Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

While true, not everyone can afford a gamming rig just for using a compiled language, so this hurts adoption.


Gaming rigs cost is mostly GPU. Compilers love cores, ssd, ram in that order.

Gaming rig is not great for compiling. And vice versa.


It was an example of the kind of compute power, of course we can get pedantic on which hardware.


You're overestimating the budget needed for the rig. Would working with a Windows 7 era laptop and Rust suck? Yes. But so would anything else.

I'm on a 4-year-old PC, granted it's 5900X, 3800 MHz RAM and my numbers are derived from it.


Quite far from the typical i5 most folks have access to on shopping malls.


Even i5 will only make it around twice as slow[1]. So from 5min -> 10min.

And that's a relatively pessimistic scenario - huge number of dependencies, slow processor (i5), fresh build. In incremental build, it goes from minutes to seconds.

[1]https://youtu.be/utWSSlyabjc?t=798


My M1 from ~4 years ago still rips through compiles. shrug


Outside wealthy countries Apple hardware isn't really an option.


I am yet to see an example of a full-time Rust developer in a poor country who can't afford Apple hardware.


See, gatekeeping right there.

How did that lucky person become a full time Rust developer, and landed a job paying Apple level of income, in first place?


Wait a bit longer?

https://xkcd.com/303/

I'd argue that gatekeeping here is being done by the "Rust requires overpowered hardware" position you're assuming. I happily use an RPi4.


When there are alternative that require waiting less, those alternatives eventually get more eyes.


Sure, all else being equal. That's why we all write LISP right? No compile times.


maybe we could use ai to optimise compilers somehow.


The reason rustc and other compilers like it (e.g. GHC) are "slow" isn't because they are unoptimized; it's because they do A LOT of work!

rustc is enforcing a strong and expressive type system, checking for ownership, generating code from macros, etc. It will always be an order of magnitude slower than C/C++ compiler, kind-of by design.


Large C++ projects aren't exactly known for their stellar compile times either.

Coming from a C++ background, I don't find Rust compile times to be that bad for comparable sized projects in C++.


Which is exactly why we traditionally don't build the world from scratch in C++, rather rely on binary libraries for 3rd party dependencies, or component frameworks.

Additionally rely on dynamic libraries during debug builds.


Incremental build times in rust are also on par (and often faster) with c++ on the similar sized projects I’ve worked on.


Except those other compilers offer multiple toolchains, including interpreters, that are faster than rustc.

Standard ML, Idris, ..., F#, Haskell and OCaml have interpreters, and REPLs, in addition to the full blown AOT compilation.

Naturally Rust can also have those, however they aren't here today.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: