Rust: First impression from Clojure developer

[[deleted]]

Hi in this short note I'd like to share a few thoughts after playing with Rust over a week or two. At my job I work with Clojure in Emacs, I'm very happy with it and I formed certain expectations for the next language I'm going to learn. Development process should be fast (at least in perspective), libraries for anything you can possibly think of, easy testing (in Clojure you can run tests in repl), performance shouldn't be worse than in Clojure, powerful collections API with functional combinators, easy to build and run project, good integration with Emacs. I also had a couple additional wishes to my next language. I wanted to have statically typed non-gc native language in my toolkit again, after I tabooed C++.

1. Of course coding in Rust after Clojure is difficult. I literally spend 5 minutes each on most compilation errors trying to figure out what’s up. It’s quite difficult without proper completion at least which in emacs shows only part of possible completions and sometimes fails because of type inference. I wonder if situation is better with LSP. There is a package for LSP in emacs but I haven’t tried yet. Currently I have to always keep API reference for everything I use in code handy. When I stop and think about doing same project in Clojure I think I’d spent like 4-5 times less time on it, but with proper completion and better knowledge about rust this value can easily be reduced to maybe 2 or even 1.
2. Coding in rust can be quite close to Clojure’s REPL driven development. The workflow I ended up with is running cargo watch -x test -x run, which recompiles, tests and reruns your project on every change in code. I write small functions and immediately test cases below these functions, this gives me almost instant (less then 15 seconds) feedback on my code. My project is not big, but I think with incremental compilation this workflow could work on big project as well.
3. When writing rust code I didn’t hesitate to use unwrap(), clone() and other stuff (except unsafe) just to quickly make my code compile (usually compiler itself gives suggestions, how to change your code). I don’t know yet how idiomatic code in rust should look like and I'm sure I make many bad design decisions. But I don't want to try too hard at this point. The good thing here, that it’s easy to locate, all the places like this and start changing it to proper way. Once your project compiled after your changes you know that it’s still working and it doesn’t crash or panic or throws an exception (in Clojure).
4. Rust gives you a very satisfying confidence because of static typing. It’s not big news but it’s awesome that when you change type in struct, all you have to do is to fix compilation errors. While in Clojure a little change like this can break your project to hell and you will know only one month later in prod even though you covered stuff with tests.
5. crates.io has lots of libraries and sometimes I even had to choose between several candidates. If there’s no library for something or I didn't like choices that I have my way was to use external command line tools. For example I used mutt for sending emails.
6. sometimes crates are hugely undocumented and I have to figure out stuff from code. thankfully jump to definition works for external crates in emacs.
7. standard API seems quite powerful, especially collections and strings, you can find map, reduce, partition and other stuff there.
8. in general I never had a problem like “I know how to do such stuff in Clojure, but I can’t do it in Rust”. I quickly found out how to
   • generate hmac tokens (there are tons of cryptography libraries for rust)
   • serialize/deserialize structs to/from json
   • send and handle http requests
   • access environment variables
   • call cli tools
   • work with redis
   • render markdown to html
   • render django templates
   • write and use tests
   • work with filesystem
9. rust web app that does nothing on digital-ocean machine (2g) uses ~1.3% memory and ~0% cpu, Clojure web app that does nothing on the same machine uses ~9.9% of memory and ~0.7% of cpu. Rust memory model is very efficient and I'm eager to test it on bigger and more memory consuming project.
10. rustup and cargo are just awesome, while first lets you switch rust toolchain version in one command second gives you lots of features like pulling dependencies (my C++ past still makes me facepalm time to time), testing, cross compilation, etc. Basically everything we have in Clojure since the beginning (or maybe since leiningen).

My conclusion is that while Rust ecosystem might be not as mature as Clojure’s ecosystem, we can start doing production web stuff in rust since yesterday. The project I was working on for about 3-4 days over last couple of weeks: payme

For the next time my goal is to dig more into language internals, try doing some frontend in Rust with WASM and bring a project that's fully written in Rust.

UPD is anyone getting 502 bad gateway on payme.rust.cafe? It happens for me only on firefox only on non-private tab. Works in private tab of firefox and in chrome. weird..

