I think it is, especially for higher level software. People are rewriting I/O bound applications from garbage collected languages and the top two reasons they cite are performance and memory safety - it's just peak stupidity.
Rust isn't even that popular yet and already more people are using it than actually need to.
I sometimes feel like I'm taking crazy pills happily toiling away in F#. Am I missing the boat or am I on it? Or maybe it is me lamenting the idea that languages like Rust get all this mindshare to create interesting libraries. There are lots of interesting languages out there for all sorts of purposes, but as far as I can tell, F# is the sweet spot of general purpose language design. My only wish is a very similar subset of the language for embedded programming, and no, that isn't Rust.
(I love Elixir as well, but it definitely gets a lot of attention and isn't as general purpose.)
Honestly I think your observation is mostly right... if you don't have a hard performance requirement, then rust probably isn't the best language to write your code in...
I agree that, if your main reaction to the various approaches Rust supports is "why do I need all this?" that's a sign of a mismatch between your engineering goals and the functionality the language is providing.
Either just pick an option and it will be fine (b/c rust is fast and has good checks) or pick another language that makes the choice for you and it will be fine because the compiler made the choice you did not want to.
> But I really don't understand why people use Rust for scenarios that a GC language works.
This entire article's thread is littered with generalizations without context/nuance so you're probably right. I don't think most people could rationalize it beyond those usecases. Especially considering 90% of us on HN are building SaaS and business software or stuff unrelated like games/data science. Maybe even more than 90%.
For the rest of us doing non-Rust applicatiable software to pay ou4 bills GC by default and Rust where it matters is more than sufficient. And usually the Rust part means libraries since we can't all have dedicated dudes doing optimization type software.
I've said it before, you must really hate your employer if you're migrating from high level languages to Rust.
If you want a sure fire way to make sure hiring costs more, development progresses slower, and time that would otherwise spent on delivering business value is instead spent on engineering rigor, move that Java monolith to Rust today.
(to be clear, this isn't an indictment of Rust, it's simply the idea of going from established high level languages to any unmanaged language)
I’ve experienced two startups choosing Rust. The main slowdown factor is that everyone is a Rust novice and are not highly productive from day zero. In both cases, prototypes are built with Python to sketch out architecture and not limit the design phase. It feels like bamboo scaffolding being replaced with reinforced concrete once the company has developed the skills and the models.
In the case of these two startups, their main domains were cryptography and embedded. You can’t just pick a language like Java, C# or Python. The strategically safe alternative here is C/C++. I’m happy they chose Rust; it was a deciding factor for me when choosing between two embedded jobs.
I choose to not respond to everything, because it's not all constructive.
You don't choose Rust because you hate your employer.
You don't choose Rust to make development go slower.
I'm not sure what the definition of "unmanaged language" is, and how Rust ends up being one.
There are reasons to choose Rust when you could have chosen another language as well.
For example: I worked for a company built on PHP and TypeScript. They had a stable cashflow, but the performance of the apps was down the drain (poorly made, poor technology), but the money was there. Gradually refactoring the busy parts in a performant language by competent programmers would solve the scaling problem. Choosing a popular and performant language would ensure new hires. A solid choice here would be C# or Java. Rust would be another option: it attracts qualified candidates, and you don't need to experiment much with the software design and architecture.
> This is complete non-sequitur.
Just because I'm responding to your comment, it does not mean that what I say should logically follow from what you said. I'm adding information.
You didn't "not respond to everything", you didn't respond to anything.
> Just because I'm responding to your comment, it does not mean that what I say should logically follow from what you said. I'm adding information.
You didn't even understand the comment, this reply goes and misconstrues a bunch of things it said again
People tend to not like it when you put words in their mouths. If you're out of your depth no one is asking you to flounder in an attempt to "add information"
>and time that would otherwise spent on delivering business value is instead spent on engineering rigor, move that Java monolith to Rust today.
Oh no. I would hate more engineering rigor at the cost of business value! Please, anything but that. After all, that's why I majored in business instead of CS.
This mentality is why the industry is having layoffs.
You should have stayed in academia if you didn't want to worry about business value.
No field is exempt from the need to balance the two. We could make planes safer by making them cost 100x as much and then no one would be able to afford to fly. The difference between an ok engineer and an exceptional engineer is being able to pull your head out of the weeds and realize no piece of engineering exists in isolation.
> I think it is, especially for higher level software. People are rewriting I/O bound applications from garbage collected languages and the top two reasons they cite are performance and memory safety - it's just peak stupidity.
One failure mode I see lead to this in JS is that sometimes you have a program that is usually IO bound but certain paths are CPU eaters. If the CPU eating workload is entirely synchronous this interacts badly with the event loop architecture because there's no scheduler (at the JS level) to interrupt the workload and handle outstanding IO work. My guess is that many devs are unable to diagnose this issue correctly and jump straight to Rust.
The sweet spot for Rust in high level software really seems to be using it in small doses. My shop is 99% JS but just a little bit of Rust in the right places gamechanger: millions of savings in cloud spend, big UX improvements on key workflows, new architectural capabilities. I don't know if we would have taken the plunge with C++ for most of those cases out of fear of the potential operational issues.
Nowadays it is easy to mix in Rust in higher level languages. If there are certain critical paths only those paths can be rewritten in Rust or offloaded to a separate process.
With 10 Gb Ethernet and NVMe SSDs, I/O bound doesn’t mean what it used to. 10 Gb Ethernet and NVMe SSDs can expose the garbage collected language as the bottleneck pretty easily.
Well, for one, Rust doesn't. And I think you mean data races and not race conditions, or at least race conditions with regards to data/memory access. I don't know of a language that prevents race conditions.
In Elixir and Erlang, mutating data is impossible, so those. A language like F# makes it easy to avoid race conditions as well, but it is possible if you use classes or the mutable keyword. Even then, you will not corrupt memory and are only having race conditions in terms of the order in which data is accessed. But is rarely a problem with a functional first approach. I never even need to use a debugger with F#.
Any language with asynchronous computations will have race condition surface area, but there are several high-level languages that makes this difficult.
The only ones I can think of with literally none[0] of those problems use a shared-nothing concurrency model. Usually, that's fine -- downright pleasant, even. Occasionally, it's a real problem to accomplish something in a shared-nothing environment.
[0]- Well, assuming "race conditions" means "data races". Obviously no tooling can prevent race conditions in general.
I experienced similar headaches without async code. I always need helper functions to let me open a file and work with the contents. It seems like I always need new variants depending on what operations I'll do inside 'f', e.g:
pub fn with_vec_align<A,V>(file_name: &str,
f: &dyn Fn(&[V]) -> A) -> A
pub fn with_vec_align_mut<A,V>(file_name: &str,
f: &mut dyn FnMut(&[V]) -> A) -> A
pub fn with_vec<A>(file_name: &str,
f: &dyn Fn(&[u8]) -> A) -> A
fn with_vec_mut<A>(file_name: &str,
f: &mut dyn FnMut(&[u8]) -> A) -> A
pub fn with_mut_vec<A, V>(file_name: &str,
f: &dyn Fn(&mut [V]) -> A) -> A
It's the kind of thing I'd hope polymorphism would solve (maybe it already does but I just don't know how to leverage it).
It’s a shame that swift isn’t brought up more often in conversations around Rust and borrow checker mental overhead. From what I understand swift gets pretty close to the rust model (and even closer with some of the newer move and ownership proposals) without imposing as much on developers (especially folks that want to deal with slightly higher level programming).
The sooner you find bugs, the less time/effort/money you spend in the maintenance bit of the SDLC fixing them.
Rust's borrow checker actually saves you time by flagging up memory bugs upfront, the same way a statically typed language's type checker saves you time by flagging up type bugs upfront.
> call it a day, finish work early and go to the beach for sunset.
That's great, except if you're on call, responsible for your own and your team's code. Hopefully, there are no NullPointerExceptions, ConcurrentModificationExceptions, not to mention the odd race condition or two. I appreciate a language that can eliminate the majority of these cases at complie time. I'd rather sort these issues out on a Tuesday morning than get pulled off the beach by PagerDuty.
I was expecting more to the article than those few lines. This, along with most rust pieces that get posted here, can be answered by if your code needs to be performant or not. Not everything is just a CRUD web app and using rust for everything obviously isn't a silver bullet
40 comments
[ 2.4 ms ] story [ 91.3 ms ] threadRust isn't even that popular yet and already more people are using it than actually need to.
(I love Elixir as well, but it definitely gets a lot of attention and isn't as general purpose.)
By the way, do you mind pointing to where else it was mentioned?
Either just pick an option and it will be fine (b/c rust is fast and has good checks) or pick another language that makes the choice for you and it will be fine because the compiler made the choice you did not want to.
But I really don't understand why people use Rust for scenarios that a GC language works.
This entire article's thread is littered with generalizations without context/nuance so you're probably right. I don't think most people could rationalize it beyond those usecases. Especially considering 90% of us on HN are building SaaS and business software or stuff unrelated like games/data science. Maybe even more than 90%.
For the rest of us doing non-Rust applicatiable software to pay ou4 bills GC by default and Rust where it matters is more than sufficient. And usually the Rust part means libraries since we can't all have dedicated dudes doing optimization type software.
Or maybe I'm biased cuz I work for Startups.
If you want a sure fire way to make sure hiring costs more, development progresses slower, and time that would otherwise spent on delivering business value is instead spent on engineering rigor, move that Java monolith to Rust today.
(to be clear, this isn't an indictment of Rust, it's simply the idea of going from established high level languages to any unmanaged language)
In the case of these two startups, their main domains were cryptography and embedded. You can’t just pick a language like Java, C# or Python. The strategically safe alternative here is C/C++. I’m happy they chose Rust; it was a deciding factor for me when choosing between two embedded jobs.
I plainly state that this is about when you CAN choose other languages.
> to be clear, this isn't an indictment of Rust, it's simply the idea of going from established high level languages to any unmanaged language
How hard is it to read a whole comment before writing this many words in response?
I choose to not respond to everything, because it's not all constructive.
You don't choose Rust because you hate your employer.
You don't choose Rust to make development go slower.
I'm not sure what the definition of "unmanaged language" is, and how Rust ends up being one.
There are reasons to choose Rust when you could have chosen another language as well.
For example: I worked for a company built on PHP and TypeScript. They had a stable cashflow, but the performance of the apps was down the drain (poorly made, poor technology), but the money was there. Gradually refactoring the busy parts in a performant language by competent programmers would solve the scaling problem. Choosing a popular and performant language would ensure new hires. A solid choice here would be C# or Java. Rust would be another option: it attracts qualified candidates, and you don't need to experiment much with the software design and architecture.
> This is complete non-sequitur.
Just because I'm responding to your comment, it does not mean that what I say should logically follow from what you said. I'm adding information.
> Just because I'm responding to your comment, it does not mean that what I say should logically follow from what you said. I'm adding information.
You didn't even understand the comment, this reply goes and misconstrues a bunch of things it said again
People tend to not like it when you put words in their mouths. If you're out of your depth no one is asking you to flounder in an attempt to "add information"
I won't take more of your time; your duty calls.
https://xkcd.com/386/
Oh no. I would hate more engineering rigor at the cost of business value! Please, anything but that. After all, that's why I majored in business instead of CS.
You should have stayed in academia if you didn't want to worry about business value.
No field is exempt from the need to balance the two. We could make planes safer by making them cost 100x as much and then no one would be able to afford to fly. The difference between an ok engineer and an exceptional engineer is being able to pull your head out of the weeds and realize no piece of engineering exists in isolation.
One failure mode I see lead to this in JS is that sometimes you have a program that is usually IO bound but certain paths are CPU eaters. If the CPU eating workload is entirely synchronous this interacts badly with the event loop architecture because there's no scheduler (at the JS level) to interrupt the workload and handle outstanding IO work. My guess is that many devs are unable to diagnose this issue correctly and jump straight to Rust.
The sweet spot for Rust in high level software really seems to be using it in small doses. My shop is 99% JS but just a little bit of Rust in the right places gamechanger: millions of savings in cloud spend, big UX improvements on key workflows, new architectural capabilities. I don't know if we would have taken the plunge with C++ for most of those cases out of fear of the potential operational issues.
With 10 Gb Ethernet and NVMe SSDs, I/O bound doesn’t mean what it used to. 10 Gb Ethernet and NVMe SSDs can expose the garbage collected language as the bottleneck pretty easily.
In Elixir and Erlang, mutating data is impossible, so those. A language like F# makes it easy to avoid race conditions as well, but it is possible if you use classes or the mutable keyword. Even then, you will not corrupt memory and are only having race conditions in terms of the order in which data is accessed. But is rarely a problem with a functional first approach. I never even need to use a debugger with F#.
Any language with asynchronous computations will have race condition surface area, but there are several high-level languages that makes this difficult.
[0]- Well, assuming "race conditions" means "data races". Obviously no tooling can prevent race conditions in general.
This is closer to Python’s philosophy if you ask me.
> while you think your program is off working as intended but isn't.
:P
The problem is async not the borrow checker. Async adds a lot of incidental complexity
Rust's borrow checker actually saves you time by flagging up memory bugs upfront, the same way a statically typed language's type checker saves you time by flagging up type bugs upfront.
That's great, except if you're on call, responsible for your own and your team's code. Hopefully, there are no NullPointerExceptions, ConcurrentModificationExceptions, not to mention the odd race condition or two. I appreciate a language that can eliminate the majority of these cases at complie time. I'd rather sort these issues out on a Tuesday morning than get pulled off the beach by PagerDuty.
The learning curve is a fixed tax for a recurrent return.