
An Intern's Experience with Rust - discreditable
https://msrc-blog.microsoft.com/2019/10/16/an-interns-experience-with-rust/
======
echelon
> First lesson: Rust isn’t as hard as I expected

We're going to see a lot more of this. As the language has matured, the Rust
folks have paid great attention to easing the learning curve. Even with the
borrow checker, it's not that far from Java or a scripting language these
days. Most people won't hit lifetimes early on in their use.

~~~
jandrese
I don't know. I recently took a Rust course and our day three project was to
build a simple multi-threaded webserver. The really easy kind in C where you
accept a connection and then spawn a thread to handle the request so the main
thread can get back to accepting new connections ASAP.

This turned out to be quite challenging in Rust, even when starting from a
working single threaded server. Threading the needle on borrows was quite a
challenge.

~~~
fluffything
Did you learn C (or any other programming language) by writing a multi-
threaded web server in it ?

The Rust book actually ends by showing you how to do that, but... there are
many reasons why that's the last chapter in the book. Starting there is
definitely not the most efficient way of learning Rust.

~~~
tick_tock_tick
I did for golang. Assuming you know how to program in general it's a very
basic task.

~~~
vertex-four
Ehh... it's a basic task _as long as you never touch shared mutable state_. As
soon as you have to do that, you need to work out what the abstraction for
dealing with shared mutable state in your language of choice is.

~~~
tick_tock_tick
I mean most languages you don't. You lock do some stuff then unlock. Rust
prevents a whole lot of bugs by not making it this simple but that means if
you pick anything with threading as a task to jump into the language your
going to have a much harder time.

~~~
fluffything
Rust `Mutex`es are simpler to use than C++ ones.. so if you just `Mutex` your
shared state away, writing an app on top of `actix-web` or `hyper` or `tokio`
is dead easy once you learn how to use the framework, particularly if you have
already done that before in Go.

------
grok2
Anybody else found the last variation annoying from a C perspective? I find
that people coming from a web background don't mind writing complex statements
in function parameters (seems like due to writing lambdas/closures and such
encourages this kind of programming; maybe it makes sense in a lazy evaluation
environment), but people with a C background use the last-but-one variation
where you use an intermediate variable to capture a prior result to use as a
function parameter. I myself prefer the last-but-one variation and it's a pet-
peeve of mine that people write large functions/expressions/statements as
function parameters when not needed all in the name of conciseness -- I think
it affects readability.

~~~
thrower123
Generally, I like to keep the temporaries. Mostly it is a consequence of
getting burned and trained by the Visual Studio debugger; trying to put
anything too complicated into the watch window or even evaluating it in the
immediate window tends to be an exercise in frustration. It's also easier to
step into the sub-expression/function call if need be when I do this, which is
not always the case if it is a parameter to another function.

~~~
Sammi
I feel like there is some law in the universe that says that if I don't use an
intermediate variable, then I will for certain need that intermediate variable
some time later when I'm debugging.