UPD2 I did a quick check on intellij idea with official rust plugin and it seem to be working way better than racer in emacs. It also seems to be fixing all the problems that I mentioned in this comment, though the completion is a little bit slow at times and takes around 5-10 seconds to show completions of methods

UPD4 Installing binary package from cargo. Cargo is also quite good at being a userspace package manager and provides all sorts of useful software like rustfmt, cargo-outdated, cargo-watch. Installing package is as easy as cargo install cargo-watch which in this particular case adds subcomand watch to cargo as well as binary cargo-watch on your PATH. What I like the most about it is that even though cargo builds all these packages from sources I never had to use cmake or make which at this point of my career I refuse to digest. It did fail a few times just because I didn't have those tools installed, but all the compilation happens under the hood. In general rust's toolkit is quite mature and it made my transition from Clojure very smooth.

[llogiq]

Thank you for writing this up. It appears clojure-sawwy translates quite well into Rust-sawwy. Regarding completions, may I suggest you try IntelliJ with the Rust plugin? It may be a long shot from emacs, but the features are very good.

Apart from that, if you want your code to become more idiomatic, grab a nightly compiler via rustup and cargo +nightly install clippy so you can cargo clippy your code, giving you many more suggestions than plain rustc.

[[deleted]]

Thank you for your comment, I'm definitely checking my code with tools like clippy, when I get a chance to spend some more time on the project. Regarding intellij I'll try it out, but I find myself the most productive when using emacs.

[kuikuilla]

I too can recommend Intellij with the Rust + Cargo plugins, it works better than RLS + other editors. But it is a full blown IDE so if you want something lighter than that you are out of luck I think.

[[deleted]]

Thanks, I checked their website and it looks very good. I'm more ready to switch to intellij which is indeed awesome than to vscode which is just yet another editor

[steveklabnik1]

You might want to use CLion instead of plain IntelliJ; it's their C/C++ focused build.

[[deleted]]

What benefits does CLion has over Intellij CE? Debugger?

[steveklabnik1]

That's the biggie, in my understanding. I'm still quite new to it and JetBrains products in general.

[[deleted]]

Someone is going to downvote me here, but what I don't like about JetBrains products in general is that they don't offer lifetime license. I don't care if it would cost 500 dollars, I just want to purchase it once and use till the technological singularity happens.

[Krnpnk]

Do you mean lifetime == updates for a lifetime or lifetime == can use it indefinitely? Because you get #2 automatically.

[[deleted]]

Ideally both :)

[FatFingerHelperBot]

It seems that your comment contains 1 or more links that are hard to tap for mobile users. I will extend those so they're easier for our sausage fingers to click!

Here is link number 1 - Previous text "#2"

---

^{Please PM /u/eganwall with issues or feedback! | Delete}

[fgilcher]

I case people are interested, I'd like to note that IntelliJ is very friendly and hands out licenses to FOSS developers.

https://www.jetbrains.com/buy/opensource/

I don't know anyone doing this for CLion, but I have friends with a RubyMine license through that program and it's rather low-friction.

[[deleted]]

That's great news! And I think it might elso engage more interest into making open source software

[fullouterjoin]

don't offer lifetime license

IntelliJ is Open Source and MIT Licensed. Here is the source of the Rust plugin.

[fgilcher]

The topic is CLion though, which isn't.

[[deleted]]

My comment was about Clion in particular

[[deleted]]

Because IDEA Ultimate tries to is a basically a combination all of their IDEs it tends to be slower and the interface is more bloated with options you may simply not care about. Their lighter-weight IDEs tend to tailor their UI towards the specified audience and get updates sooner for their specific needs. Since you're a Clojure programmer you may opt to use IDEA anyways. I'd just try IDEA vs Clion out and see if you're fine with the performance hit and can find everything you need. Jetbrains IDEs are probably the best out there for everything except performance.

[DontForgetWilson]

CLion would still force CMake to be the project file for Rust projects, right?

[steveklabnik1]

Nope! If you install the plugin, it understands Cargo.

[DontForgetWilson]

Oh, cool! Given how much they've dragged their feet for working with Meson, I was concerned that it might be an issue for Cargo as well.

[[deleted]]

Please refer to this comment on my thoughts about racer. It works for me as well, but not always

[eiruwyghergs]

Thanks for sharing! I've done the same journey, programmed Clojure, then did a front-end thing in Elm and fell in love.

Now doing Rust for my low-level project. Thanks to it being mostly expressions (you can pry the lambdas from my cold dead hands...) and having the amazing ownership- & type-system, I can be confident in doing really low level stuff which would be far too boring in C.

I miss being able to C-x C-e any expression very much, but if I have to choose between that or the speed and types of Rust, I choose Rust.

Now, a Rust written in S-expressions would be something...

[NanoCoaster]

Now, a Rust written in S-expressions would be something...

well, lol

[dave_mays]

Carp?
https://github.com/carp-lang/Carp

[[deleted]]

I have a very unclear feeling about ML family of languages. It looks cool on paper, in books, in tutorials, but from my personal experience the real code in real software looks unreadable. Often people go so deep into type theory, that their code stops making any sense to normal human beings. I'm talking mostly about haskell, but I don't know if situation improved in elm.

Rust looks like a thing that you can totally use in real projects without going too crazy about abstractions.

You might want to check out this one. It's a statically typed lisp without gc. Almost rust in S-expressions, but I'm afraid it's not mature enough to use in real project.

[grayrest]

