Or is Rust finding a niche in userpace apps even though it was designed for systems level use? I am not saying apps shouldn't be written in Rust, I just don't understand the appeal. What am I missing?
A quick back of the paper example, I am doing Advent of Code this year and the same exact implementation took 40 ms in Rust and 350 ms in Go. Not to mention the Rust implementation, despite being the same semantically, was more concise and clear due to Rust’s extensive Iterator trait methods. A small difference you might say, but it’s just one less reason for me to switch.
Go was designed to be a language that development scales very well with it's focus on simplicity and very fast compile speed.
Rust on the other hand, was designed to make certain hard things less hard, at the cost of complexity, ease of learning, speed of development (high amount of restrictions) and compile speed. If you have a multi-million line monolith made in rust, I bet your compile speed and edit-build-run cycle will take a very long time and be very painful compared to the same golang one. Hiring will also be harder because the minimum IQ & experience bar is higher and you couldn't have productive jr engineers get up to speed on it nearly as quickly.
I agree the single file argument is not extremely convincing. Especially because engineers are often on Mac on Windows machine and compiling for Linux. While Go does support this, as soon as you have to use a c library dependency (in my experience this was sqlite), then we had to start compiling in the environment we wanted. Easy to solve with docker but deployment wasn't the reason I like Go.
I should spend some time thinking about why but overall I just "feel" more productive with Go vs Java (including Kotlin). Go's standard library, docs (with links to the source code), everything just feels super readable and understandable.
I don't see much debate agains Go using less memory. I can confirm this was my experience as well. My experience is that it uses a lot less CPU as well.
No it isn't. On many times I've been able to simplify golang code that is dozens of line long into something that is only a few lines long in Java, while improving readability and reliability. This is especially useful when exploring a new code base and spending a lot of time perusing boilerplate trying to figure out what's going on.
I’ve been working through the latest AoC in Rust and it’s been eventually very nice looking once I’ve got all the functional features used correctly, but my Go solutions from last year are also elegantly read.
The biggest difference to me is explicitly managing memory or not. This is neither an explicit advantage or disadvantage though. In some cases, it’s tremendously powerful, and in others, it’s an unnecessary cognitive load.
If you've been looking at go, it's really not much of an investment to try it out (I wouldn't heartily recommend it as I dislike the language but you do you).
rust is fantastic for building highly performant safe code at the expense of developer productivity. builds times are atrocious and tooling isn't as polished as golang.
both at great languages.
A good type system is appealing regardless of the context.
The ecosystem can also be nice (or known) e.g. serde is amazing when dealing with all sorts of serialisation schemes. The tighter resource control can also be useful for application space, and it was most certainly one of the goals for vaultwarden as complexity aside the heft of the official server was a large part of the motivation (e.g. the ability to run it on a Pi or a small VPS)
An other longer-term option is that I can imagine e.g. coding something in rust then extracting its core or bits and bobs to libraries, and exposing that in C or Python or what have you. Nowhere near as attractive (or easy) with Go.
First, thanks to default immutability of variables and the borrow checker, I trust that I'm far less likely to accidentally mutate something and cause an action-at-a-distance bug.
Second, I absolutely love idiomatic Rust error handling of returning a Result (especially combined with the question-mark operator). It forces me to deal with error conditions. Unlike C# or Python or Java or C++, I don't have to worry that any code could throw an exception at any time. (Rust code can panic, but panics generally represent unrecoverable errors — see http://joeduffyblog.com/2016/02/07/the-error-model/#bugs-are... ) And unlike Go or C, I don't have to remember to check the error every single time.
I still have to write functionality tests for Rust code, but once I've done that I feel like the code is mostly locked down. It's harder to get to that sense of security in other languages.
I just don't understand this logic. Exceptions are the same (C++ exceptions use the very same unwinding mechanism than panics in Rust as far as I can see), why would you forbid yourself to catch_unwind ? It's just making your software worse for no reason, users always will be happier with an app that shows a small "warning: internal error. Document backup saved in </some/place/>. $software will now shutdown", than seeing macOS or Windows's crash dialog.
The distinction is that panicking should (almost) never be used for recoverable errors. You can, but that's not idiomatic and would only be appropriate within the confines of your own application. Recoverable errors in Rust should be handled by return values, typically via either Result or Option.
This is unlike all the other options I listed (except Go, and C++ with exceptions disabled), where it is idiomatic to use exceptions to handle recoverable errors.
In theory, (strictly) checked exceptions are equivalent (isomorphic) to error codes as an error handling mechanism. But as soon as unchecked exceptions are allowed, it all falls apart and you must contend with the problem of "invisible control flow". Not having to deal with "invisible control flow" in Rust is one of the things that makes me much more confident that the code actually does what it looks like it does.
The Joe Duffy blog post I linked to earlier compares various error handling methods, including checked exceptions. It's very long, but interacting deeply with this blog post helped me to level up my understanding of error handling. FWIW I did a presentation on Duffy's article for the San Diego chapter of Papers We Love: https://www.youtube.com/watch?v=GwPBC4mWfFQ
I know that this is a fairly contrarian take, but I strongly believe than the emphasis on idiomatism is more harm than good. The only thing that matters is the language spec - everything that fits in there is kosher. Idioms just create pointless fights and tabs vs spaces situations where there doesn't need to be any.
> Not having to deal with "invisible control flow" in Rust is one of the things that makes me much more confident that the code actually does what it looks like it does.
no, you just choose to ignore it. I can also write C++ code with throw and no try..catch and that will give the same result (as I pretty much use exceptions like one would use panic! in rust). I don't know anyone who would say that this is a good idea. My sweet spot is to have a few catch handlers around the main loop which catch 99% of the unrecoverable issues, and sometimes, when it turns out that an issue has a way to be recovered (or that maybe it doesn't matter), then someone gets a try..catch block.
Like most articles about exceptions, that Joe Duffy post talks about the problem of "where the control flow goes". I've written my first lines of C++ something like 17-18 years ago now and not once it has actually been an issue. Consultants sure do love selling it as one though.
My response is that adherence to common idioms is simultaneously beneficial and harmful. It is beneficial because shared assumptions and shared understanding facilitate cooperation, yet it is harmful because it impedes innovation. Whether it is more beneficial or more harmful on balance depends on the situation and on individual taste.
I'd like to think that our perspectives are compatible.
> > Not having to deal with "invisible control flow" in Rust is one of the things that makes me much more confident that the code actually does what it looks like it does.
> no, you just choose to ignore it.
I guess you could characterize things that way. For example, in the Rust library code I write, I choose to ignore certain unrecoverable errors — e.g. out-of-memory panics from allocating ordinary sized objects, even though such panics can theoretically occur.
But the distinction here is that I also expect e.g. invalid argument values or "file not found" errors to be handled via Rust's Result type. I don't choose to ignore such events — I expect all recoverable errors to be handled via visible control flow, where you can identify every location in the code that such an error might occur. This makes it easier to reason about control flow for all circumstances save unrecoverable errors.
> My sweet spot is to have a few catch handlers around the main loop which catch 99% of the unrecoverable issues
Yes, that's an Anders-Hejlsberg-endorsed way of doing things. "The exception handling should be centralized, and you should just protect yourself as the exceptions propagate out to the handler." https://www.artima.com/articles/the-trouble-with-checked-exc...
I think the preference for one way of doing things can depend on what problem domain you work in. That approach is highly suitable for applications programming.
(Duffy has done a lot of work on operating systems; my biggest projects have been libraries.)
> Consultants sure do love selling it as one though.
EDIT: I'm not very happy about that take, and I originally wrote up a lengthy response — but it turns out I had incorrectly recalled that this was not the first such interaction we've had. (I was recalling an obnoxious post from a different European with the first initial "j"). I've deleted my response because it's OT and not worth dealing with if it's not something recurring.
How do you mean? I’ve been writing Rust frequently lately and you still have to check the case. Do you mean that the compiler will nag you if you stunt so you don’t have to remember to do it because you’ll be reminded?
That’s one of the things common Go linters do that I wish was built into the compiler. It’s silly that an unused dependency is a compiler error but an unchecked error/return value is not.
It's easy and idiomatic to write code which calls `unwrap`, so that's what everybody does when they don't want or need to write sophisticated error handling code. But that's not the same as forgetting to check a return value — when something goes wrong, `unwrap` panics.
I mean, if you're determined you can definitely drop an error in Rust, e.g. with a `match` arm that does nothing. But the easy path is to `unwrap`.
unwrap feels lazy, but it's obvious what is doing and it's impossible to do nothing. With go error handling is entirely optional.
How long did that take and what resources did you use to learn?
Then I started working on a personal project, which motivated me to bull through lots of difficult problems. (This personal project happens to have been bindings for Apple Core Audio, but the point is to pick something you care about enough to motivate yourself.)
Finally, I've found users.rust-lang.org invaluable.
The first major challenge for me was the error handling ("WTF is `Box<dyn std::error::Error>`? What is `Box`? What is `dyn`?"). It got in the way as soon as I even tried to write command line utilities. Once you learn it, it's amazing, but out of the gate I continually stumbled and fell flat on my face.
The second challenge was harder: coming from OOP languages, I was accustomed to structuring everything as large mutable heap-allocated classes with private fields, accessors, and an emphasis on opaque data structures and encapsulation. That is not idiomatic Rust, so I had to unlearn it and discover architectural alternatives.
I don't know exactly how long it took before I felt comfortable, since I was learning in disconnected spurts rather than immersively all at once. It wasn't quick, though.
Firefox has portions written in Rust. 1passwd, Dropbox etc...
If you use Visual Studio Code, it uses ripgrep which is built in rust.
I use Rust for most of my servers now. It's replaced Python + flask in many cases, without too big a difference in my code.
People are confused about what system programming means and a lot of that confusion comes from parts of the Rust community which want to carve out a niche for Rust and keep claiming that Rust is particularly suited to system programming, as opposed to Go or D or other languages which are in reality also capable of tackling many system programming jobs, but have a garbage collector.
Trendy enough that the very fact that rust tools happen to be written in that language is used as a main selling point.
Go is appropriate for writing services / daemons, command line tools, servers, etc. It's not well suited for writing operating system code and very performance-intensive code (databases, audio/video, etc), but there's still a big overlap with Rust.
It seems to me that this whole discussion keeps coming up because parts of the Rust community are worried about the competition. And they have reason to be :-)
but there are DBs written in go.
For a reasonable amount of locking, The Arc / RwLock dance offers good performance (other languages, like Swift, use something like Arc for every property access (although the compiler tries to optimise it away)).
The safety is actually better because you're forced to think about the failure case. I don't have good memories of Objective-C where some Foundation calls don't throw (in they don't have an error parameter), but just throw random undocumented exceptions. (Not saying that some Rust calls don't panic, but knowing that something can go wrong is much better than learning about it in production).
Which is to say, accessing a client may or may not be thread safe (depending on the client implementation) but assuming it’s not a multiplexing client, it almost certainly uses some kind of locking mechanism under the hood
Even if it is a multiplexing client, if you saturate the internal clients you will either need to wait for a client to stop writing to its socket (through perhaps a lockless consumer model) or create a new internal client (slow).
Concurrency problems don't magically disappear because your language can check for them. You still need to use memory-safe patterns, but the compiler will force your hand and prevent you from doing unsafe things accidentally.
In the end, this makes it far easier to build correct, concurrent applications. If you decide to try some fancy new pattern that doesn't require locking, the compiler can guarantee the memory safety of your new implementation.