------
Crinus
While i appreciate the type safety that Rust may provide (even if it is
overblown and only just a little, it can still be useful - e.g. while i prefer
C, i do like C++'s "enum class"), my two main issues are that it is only a
single implementation (and that implementation looks is too Unix-y with the
Windows versions looking bolted at the side) and -especially- _too_ slow.

I get annoyed when my C builds take more than a few seconds and a major reason
i avoid C++ for my own stuff (C++'s complexity is another reason) and i hear
that Rust has worse compile times than C++. This is enough for me to stay away
from it.

But if Rust manages to get an implementation that feels at home at Windows
with a full IDE and debugger and also gets around C-like compilation speeds,
then i'd like to check it out.

~~~
unlinked_dll
On the other hand, I think user time is more valuable than developer time and
when building complex/efficient software expecting lightning builds isn't just
unwarranted, it's selfish.

~~~
Crinus
> I think user time is more valuable than developer time

Developers are users of their development tools.

> when building complex/efficient software expecting lightning builds isn't
> just unwarranted, it's selfish.

This is wrong. There is no rule that says that you cannot write fast
applications with fast builds. It is just that we got used to C++'s slow build
times.

This sort of thinking even falls flat on its face when you consider that C
provides similar optimization opportunities as C++ (and in pretty much every
modern compiler it uses the same backend and most - if not all -
optimizations) while compiles much faster.

But beyond that most of the codebase of a decently sized application does not
need more than the most basic of optimizations - it is only a tiny tiny
fraction that needs that, yet with modern C/C++ (and most other) compilers,
the entire codebase suffers for it (i think only Visual C++ allows you to
control optimization settings on a per-function basis, but i haven't
encountered any codebase that actually uses this outside of temporarily
disabling optimizations for debugging and/or working around bugs).

------
NoGravitas
People promoting Rust tend to assume that it's the _concepts_ in Rust that
don't exist or aren't explicit in other programming languages that are the
hard part. In my opinion, that's not true. It's the _syntax_ used to make
those concepts explicit. To use the example from the article: lifetimes are
not a hard concept to grasp. Knowing when the Rust compiler will require you
to make a lifetime explicitly part of your type, vs. when you can elide it?
Hard.

~~~
steveklabnik
> To use the example from the article: lifetimes are not a hard concept to
> grasp. Knowing when the Rust compiler will require you to make a lifetime
> explicitly part of your type, vs. when you can elide it? Hard.

There are only three (or is it four?) rules about when you can elide.
Personally? I never write lifetimes, and then the compiler yells at me, and
then I fix it by adding them. It's not something that you need to actively
think about. You see

    
    
        error[E0106]: missing lifetime specifier
         --> src/lib.rs:2:8
          |
        2 |     x: &i32,
          |        ^ expected lifetime parameter
    

and you add it in.

~~~
Corrado
Lifetimes trip me up in Javascript all the time. I think that I have all my
callbacks and/or promises lined up and dealt and my app runs fine. Until it
doesn't and I discover that there is some corner case in my 5 nested deep
callback hell where I didn't catch some DB timeout. I'm looking forward to
that never happening again in Rust.

------
Thaxll
"Rust code is wonderful to write and read"

Writing I'm not sure, reading it's just awful, everytime someone show his
project on HN I check github and I'm baffled how the code looks bad as a human
reader. (){}<>''-_

~~~
derefr
I feel like, whether with human or computer languages, you can only really say
what the experience of reading a language is like once you're fluent in it;
and you can only _compare_ the experience of reading a language to another if
you're fluent in both of them.

Like, to me, the human language of Vietnamese looks like a mess of accents,
and I'm baffled by why they're necessary. But I'm not a fluent speaker of
Vietnamese; and I can imagine that, for someone who _is_ fluent in Vietnamese,
and another sibling language like Chinese, maybe the extra accents actually
compare very well and help readability compared to e.g. the reduced set of
accents in Chinese _pinyin_.

Likewise, I would suspect that for someone fluent in both C++ and Rust (i.e.
someone who knows how to write code that takes advantage of arcane language
features in both), Rust might be more readable than C++ _because_ of some of
the initially-offputting syntax, whereas C++ might seem less readable because
it eschews extra syntax in favor of using template constructors for
everything.

~~~
Waterluvian
This reminds me of my experience with TypeScript. I kept noticing it and
feeling a little irritated by its popularity. God it added so much noise to
the code. JavaScript was fine for years. I got stuff done. I caught the bugs
and debugged them.

Once I finally took the plunge and committed a full project to learning
TypeScript, I grokked it. I no-longer saw noise, I saw signal. I saw details
about interfaces that I used to have to infer, document, or reverse engineer
if I forgot.

~~~
singingboyo
Incidentally - I have the reverse issue.

I had (still have!) trouble reading JS, because the vast majority of things
I've worked on have been in statically typed languages. JS was baffling
because I always have to try to infer/reverse engineer things that I can just
read off in the languages I'm most familiar with.

The only way I really could handle dynamic stuff was for things like scripts,
where I could mostly remember the entire set of types.

I've gotten better with JS after using some TS, but that difficulty still
exists. Correspondingly, I'm delighted by Rust - sure, it's a verbose
language, but that puts everything I want to know _right there_ for me to
read.

------
ncmncm
That is also not how you would write it in idiomatic C++.

The "before" example is C, or bad C++. You are allowed to write bad C++, as
you are allowed to write bad Rust. But if you are to compare langues honestly,
you should be comparing good code in one language to good code in the other.

The alternative is tendentious but typical, and nothing to be proud of.

~~~
thrower123
I wouldn't expect an intern to write idiomatic modern C++. That looked to me
to about what I would expect from a university student that had passing
familiarity with C++ from their coursework; there is still an unbelievable
amount of "C-with-classes" in active use and pedogogy kicking around.

~~~
pjmlp
Given how we used to teach C++ to university first year students back in 1994
- 2000, it still confuses me that there are so bad teachers keeping "C-with-
classes" in active use.

Basically, even without the STL, the students would get our department C++
library with the usual stuff (strings, arrays, vectors, bounds checking
enabled), and the teaching would be similar to the way that Kate Gregory
preaches how to teach modern C++.

------
thelazydogsback
Although object lifetime and borrowing is mentioned, he focuses on the pattern
expression which he's likely to get in any modern language.

Rust has many great qualities and I've been looking to find a project for it,
but it just doesn't seem like the model for long-running processes with
immutable data-structures and complex/dynamic/interlinked lifetimes. Seems
like dev. effort is better spent on functionality than managing lifetimes,
especially given that modern GC is so fast. (And I've seen C++ ports to C#
become faster, due to unneeded calling of copy c'tors, and other goodness.)

I can totally see the case for Rust in systems code where lifetime is gated by
a system/API call and you want to safely pass buffers around during the
duration of the call, for inner-loop gaming, for embedded, etc. But seeing
it's en vogue, there are many examples of Rust code where it doesn't seem like
the right tool -- but then again, I feel that way about much code written in
C++ as well.

~~~
arcticbull
You don't spend developer time "thinking" about lifetimes as you write Rust,
it becomes totally automatic, no more than you spend time "thinking" about
functions in C#. The benefits you get far outweigh the negligible overhead,
providing things like data race prevention across threads in addition to
memory safety with incredibly low overhead. Modern GCs are fast _er_ but
they're by no means free, and totally unnecessary if you just give the
compiler the information it needs to do its job statically instead of
continuing to strap more rockets to the GC rocket-powered horse. It's the
_fastest_ horse but it's still a horse, not a car.

~~~
pjmlp
Try to write a sizeable Gtk-rs application to see how automatically it gets if
you don't create your own clone macro to deal with all the Rc<RefCell<>>
instances, like the Gtk-rs samples show.

~~~
arcticbull
I’m not sure a single example of a C wrapper not idiomatically designed is a
good example of the potential of a language. It’s like pointing to the source
for any given STL implementation as quintessentially C++ coding style.
RefCells tend to be considered an anti-pattern AFAIK since they leave
invariant checking to run-time. It's meant as a hack/patch if you can't
actually design it idiomatically for some reason, such as in this case, FFI to
a C programming model.

~~~
pjmlp
I can point to other UI examples, like game engines written in pure Rust,
using array indexes with clocks on access to invalidate possible use-after-
free accesses with outdated indexes.

------
lacker
Rust is pretty neat and I would like to use it more. It seems like it could be
the ideal tool for performance-optimized software, like C++ was 15 years ago.
Unfortunately, there isn't all that much performance-optimized software that I
am writing nowadays.

------
jcmontx
The person writing this seems to be a very clever and capable individual. That
being said, I would imagine a company the size of MSFT would have a senior
engineer coding "a security critical network processing agent". That sounds
like a lot of responsibility for someone inexperienced.

------
agumonkey
the `{y:2, x:1..=4}` syntax is confusing, is it really range checking ?

~~~
steveklabnik
Yes, it says "match if y is two, and x if it's between one and four,
inclusive".

~~~
agumonkey
Weird couldn't find it in the Book.

~~~
steveklabnik
We don't cover this exact combination of features directly in the book; this
falls out of composing the "pattern match" feature with the "range" feature.

It's also possible that you're reading a version of the book before the ..=
syntax was introduced; it hasn't been there since 1.0.

------
diaz
Interesting.

Now if only the images with code actually had the snippets in code form I
would be able to share the blog post to other people.

