7 ms·

As a front-end developer dabbling with rust, the compiler being slow is not a problem for me. Whilst I appreciate the benchmark, it's not likely I'll have 72GB

As a front-end developer dabbling with rust, the compiler being slow is not a problem for me. Whilst I appreciate the benchmark, it's not likely I'll have 72GB of ram laying around to speed up the process. Yes, hot module reloading is nice and quick. But it reloads with errors included. The primary benefit of the rust compiler, at least from my point of view, is telling me what's wrong, where. It's a worthwhile sacrifice for a few seconds of my time, when at the end of addressing all of the obvious errors, I have something that works. I find this miles better than HMR.

Starlevel004 2y ago
> The primary benefit of the rust compiler, at least from my point of view, is telling me what's wrong, where. Incredible! Rust developers have invented "IDEs"!
- dan_can_code 2y ago
  I'm not sure if you're familiar with front-end developer tooling or the development process, but my editor will not tell me what error a browser is going to throw.
  - flohofwoe 2y ago
    > but my editor will not tell me what error a browser is going to throw And so won't Rust, a runtime error is a runtime error after all. But even Typescript has pretty good control flow analysis which catches a lot of (what would be) JS runtime errors while typing when properly integrated with an IDE. It's not like Rust invented static typing, it just has a very strong type system (which can quickly become an annoyance though, that's why there's a wide range of 'strictness' among statically typed languages, because while static typing is generally a good thing, a 'too strong' type system might not be.
    - pjmlp 2y ago
      Somehow I see a trend on developers educated in scripting languages and using either Go or Rust as their first compiled languages. Apparently they invented static linking, pattern matching, structural typing, unsafe keyword, and plenty of other stuff already present on compiler toolchains and type systems that predate them... I wonder if we will ever sort out the issue of developers caring about programing language history, or operating systems for that matter. I mean in the wider sense, not the geeky community that already does that as a hobby.
- boxed 2y ago
  Your sarcasm missed the mark. You meant "static typing".
boxed 2y ago
I use Elm at work, and the confidence from really strict compilation and typing is very worth it. With that said, Elm is super fast to compile too, which is very nice.
pjmlp 2y ago
I have a couple of projects where it is measured in minutes, on a dual core with 8GB and a SSD. If only devs with beefy machines are able to use Rust properly, that hinders adoption.
- guappa 2y ago
  Developers in USA: "nobody in the entire world has less than 32GB of RAM!"
  - rtpg 2y ago
    Laptop + 32 gigs of RAM is a recipe for destruction of your wallet. At least for desktops you can kind of scope things out, but companies aren't really in the practice of distributing desktops anymore it seems.
    - jakderrida 2y ago
      > Laptop + 32 gigs of RAM is a recipe for destruction of your wallet. While I'm not a developer of any sort, you couldn't be more on the nose here. I waited and waited for a Surface Laptop that has 32gb on ebay. When it came, price skyrocket to almost double the 16gb model. Twice more it happened and I literally gave up and bought the 16gb. I don't know what the retail premium from Microsoft is, but the reseller premium is truly insanity. Surely, Microsoft spent the time engineering it to fit 32gb and could reap more producing more of them.
    - virtualritz 2y ago
      I have the 2022 model of this machine [1] which is a macBook Pro clone from Xiaomi. It's an absolute beast, build quality is almost on par with Apple (screen is better than what Apple offered in 2022, actually) and the 32GB RAM base model from this year can be had for less than 1,000€. I dunno where the "destruction of your wallet" threshold lies for you but for me it's way higher. The 2022 version also used Ryzen APUs and there is excellent Linux support. It's my daily driver for Rust development (I run Pop!_OS on it). [1] https://a.aliexpress.com/_EygTDml https://a.aliexpress.com/_EygTDml
oefrha 2y ago
You’re a front end developer but you don’t need to make small tweaks all the time? “At the end of addressing all of the obvious errors, I have something that works.” is irrelevant to large swaths of front end code, which is basically always in a “working” state (displays something without error), but needs to be continuously expanded and refined. TFA talks about reload times of 20-30s before their optimization, on a powerful computer. It’s certainly not “a few seconds” especially for people on less powerful hardware. That’s a ridiculous wait time for, say, tweaking a CSS class. I find this comment highly suspect.
- dan_can_code 2y ago
  JavaScript errors only occur at runtime. It's very common, especially in legacy codebases, for issues to just fly under the radar, even if they are obvious to the seasoned dev. There is a reason why one of the most popular JS books is called 'Javascript: the good parts'. With rust, it's very refreshing in that it's idiot proof, which JavaScript is not. CSS is not relevant, since it is not actual programming.
  - oefrha 2y ago
    We (at least the author and I) are talking about front end development here where most reloads are tweaking markup and stylesheets and shouldn’t introduce any error. And half a minute or longer reloads are unacceptable for those. I don’t need a lecture on the history of JavaScript, thank you. Especially since JavaScript/TypeScript has come such a long way that JavaScript the Good Parts is barely relevant anymore. > Rust… idiot proof That’s such a… interesting statement that I’m not going to respond further.
  - spookie 2y ago
    CSS is actual programming. Nevertheless, he was just stating a common case where one iteratively checks if their assumptions, even if carefully accounted for, conform to their expectations. Another, very real "programming" situation could be the following: correctly parsing 3D mesh information in a multithreaded fashion and pass that to your preferred API of choice. Is one going to get all edge cases right the first time? Is your program's codebase large enough? Eventually it becomes kinda yucky having to wait. The compiler may know what is programmatically correct, not what your intention is. I think that's what the other person was trying to argue. I'm not too concerned about compile times myself, I'm used to them given I mostly dabble with compiled languages (I do a lot of CSS though!), but there's a argument to be made about iteration time and being fast in solving a problem.
nindalf 2y ago
I benchmarked Rusts performance on 2, 4, 8 and 16 cores on several widely used crates (https://arewefastyet.pages.dev/ https://arewefastyet.pages.dev/). Performance generally improved with the number of cores, but memory made no difference. All of these crates topped out at around 1GB and additional memory didn’t improve performance. So no, 72GB or 128GB makes no difference.
b33j0r 2y ago
Working on a couple of ideas that flip that logic on its head, but you’re more likely to be right because of finite time. The thing about rust is that the overhead is all upfront. Not to be sacrilegious, but bleeding at the move or &wtf borrow boundary is a price one pays to have confidence, subsequently. Your cms/customer acronym probably doesn’t need it, but you’ll love the —fast option in some stacks that merely means “compile the rust extension.” Plus… it’s a gainful hobby. I’m fine if other people have hobbies that don’t resemble x86 in 1998 on slackware ;)
- b33j0r 2y ago
  I will never understand who hated my innocent and light-hearted thought that much. Hope it was worth making me go, “aw” for no reason.
doubloon 2y ago
People are impatient. I expect in a few years someone will”solve” this problem by removing the borrow checker and then by removing the unsafe keyword, then allowing dynamic linking and shared libraries…. And this person will be lauded as a genius. And some group of cranky bitters will make a new language with a new borrow checker,,,, cycle repeats
- pkolaczk 2y ago
  The borrow checker is not responsible for even 1% of compilation time. The elephant in the room is monomorphisation and macro expansion. Those generate a ton of code that LLVM has to process. In return you get much faster programs at runtime.

Starlevel004 2y ago

> The primary benefit of the rust compiler, at least from my point of view, is telling me what's wrong, where. Incredible! Rust developers have invented "IDEs"!

dan_can_code 2y ago
I'm not sure if you're familiar with front-end developer tooling or the development process, but my editor will not tell me what error a browser is going to throw.
- flohofwoe 2y ago
  > but my editor will not tell me what error a browser is going to throw And so won't Rust, a runtime error is a runtime error after all. But even Typescript has pretty good control flow analysis which catches a lot of (what would be) JS runtime errors while typing when properly integrated with an IDE. It's not like Rust invented static typing, it just has a very strong type system (which can quickly become an annoyance though, that's why there's a wide range of 'strictness' among statically typed languages, because while static typing is generally a good thing, a 'too strong' type system might not be.
  - pjmlp 2y ago
    Somehow I see a trend on developers educated in scripting languages and using either Go or Rust as their first compiled languages. Apparently they invented static linking, pattern matching, structural typing, unsafe keyword, and plenty of other stuff already present on compiler toolchains and type systems that predate them... I wonder if we will ever sort out the issue of developers caring about programing language history, or operating systems for that matter. I mean in the wider sense, not the geeky community that already does that as a hobby.
boxed 2y ago
Your sarcasm missed the mark. You meant "static typing".

boxed 2y ago

I use Elm at work, and the confidence from really strict compilation and typing is very worth it. With that said, Elm is super fast to compile too, which is very nice.

pjmlp 2y ago

I have a couple of projects where it is measured in minutes, on a dual core with 8GB and a SSD. If only devs with beefy machines are able to use Rust properly, that hinders adoption.

guappa 2y ago
Developers in USA: "nobody in the entire world has less than 32GB of RAM!"
- rtpg 2y ago
  Laptop + 32 gigs of RAM is a recipe for destruction of your wallet. At least for desktops you can kind of scope things out, but companies aren't really in the practice of distributing desktops anymore it seems.
  - jakderrida 2y ago
    > Laptop + 32 gigs of RAM is a recipe for destruction of your wallet. While I'm not a developer of any sort, you couldn't be more on the nose here. I waited and waited for a Surface Laptop that has 32gb on ebay. When it came, price skyrocket to almost double the 16gb model. Twice more it happened and I literally gave up and bought the 16gb. I don't know what the retail premium from Microsoft is, but the reseller premium is truly insanity. Surely, Microsoft spent the time engineering it to fit 32gb and could reap more producing more of them.
  - virtualritz 2y ago
    I have the 2022 model of this machine [1] which is a macBook Pro clone from Xiaomi. It's an absolute beast, build quality is almost on par with Apple (screen is better than what Apple offered in 2022, actually) and the 32GB RAM base model from this year can be had for less than 1,000€. I dunno where the "destruction of your wallet" threshold lies for you but for me it's way higher. The 2022 version also used Ryzen APUs and there is excellent Linux support. It's my daily driver for Rust development (I run Pop!_OS on it). [1] https://a.aliexpress.com/_EygTDml https://a.aliexpress.com/_EygTDml

oefrha 2y ago

You’re a front end developer but you don’t need to make small tweaks all the time? “At the end of addressing all of the obvious errors, I have something that works.” is irrelevant to large swaths of front end code, which is basically always in a “working” state (displays something without error), but needs to be continuously expanded and refined. TFA talks about reload times of 20-30s before their optimization, on a powerful computer. It’s certainly not “a few seconds” especially for people on less powerful hardware. That’s a ridiculous wait time for, say, tweaking a CSS class. I find this comment highly suspect.

dan_can_code 2y ago
JavaScript errors only occur at runtime. It's very common, especially in legacy codebases, for issues to just fly under the radar, even if they are obvious to the seasoned dev. There is a reason why one of the most popular JS books is called 'Javascript: the good parts'. With rust, it's very refreshing in that it's idiot proof, which JavaScript is not. CSS is not relevant, since it is not actual programming.
- oefrha 2y ago
  We (at least the author and I) are talking about front end development here where most reloads are tweaking markup and stylesheets and shouldn’t introduce any error. And half a minute or longer reloads are unacceptable for those. I don’t need a lecture on the history of JavaScript, thank you. Especially since JavaScript/TypeScript has come such a long way that JavaScript the Good Parts is barely relevant anymore. > Rust… idiot proof That’s such a… interesting statement that I’m not going to respond further.
- spookie 2y ago
  CSS is actual programming. Nevertheless, he was just stating a common case where one iteratively checks if their assumptions, even if carefully accounted for, conform to their expectations. Another, very real "programming" situation could be the following: correctly parsing 3D mesh information in a multithreaded fashion and pass that to your preferred API of choice. Is one going to get all edge cases right the first time? Is your program's codebase large enough? Eventually it becomes kinda yucky having to wait. The compiler may know what is programmatically correct, not what your intention is. I think that's what the other person was trying to argue. I'm not too concerned about compile times myself, I'm used to them given I mostly dabble with compiled languages (I do a lot of CSS though!), but there's a argument to be made about iteration time and being fast in solving a problem.

nindalf 2y ago

I benchmarked Rusts performance on 2, 4, 8 and 16 cores on several widely used crates (https://arewefastyet.pages.dev/ https://arewefastyet.pages.dev/). Performance generally improved with the number of cores, but memory made no difference. All of these crates topped out at around 1GB and additional memory didn’t improve performance. So no, 72GB or 128GB makes no difference.

b33j0r 2y ago

Working on a couple of ideas that flip that logic on its head, but you’re more likely to be right because of finite time. The thing about rust is that the overhead is all upfront. Not to be sacrilegious, but bleeding at the move or &wtf borrow boundary is a price one pays to have confidence, subsequently. Your cms/customer acronym probably doesn’t need it, but you’ll love the —fast option in some stacks that merely means “compile the rust extension.” Plus… it’s a gainful hobby. I’m fine if other people have hobbies that don’t resemble x86 in 1998 on slackware ;)

b33j0r 2y ago
I will never understand who hated my innocent and light-hearted thought that much. Hope it was worth making me go, “aw” for no reason.

doubloon 2y ago

People are impatient. I expect in a few years someone will”solve” this problem by removing the borrow checker and then by removing the unsafe keyword, then allowing dynamic linking and shared libraries…. And this person will be lauded as a genius. And some group of cranky bitters will make a new language with a new borrow checker,,,, cycle repeats

pkolaczk 2y ago
The borrow checker is not responsible for even 1% of compilation time. The elephant in the room is monomorphisation and macro expansion. Those generate a ton of code that LLVM has to process. In return you get much faster programs at runtime.