Is life too short to fight Rust's borrow checker?
kerkour.com
kerkour.com
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.
Rust 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.
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.
The problem is async not the borrow checker. Async adds a lot of incidental complexity
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
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.
The learning curve is a fixed tax for a recurrent return.
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
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.