this post was submitted on 01 Sep 2025
126 points (97.0% liked)

Programming

22550 readers
234 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev

founded 2 years ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
MaungaHikoi@lemmy.nz
UlrikHD@programming.dev
126
Unix Co-Creator Brian Kernighan on Rust, Distros and NixOS (thenewstack.io)
submitted 5 days ago by who@feddit.org to c/programming@programming.dev
26 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] TheTechnician27@lemmy.world 40 points 5 days ago* (last edited 5 days ago) (5 children)

I don't know how else they could react:

And the compiler was slow, the code that came out was slow…

The compiler is slower because it has more to check for, but "the code that came out was slow" seems like nonsense, exaggeration, or PEBCAK. Rust code is highly performant and very close to C code.

The support mechanism that went with it — this notion of crates and barrels and things like that — was just incomprehensibly big and slow.

Dude what? C's build systems like cmake are notoriously unfriendly to users. Crates make building trivial compared to the ridiculous hoops needed for C.

I have written only one Rust program, so you should take all of this with a giant grain of salt,” he said. “And I found it a — pain… I just couldn’t grok the mechanisms that were required to do memory safety, in a program where memory wasn’t even an issue!

He doesn't say what the program was, and the borrow checker operates by a set of just a few extremely simple rules. There's no idea of what he was trying to accomplish or how the borrow checker impeded that.

So my reaction as someone who cares deeply about how disastrously unsafe C is and the tangible havoc it creates in modern society:

  • I agree the compiler is slower. Honestly boo hoo. It's slower for two very good reasons (better static analysis and better feedback).
  • The code being slower is such a minor issue as to effectively not be true. Benchmarks prove this.
  • I'm not going to take "big and slow" as a serious critique of Cargo from someone who idealizes C's ridiculous, tedious, convoluted build system.
  • The borrow checker is trivial, and unlike C, the compiler actually gives you easy, intuitive feedback for why your code doesn't build.
[–] _thebrain_@sh.itjust.works 16 points 5 days ago (2 children)

In my limited experience the speed a rust complied executable runs is highly dependent on compiler options. By default (from what I remember), rust includes a ton of debug info in the resulting program. With the correct compiler flags you can strip all that out and programs run very close to c speeds.

[–] mitchty@lemmy.sdf.org 16 points 5 days ago (2 children)

The default for cargo is debug builds why that would surprise anyone as being slower is beyond me, —release isn’t that much extra to type or alias. Do people not learn how their tools work any longer? This isn’t that far off from c/c++ where you set cflags etc to fit the final binaries purpose.

[–] FizzyOrange@programming.dev 4 points 5 days ago (1 children)

Tbf this mistake comes up so often I do wonder if cargo should have defaulted to release builds. It seems to be what beginners expect.

[–] nrab@sh.itjust.works 4 points 4 days ago (1 children)

Gcc, clang, msvc, and all the other compilers also don’t optimize by default. It’s very normal and very expected for the default build to not include optimizations

[–] FizzyOrange@programming.dev 0 points 4 days ago

Sure but you don't normally run GCC or Clang directly; you make, and that normally does optimise. I think a closer example is CMake which doesn't enable release mode by default.

MSVC is usually run from Visual Studio which makes it obvious which mode is being used so the default doesn't matter so much.

As for "all the other compilers", Go optimises by default. It does seem to be the exception though...

[–] gravitas_deficiency@sh.itjust.works 0 points 5 days ago* (last edited 5 days ago)

Yeah honestly this does smack of PEBKAC/RTFM

[–] Ephera@lemmy.ml 6 points 5 days ago

Yeah, cargo build produces a debug build and cargo build --release is for actually distributing to users. (It doesn't add the debug symbols, but also spends more time optimizing.)

[–] Ephera@lemmy.ml 11 points 5 days ago

The support mechanism that went with it — this notion of crates and barrels and things like that — was just incomprehensibly big and slow.

Dude what? C’s build systems like cmake are notoriously unfriendly to users. Crates make building trivial compared to the ridiculous hoops needed for C.

I wouldn't be surprised, if the guy does not normally use a build system to begin with. Professors don't tend to have the time to write software that would require a build system (both in terms of complexity and being used by end users).

So, I'm guessing, all he wanted was rustc, but most Rust tutorials don't bother explaining it, because cargo isn't much harder to use.

[–] unique_hemp@discuss.tchncs.de 7 points 5 days ago

Off the top of my head the compiler is slow because:

  1. With C you can compile every file in parallel, in Rust compilation of a single crate is serial (hence splitting up large projects into many crates is important, but that makes development somewhat more difficult)
  2. LLVM itself is pretty slow
  3. Generic functions are monomorphized (there's a unique machine code version of it for every concrete type combination they are called with) to improve runtime performance, but that gives LLVM a lot more work to do - see point 2
[–] FizzyOrange@programming.dev 6 points 5 days ago

It’s slower for two very good reasons (better static analysis and better feedback).

Apparently that's not really the reason. cargo check is usually quite fast.

I also wouldn't say Rust code is slower than C. It wins in some places (e.g. strict aliasing) and loses in others (e.g. bounds checks) but in practice it's usually much faster because it's so much easier to use fast containers (not just linked lists everywhere), fast libraries, and multithreading.

[–] tracyspcy@lemmy.ml 5 points 5 days ago

No language guarantees high-speed code. Rust, like C and C++, is also perfectly suited for writing slow code