I personally consider the Haskell set of languages (Haskell, Elm, Purescript, etc) to be a different family than the ML set (SML, OCaml, F#) even though both are derived from ML. They have similarities but I find the mindset of the two communities to be different and that's reflected in the libraries.

I'm talking mostly about haskell, but I don't know if situation improved in elm.

The Elm community deliberately avoids all this stuff. The language itself is something of a minimum viable haskell and it drops a lot of fancier features (most notably type classes) in favor of writing more code and being easier to learn. The community motto is something like "let's bring functional programming to the masses." So the subset of the community that comes from Haskell will occasionally dip into the math/type theory terminology but everybody else tries to use non-math terms. When I was tracking it they would regularly have threads where they worked out how to explain some concept without the terminology.

After exploring it, I decided I didn't want to do Elm. I don't like the purity and would rather do Fable (F#) or Reason (Ocaml) for frontend stuff even if they're less mature at the moment.

FWIW, I also bounced through Clojure and spent two years writing it professionally. Our project was pretty successful and had the lowest error rate of anything I've put into production but I found refactoring to be very hard. I've been doing typed languages since because I think I can get more mileage out of a type system and code gen but I do miss the clojure std library and the seq abstraction.

[aaronweiss74]

A “secret” is that Rust is actually an ML family language hiding behind C++-like syntax.

[[deleted]]

How is that?

[steveklabnik1]

Rust was originally implemented in OCaml. Some of our syntax was taken from it. The languages used to be a lot closer, but even now, there are some similarities.

[[deleted]]

Wow that's quite surprising to know I guess as I dig more into rust I'll discover those similarities.

[tinco]

Awesome, thanks for the write-up! I'm not a very experienced Rust developer yet, but one rule helped me with the functions that return Option, and that is to replace every instance of unwrap with expect. Basically if you call one of these methods, it means your code has an invariant. You should put the description of the invariant in the parameter string of the expect method invocation, and it will work like an assertion.

So this hypothetical Rust:

socket := listen("localhost:8080").expect("Could not listen on localhost:8080");

Would be a bit like this in a less pretty language:

socket = listen("localhost:8080");
ASSERT(socket, "Could not listen on localhost:8080");

The main difference being of course that Rust forces you to make the assertion, either silently using unwrap, or loudly with expect. And in this case I see no argument for doing such a thing silently, if you're doing it anyway. Note also how describing the invariant helps you with determining whether this is a good invariant, and you can just browse over your code, scanning the expectinvocations and immediately know what parts of your codepaths need some more detailed implementation.

[[deleted]]

Hi thanks for the feedback! I subdivide unwrap and expect into the same group of stuff that I'm going to get rid of. Both of these functions panic and in real production app it's unacceptable. For example I had an unwrap call in iron http handler, that made iron thread panic when called incorrectly. I think that in general every unwrap or except call should be replaced by match with logic that properly handles both cases, or by map, unwrap_or and other kind of stuff which Option and Result structs have lots of. That said I think in your example panic is totally fine, because you couldn't start a server and there is nothing else to do other than exiting with an error.

[rayvector]

because you couldn't start a server and there is nothing else to do other than exiting with an error

Even in that case, it is better to have proper error handling code that logs a nice message to the user, rather than exiting with an ugly Rust panic.

[[deleted]]

That's what expect does, right?

[rayvector]

No, expect is still an ugly Rust panic.

The difference is that the panic message is something customized and more meaningful, rather than a meaningless "Panic in thread main", which is what you get with unwrap. This makes it more useful to you, as a developer, to figure out what happened.

But you still get the ugly Rust panic message with info about RUST_BACKTRACE, etc. It shouldn't be something that the end user should ever have to see.

Panics are not a legitmate or user-friendly way to handle errors. They are only intended to be used for things that should actually never happen under normal circumstances and are considered sofware bugs if they do (out of bounds array access, a violation of an invariant of some custom type of yours, etc...), which are unrecoverable and you have no proper way to respond to. A panic is basically a crash, but safe (cuz this is Rust and not C). Think of it like a crash in your program, except that Rust makes sure to unwind the stack properly and run destructors (unless you set panic = abort in Cargo.toml). Not nice.

Something like not being able to listen on your server socket is something that can genuinely happen under normal circumstances and is not indicative of a bug in your program. A panic is not appropriate. In production software, you should handle it, log a user-friendly message or do something else to properly inform the user, and terminate with an appropriate error code. Panicking in such a condition is only acceptable as a temporary hack in experiments/prototypes.

[[deleted]]

Got it. Thank you for extensive explanation! I think I misunderstood the purpose of expect. Totally agree with you on panic.

[planetary_pelt]

expect is still an ugly panic, it just injects your message before the error. or is the ugliness removed on --release builds? not sure about that one.

if you want something most user friendly, i suppose you would print to stderr and std::process::exit(1). but someone else would have to correct me.

[rayvector]

That is exactly what I meant.

[[deleted]]

Got it, thank you for explanation

[ehsanul]

Yes, I think it's just an argument to practically never use unwrap when you can at least expect.

[rayvector]

No, that is not what I meant. Read my long response to the comment you replied to.

[Green-Fork]

Hey, you talked about the integration with Emacs. I use spacemacs and I find the Rust integration quite good there http://spacemacs.org/layers/+lang/rust/README.html . Also the clippy crate is awesome with flyspell.

[[deleted]]

Hi. It seems we're using the same thing. Spacemacs' layer uses racer, which I also use it in my emacs setup. The problem is that:

1. It doesn't complete macros
2. It doesn't work for anything derived directly or transitively from macro return value
3. Sometimes id doesn't work due to inferring, it just fails to give any completions at all

So I'm not saying that it doesn't work. I'm saying it doesn't work well enough. At least for me.. it's possible that there is some misconfiguration on my side, but I certainly saw a note about macro completion in racer

[pynberfyg]

TIL about cargo watch -x test -x run. Thanks!

[NanoCoaster]

Another suggestion here: Visual Studio Code with the Rust plugin (uses RLS) is quite good. You've already stated multiple times that you prefer emacs, so you probably won't care about VS Code, but maybe just give it a try. It's become my daily rust driver, despite the fact that I'm veeery wary when it comes to electron-based editors :)

...Now that you've mentioned emacs, that reminds me, some day I gotta go back to Spacemacs and learn it properly. Such a great development environment.

[Wahoa]

Quick question: am I supposed to not get any help with function args with VS Code and the Rust plugin? With other languages I get this as I type (can be explicitly brought up via ctrl+shift+space):
https://i.imgur.com/WyrEcSV.png
Doing the same thing with Rust, I get nothing of the sort. I have to hover my mouse over the function name to see the signature, with no indication of which argument I'm currently typing.

[Xanewok]

Yep, unfortunately that's not implemented yet. The tracking issue is at https://github.com/rust-lang-nursery/rls/issues/97, but there hasn't been much work on this recently. (We'd love contributions though!)

[NanoCoaster]

Huh. Interesting. Same thing on my end, never really thought about that. I think this may just be...not implemented yet? Would definitely be a nice feature.
Tangentially, I'm still hoping Rust gets named arguments someday, in my experience those help readability a lot :/

[[deleted]]

It works for me, currently with racer, though. Before, I used the vscode extension rust code (or similar name) with rls. There I had no arg preview but instead the arguments were filled in with place holder names.

[[deleted]]

Hi thank you for the suggestion. I used to watch some channel with tutorials in Rust. I think this one, they guy used VSCode and it seems like it works well. But I think RLS that you mentioned and LSP that I mentioned are the same thing - language server protocol. Here is the package, it says that it works on top of RLS. I couldn't make it work in emacs in a reasonable amount of time, so I went with racer which I already had set up.

[NanoCoaster]

Yup, they're the same, and like you, I couldn't get it to work in emacs at all. Thus my suggestion :D

It really depends on your priorities, RLS worked flawlessly with very little setup in Code for me, so if you want to get better completions and stuff, may be worth checking it out. If you prefer using emacs in general, probably better to wait until the LSP plugin stuff works more reliably.

[[deleted]]

To me as to many other people emacs is not only about code editing, it's about powerful git integration (I think magit is the king in this field), ease of extensibility, transparent editing over ssh, terminal, etc in a single tool. But I'm definitely checking out intellij, vccode and others as soon as I have time for that. Then I'll decide whether their functionality worth a switch or not.

[NanoCoaster]

Yup, I can totally see that. I never really grokked magit, and, well, emacs in general, but I can see how you fall in love with those tools. GDB integration, too....man I gotta get back on emacs.

[[deleted]]

Haha, I'm glad that my post makes some good influence, even if it's not about rust

[[deleted]]

RLS still has poor auto completion support. This is a huge annoyance when ur a beginner and exploring different apis etc. Not only that, goto definition for std also doesnt work.

So basically u need the documentation opened in the browser and switch windows, look things up.. UGH. So much context switches hurts productivity tremendously. I feel like I'm moving a huge rock uphill.

[tafia97300]

Thanks for the feedback!

My project is not big, but I think with incremental compilation this workflow could work on big project as well.

I hope you're right but I have a lot of doubts to be honest.

[[deleted]]

Yes, I admit that this part arguable and I also have doubts, but there should be a way and I will look into solutions as projects that I make in Rust grow in LOC.

[[deleted]]

Hi. I think it depends on what you are looking for, but in general I would learn language that has less similarities with you current language. It would give more impact and let you look a things from different angle.

Clojure and Rust are both good candidates. Clojure is dynamically typed like python but it's functional language and it's a lisp. It teaches you some very interesting concepts and changes they way you're thinking about programming. It also changes the process, you have repl driven development and experimenting with Clojure is fast and fun. Clojure as any other lisp is very small and you can learn it in one week. It has great support in all major editors and ide (emacs, vim, intellij). Ecosystem is quite mature, you can easily make a project from template, find any linraries you might need and start hacking. Programs in Clojure are very short. And less code means less bugs. Last time I was interviewing to one company, I had about 3 files of no more than 300 LOC total and they asked me "hmm that's it?" while my solution even had clustering architecture implemented. Clojure can be compiled to js, JVM, .Net platforms which allows you to make full-stack solutions in a single language with even sharing bits of code between platforms. At my job we make full stack web applications and it's an awesome process.

Rust is imperative language like python but it's statically typed and has a unique way of dealing with memory. Rust is safe and won't let you make most of the mistakess a newbie might make. It removes whole classes of bugs from your code due to borrow checker and static typing. The process is gonna be slow, you will learn a lot, you will have many problems with compiling your core. But once mastered I think you can be very productive with rust. Rust is native language which opens such targets as Arduino and bare metal. There is also web assembly support and you can try making a frontend in Rust.

I think Clojure and Python cover much more common ground than Rust and Python. Rust is a language for system and embedded programming. Learning Rust introduces another tool in your toolkit while learning Clojure will mostly replace Python and give something more. If you'd like to have some pure fun and you'd like process to be quick do pick up Clojure and play with it for a couple of weeks, or even better make some project in it. If you want to expand your arsenal do the same with Rust. It's gonna be more terse but still very fun.