Hacker News Reader

Comment by dan_can_code | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

I benchmarked Rusts performance on 2, 4, 8 and 16 cores on several widely used crates (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.

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.

Developers in USA: "nobody in the entire world has less than 32GB of RAM!"

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.

> 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.

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

"But for me it's way higher"

Point not comprehended.

I’m really not wild about buying a Xiaomi laptop (even though my understanding is Xiaomis stuff is all well engineered etc). People will point to the NSA doing shit but I have fairly little faith in Xiaomi devices (especially ones heading towards foreign addresses) not having nasty secret backdoors.

There is a bit of a qualitative distinction between the Lenovo backdoor stuff and that. But that’s just my personal threat model

I recently upgraded my gaming laptop to 32GB DDR4 for very cheap. It doesn’t destroy the wallet if the ram isn’t soldered and you can easily replace it. I paid about 75€ with taxes for two sticks of 16GB. I wouldn’t recommend gaming laptops as laptops though. They are terrible laptops.

How much was the gaming laptop itself though? I’m sure you can make this work of course, just curious about the base machine price

About 2000€ I think. But you can probably find a gaming laptop around 1000€ that is easy to upgrade to 32GB.

What? Laptop + 32G RAM is Laptop + 100€. With a refurbished thinkpad you can get reasonable compile times for as little as 600€.

Stop buying macbooks if you want lots of RAM and performance for a low price.

This has definitely be one big reason for me why I did not get into rust. I don’t want to have to buy a new machine just to get the compile times I’m used to

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

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.

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.

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 ;)

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.

> 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"!

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.

> 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.

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.

Your sarcasm missed the mark. You meant "static typing".

Reply on news.ycombinator.com