
Rust in 2018: easier to use - OberstKrueger
https://jvns.ca/blog/2018/01/13/rust-in-2018--way-easier-to-use/
======
grayrest
I expect a "it's easier to use" evangelism push around the upcoming epoch
release. There are a bunch of mostly completed but still feature flagged
changes that should remove a lot of the borrow checker toe stubbing. Getting
rustfmt (formatter) and clippy (linter) on stable Rust would ideally be part
of the push.

Aside from the almost completed features in the pipeline, I only see
procedural macros (macros 2.0) and whatever happens to make async code easier
to write[1] really impacting day-to-day code for most people.

[1] I'd really like to see F# Computation Expressions instead of async/await.
I know the language experts have said Haskell-like do notation doesn't work in
Rust but I'm not sure if the F# tweaks would make it work or not.

~~~
curiousGambler
Why anyone would name anything "clippy" again is beyond me.

~~~
jgtrosh
Clippy is reborn from its ashes into a cultural icon; it made you react,
therefore it's a fun name to choose. Kakoune uses a clippy ASCII art for its
immediate help, it's nice.

~~~
bjz_
> Kakoune uses a clippy ASCII art for its immediate help, it's nice.

Had to look this up - very cute!

[https://github.com/mawww/kakoune#screenshots](https://github.com/mawww/kakoune#screenshots)

[https://raw.githubusercontent.com/mawww/kakoune/master/doc/s...](https://raw.githubusercontent.com/mawww/kakoune/master/doc/screenshot-i3.gif)

~~~
tomsmeding
Their choice of executable name is slightly unfortunate in Dutch, where 'kak'
basically means 'shit'.

~~~
elygre
I think “kak” would be better translated as “poo”. Parents will routinely talk
to their kids about “kak”, similar to the way US parents will use the word
“poo”. The word “shit” generally has a much stronger meaning (and is therefore
often obscured, as “s..t” or something similar.

~~~
lieuwex
I think "kak" still would be translated better as "shit", you wouldn't curse
with "POO!". But in Dutch you can curse with "KAK!", just as 'SH*T!' in
English.

------
yen223
This is going to sound weird, but I would like to see a garbage-collected
Rust. Take away the borrow checker, and you still have a modern language with
UTF-8 support out-of-the-box, algebraic data types, pattern matching, a focus
on performance, and great tooling (cargo + rustup = <3).

OCaml almost fits the bill (Rust is inspired by OCaml after all), but the
tooling around it is lacking to put it mildly.

~~~
Nelkins
F# sounds like it fits the bill. ADT, pattern matching, performant, great
tooling (multiple amazing IDEs, a REPL, etc.), and a huge ecosystem of
software packages to use with it (all of .NET). It's my favorite general
purpose programming language (can be used for frontend programming, server,
mobile apps, etc.).

~~~
andendau
F# has hit a huge sweet spot for me in productivity, strong typing, inferred
typing, multi-paradigm and syntactic sugar. The tooling just gets better and
better. I struggle to think of a language that's so well rounded.

~~~
carlmr
Couldn't agree more. My only wish is more people would use it.

~~~
eggy
My wish too! I have no issues with F# on Windows or Linux using .NET Core I
use F# as my general high-level language and Zig as my C replacement/Rust
alternative for low-level work. I can gradually re-write C stuff in Zig, and
be productive.

    
    
      [1] - ziglang.org

------
stevedonovan
The error messages are indeed _mostly_ marvelous (and there's an ongoing
effort to make them even more marvelous). Often working with `rustc` feels
like pair programming for introverts. But here's a question: `rustc` often
gives _actionable_ advice - how far can can you get just following that
advice? You can make `rustc` happy by following suggestions, but may end up
puzzled as to the reasons for the changes it suggests.

~~~
Karliss
Having some understanding of difference between value and reference types
types (from c or c++) and reading documentation a bit might be necessary.
Error messages sometimes also contain links to documentation in case you have
no understanding of the topic. The most common problems I had so for was due
to incorrect level of indirection. In such cases the cause is quite clear
function returned/expected reference/value/Option<val>/Option<&val> and you
tried to assign it to something else. Suggestions help learning how standard
library API behaves without opening API reference. In case of unwrapping
Option or limiting borrows lifetime the code may get a bit messy. In such case
I recommend reading documentation/searching internet as there might language
or standard library feature (sometimes even in the link given by error message
but not message itself) that helps writing it cleaner without brute forcing
the code. Due to type checking it is difficult to mess up worse than making
ugly code or moving away object you didn't want(which will be pointed out by
compiler if you try to use it afterwards).

~~~
stevedonovan
Oh yes - there will be some explicit type like
std::vec::Vec<&std::string::String> in the error and that all-important '&'
gets lost in the verbosity. Definitely necessary to learn to see the needle in
that haystack. (Some have proposed simplifying the explicit types if no
confusion results, but this could always done by a post-processor. I saved
some of my sanity when doing C++ this way)

~~~
bjz_
> and that all-important '&' gets lost in the verbosity

Perhaps some console colouring could help as well. I'd really like some type
diffs on type mismatch errors (I think Dotty has this?). That could be super
handy for quickly diagnosing errors - speaking as a reasonably experienced
Rust user here.

~~~
stevedonovan
Well, we already have a christmas tree colour issue. I think rustc could do
better here - check whether types differ by only '&' and put out a hint. That
is, by adding/removing &, could the error have been resolved?

------
karlding
Out of curiosity, how is the embedded story (for both bare-metal and RTOS) in
Rust nowadays? I took a look early last year, and I remember feeling that the
ecosystem still wasn't as mature as I liked.

There's svd2rust [0] and dslite2svd [1], which is basically "bindgen for
hardware". Please do correct me if I'm wrong, but from what I understood [2],
most SVD files leave out a lot of information so a lot of what svd2rust
generates is unsafe. Seems like the only way around that is to patch the SVD
files. Is this still the case?

In addition, what about compiling with no stdlib? And how does that interop
with existing Crates (ie. do new "embedded-specific" Crates need to be
created?)

Super excited to see Rust gain traction! I'll definitely take another shot in
my free time and see how the ecosystem has matured.

[0] [https://github.com/japaric/svd2rust](https://github.com/japaric/svd2rust)

[1]
[https://github.com/m-labs/dslite2svd](https://github.com/m-labs/dslite2svd)

[2]
[https://www.reddit.com/r/rust/comments/687b3l/embedded_in_ru...](https://www.reddit.com/r/rust/comments/687b3l/embedded_in_rust_rust_your_arm_microcontroller/dhby29s/?context=1)

~~~
jefftime
I tried exploring no_std Rust recently, and found it to be quite frustrating.
After just using a Result type I was getting errors of things like
`eh_unwind_resume` being undefined. Toggling LTO rectified my problems but
didn't give me much confidence in reliably using no_std

~~~
red75prime
`-C panic=abort` compiler option should have fixed the problem. If you want to
be able to intercept panics, you need to provide implementations for
`eh_unwind_resume` and `eh_personality`.

~~~
jefftime
Perhaps it's just an issue of me not being educated enough with this kind of
low-level Rust. Setting panic to abort in the cargo config did indeed fix
`eh_personality` being undefined, but `eh_unwind_resume` still seems finnicky.
Building in release will work, but building in debug will still complain

~~~
red75prime
I'm a little rusty on the topic, but it seems ([0]) that adding `#[no_mangle]`
before `panic_fmt` should fix it.

[0] [https://github.com/rust-lang/rust/issues/38281](https://github.com/rust-
lang/rust/issues/38281)

~~~
steveklabnik
See also [https://doc.rust-lang.org/nightly/unstable-book/language-
fea...](https://doc.rust-lang.org/nightly/unstable-book/language-
features/lang-items.html#writing-an-executable-without-stdlib)

~~~
jefftime
Even specifying `eh_unwind_resume` as a lang item gives me a linking error in
debug builds.

~~~
steveklabnik
Did you define them exactly the same way? Every aspect has to be identical;
extern, no mangle, function name, arguments, lang item.

If this happens to be open source, I can take a look at it.

~~~
jefftime
I just whipped this up yesterday to test if I was still having the same
issues. Debug fails to build with a linking error "undefined reference to
`_Unwind_Resume`". Release build works fine.

I'm using rustc 1.25.0-nightly on Ubuntu 17.10

[https://gist.github.com/jefftime/d7e96461138b5aa6895550b63ca...](https://gist.github.com/jefftime/d7e96461138b5aa6895550b63caac66c)

~~~
steveklabnik
The lang item symbol names need to be prefixed with rust_ like this:
[https://gist.github.com/steveklabnik/5abd59a8fe7e5abda3db58b...](https://gist.github.com/steveklabnik/5abd59a8fe7e5abda3db58bd8c208fbb)

~~~
jefftime
This didn't fix the compilation errors for me. I can set my own no_mangle pub
extern `_Unwind_Resume` function (without declaring it a lang_item) and fix
the undefined reference that way, but I'm pretty sure that's not how one's
supposed to solve this

~~~
steveklabnik
Hm, it compiled for me. Well, it didn't know about the C functions that were
being linked in, but it didn't complain about the lang items.

You should file a bug, maybe.

------
ohazi
Agreed. I've played with Rust on and off since ~v0.8. I tried to get through
the Matasano crypto challenges a few years ago and gave up after hitting a few
language hiccups. I recently gave it another go, and it's _much_ easier to use
now.

I must have written around a thousand lines before needing a lifetime
annotation, vs. something like 30 lines two years ago.

~~~
QasimK
The Matasano crypto challenges seem interesting and remind me of Project
Euler. I used the latter to help learn Python a little, and I think the former
would be even better for Rust!

------
eecc
Julia writes she wouldn’t yet use Rust to write webservices. Right there, this
could be the mission for 2018.

[http://www.arewewebyet.org](http://www.arewewebyet.org)

Nobody with a sane mind would write C or CPP micro-services, but post-Spectre
and Meltdown any reclaim in performance is tangibility valuable. Rust could be
the one to swoop in and claim the position

~~~
pjmlp
Neither I think Rust is fit for that purpose, any GC language is a better fit
in terms of productivity, unless we are speaking about tiny IoT devices with a
few KBs.

Also, it is not yet fit for writing GUI code. It is quite far from what is
possible to achieve today in Qt/WPF/Cocoa/Android/... tooling and even the
latest NLL improvements don't fix all issues regarding writing callbacks.

~~~
vhakulinen
Writing GUI with rust is totally possible: [http://gtk-rs.org/](http://gtk-
rs.org/)

~~~
pjmlp
It is possible, but far from productive, which I learned exactly by trying to
use Gtk-rs to port an old basic Gtkmm demo, that I used for a C/C++ Users
Journal article.

~~~
amelius
Wasn't Rust invented to write a GUI? A webbrowser can be regarded as a kind of
GUI.

~~~
foldr
There aren't any good GUI libraries available for Rust at the moment. GUI
libraries are huge and take an enormous amount of work to get right. It's
typically only the most popular three or four languages at any given point in
time that have satisfactory GUI libraries. Rust has the additional burden that
it is far from trivial to wrap Gtk, Qt or other C/C++ toolkits in a safe
manner.

~~~
amelius
Didn't Mozilla write a GUI library before they wrote Firefox? It would strike
me as odd if they didn't.

~~~
foldr
There is no mature GUI library for Rust that I'm aware of. I believe the servo
project is focused on writing a browser rendering engine, not a browser GUI.
It certainly has not so far yielded a GUI toolkit that can be
straightforwardly used in other projects.

------
reacharavindh
Just an idea: I wish there was an official wiki in the lines of Arch Wiki that
shows how to do things with Rust with lots and lots of examples.

True there is the Rust Programming Language v2 book and several other learning
resources online, but they all carry redundant information and pass it on the
user to discover what they want to learn. A legendary wiki which acts like a
cookbook of all things Rust could be awesome and anyone can pick what they
want to learn about and go at it.

I would happily contribute and do it, but I'm just starting to learn Rust.
Perhaps it is easier for other experienced Rustaceans to do it right.

~~~
chillydawg
[https://rustbyexample.com/](https://rustbyexample.com/)

~~~
reacharavindh
Thanks for the link.

I thought it was a small effort to show around the language features. Like a
live(runnable code) version of the Rust programming language book. Very useful
for someone trying learn the language feature by feature.

What I'm writing about is a how-to style wiki. For example,

How to do things with Rust:

How to read from stdin?

How to read and write from a text file?

How to make a REST API call from Rust?

How to parse JSON content in Rust?

How to connect to PostgreSQL in Rust?

How to issue Unix commands to a remote host via SSH using Rust?

How to create threads for parallel work in Rust?

You get the idea..

~~~
bjz_
The Rust Cookbook has made a start on this too! [https://rust-lang-
nursery.github.io/rust-cookbook/](https://rust-lang-nursery.github.io/rust-
cookbook/)

~~~
reacharavindh
Thanks for posting the link. Precisely what I was talking about! They are very
useful to play around with the language ecosystem.

If I learn something new, I'll try to add to their repo.

------
stumpelrielzchn
Surprised no one mentioned the long compile times yet.

For me, while I'd really like to try Rust, these are a deal-breaker.

~~~
Sammi
Looks like incremental compilation has been enabled in nightly:
[https://github.com/rust-lang/cargo/pull/4817](https://github.com/rust-
lang/cargo/pull/4817)

~~~
stumpelrielzchn
That's a welcome improvement from last time I looked at it.

Does anyone know a ballpack figure for how many LoC/s you can expect on a
beefy workstation?

~~~
steveklabnik
It really depends. That is, thanks to monormorphization, 1 LOC in your source
doesn't necessarily mean 1 LOC compiled by the compiler.

Furthermore, this is the start of incremental: we have more stuff coming down
the pipeline.

------
nafizh
Anyone has suggestions on learning rust for a python programmer who is also
not strong on systems concepts?

~~~
StreamBright
Depends what is your goal. Learning a language with decent type system?
Learning a language with lower level access to operating system features? I
would suggest to learn OCaml because it got really popular in 2017 thanks to
Facebook & Bloomberg, it has an amazing type system and you can use it to
build CLI tools and web pages (Reason/Bucklescript) with an insanely good
tooling (utop, jbuilder, merlin) and the community is probably the best
community of software engineers I have encountered recently. If you are
interested in lower level coding there is Mirage as well.

[https://discuss.ocaml.org/](https://discuss.ocaml.org/)

~~~
papaf
I used OCaml a few years ago and I thought it was an excellent language.
Despite being powerful it was really easy to learn.

One thing that put me off in the end was that it didn't support native OS
threads (I have the same problem with Racket). Has threading support improved
over the years?

~~~
StreamBright
I am not sure what exactly you are missing, isn't this a native OS thread
either POSIX or Win32?

[http://caml.inria.fr/pub/docs/manual-
ocaml/libref/Thread.htm...](http://caml.inria.fr/pub/docs/manual-
ocaml/libref/Thread.html)

~~~
papaf
The documentation that you linked to is not describing native OS threads. I am
sure that the OCaml implementation is good for a lot of applications.

However, because I am used to writing multithreaded code using pthread or
std::thread, I find the standard OCaml model uncomfortable and limiting. Its
mostly a matter of personal taste but this is the reason I stopped using
OCaml.

------
shmerl
_> like – maybe Rust is not for people who are already C++ experts and who are
happy with C++? I don’t know!_

I think Rust is very good for C++ experts. Some key concepts like ownership /
RAII and etc. are well known in C++, and they should be easy to understand.

~~~
cesarb
Yeah, people with C++ experience have an advantage when learning Rust, since
they're used to these concepts, and the Rust compiler enforces things they
already know to be careful with (like not mutating a container while there's a
live iterator to it). On the other hand, Rust lacks some things C++ has like
being generic over values instead of just over types, so for instance
implementing a trait for every fixed-size array of a type is currently AFAIK
not possible (the usual solution is to use a macro to manually implement the
trait for every size up to 32).

~~~
TillE
As someone who's extremely comfortable with C++, I've tried Rust multiple
times but keep bouncing off. Ultimately my problem is just that it doesn't
have enough exciting features to lure me away, especially with C++ improving
every few years.

Compiler-enforced safety and a built-in package manager are really nice, but
it doesn't quite make up for the loss of a lot of handy C++ features.

~~~
steveklabnik
Which features do you miss the most?

------
b0rsuk
I'm learning Rust by writing graphical / glitch art software. Not too much
exposure to 'systems' programming although color spaces are more complex than
you'd think. Performance is important when you shuffle thousands of pixels
around, and some of it is easy to parallelize.

------
xstartup
Is there something like Helix (Rust) for Python?

~~~
steveklabnik
My siblings have given good answers, but there's also
[https://blog.sentry.io/2017/11/14/evolving-our-rust-with-
mil...](https://blog.sentry.io/2017/11/14/evolving-our-rust-with-milksnake)

------
StreamBright
Well it is super easy to develop hello world in Rust. Yay! Last time I checked
there was no decent HTTP client and the documentation is just non existent for
that subpar library. There were lost of promises about the newer version of
async io library yet it is still WIP as of today. The performance was 30 times
less than the same code in Java and after consulting many Rust developers
nobody could tell me why.

It is new, it is shiny but lets wait its 10th birthday before it can be taken
seriously and pls provide a decent async io / http library before we even get
started what else can be done in Rust.

~~~
setzer22
So if a language can't do HTTP and async I/O (with state-of-the-art
performance) then we shouldn't consider any other possible application for it?
Rust is not Java, you have better languages to build webservers with.

~~~
kod
Yes, if a language can't easily do async IO and HTTP in 2018, it is in deep
shit with regard to long term adoption. The Rust devs realize this, otherwise
they would be putting less effort into tokio.

------
karo_ops
Each time I try to read an article by Julia, I get alienated by the chidlish
style of writing (count the exclamation marks and caps).

Which is a shame, because the article is otherwise fine.

~~~
hateduser2
You can probably just ignore that right?

~~~
fyfy18
I feel the same as OP in regards to spelling mistakes. It just erks me so much
that I find it really hard to continue reading.

If someone hasn’t bothered to take the time to proof-read their work, what
does it say about the topic they are writing about? I don’t mind if the
mistakes are because they are learning English, but I’m talking about really
obvious spelling mistakes.

~~~
erpellan
Irks.

(I checked - TIL an 'erk' is a male member of the RAF of the lowest rank.)

Or did I just miss the ironic joke?

------
grnadav1
A guy w/ 10 weeks Rust experiance and already gave a talk at RustConf?!

~~~
Manishearth
The closing keynote at RustConf is generally someone who is new to Rust or has
never used Rust but can bring in an interesting perspective. Last year we had
Joe Duffy, who I don't think has done much Rust aside from perhaps basic
experimentation, but has a lot of relevant experience from running the Midori
(Microsoft's safe systems language) project.

(also, the author isn't a "guy")

~~~
Shoothe
It's interesting because when I read about how Rust can rewrite iterators code
into more performant direct loops I thought about Joe's blog posts that
mentioned the same efforts for .NET. Also Span<T>. It seems .NET will have
similar abstractions like Rust (of course not all can be migrated).

~~~
pygy_
LuaJIT does the same, down to an absurd level.

From the luafun library readme (which uses iterators under the hood):

[https://github.com/luafun/luafun](https://github.com/luafun/luafun)

————

> Let's see an example:
    
    
        > -- Functional style
        > require "fun" ()
        > -- calculate sum(x for x^2 in 1..n)
        > n = 100
        > print(reduce(operator.add, 0, map(function(x) return x^2 end, range(n))))
        328350
    
        > -- Object-oriented style
        > local fun = require "fun"
        > -- calculate sum(x for x^2 in 1..n)
        > print(fun.range(n):map(function(x) return x^2 end):reduce(operator.add, 0))
        328350
    

> _Lua Fun_ takes full advantage of the innovative _tracing JIT compiler_ to
> achieve transcendental performance on nested functional expressions.
> Functional compositions and high-order functions can be translated into
> _efficient machine code_. Can you believe it? Just try to run the example
> above with `luajit -jdump` and see what happens:
    
    
        -- skip some initilization code --
        ->LOOP:
        0bcaffd0  movaps xmm5, xmm7
        0bcaffd3  movaps xmm7, xmm1
        0bcaffd6  addsd xmm7, xmm5
        0bcaffda  ucomisd xmm7, xmm0
        0bcaffde  jnb 0x0bca0024        ->5
        0bcaffe4  movaps xmm5, xmm7
        0bcaffe7  mulsd xmm5, xmm5
        0bcaffeb  addsd xmm6, xmm5
        0bcaffef  jmp 0x0bcaffd0        ->LOOP
        ---- TRACE 1 stop -> loop
    

> The functional chain above was translated by LuaJIT to (!) _one machine
> loop_ containing just 10 CPU assembly instructions without CALL.

------
dmitriid
\- "I'm an intermediate programmer"

\- "I'm writing a profiler"

\- "I wrote a mini-OS"

\- "I had a talk at RustConf"

Other than that, it's really good to see Rust improving.

~~~
pygy_
Intermediate _Rust_ user. Obviously she excels at coding.

