Unix Co-Creator Brian Kernighan on Rust, Distros and NixOS (thenewstack.io)
from who@feddit.org to programming@programming.dev on 01 Sep 19:16
https://feddit.org/post/18221137

#programming

threaded - newest

SpaceNoodle@lemmy.world on 01 Sep 19:41 next collapse

I wonder how the Rustaceans will react to his honest criticism.

Edit: exactly how I expected, LOL

ExLisper@lemmy.curiana.net on 01 Sep 20:26 next collapse

‘”I have written only one Rust program, so you should take all of this with a giant grain of salt,”

I will listen to his sound advice and not take it very seriously.

Solemarc@lemmy.world on 01 Sep 20:28 next collapse

What honest criticisms did you find in this article? All I saw was;

  • compiling is slow
  • borrow checker is complicated

This isn’t new?

floofloof@lemmy.ca on 01 Sep 20:33 collapse

He said the code that came out was slow, but Rust always ranks within the top handful of languages for speed, so I’m taking that comment with a big pinch of salt. Among popular systems languages only C and C++ really beat Rust for speed. So you get better memory safety for the price of a pretty small decrease in speed and a steeper learning curve for the compiler’s picky rules (though the compiler gives you lots of clear help). Rust programmers know this.

TheTechnician27@lemmy.world on 01 Sep 20:42 next collapse

I’d go even further: the learning curve for Rust is shallower than C/C++.

  • C is obvious: dealing with strings is a goddamn nightmare in pure C, and strings are used all the time in modern programming. Almost no guardrails for memory safety mean that an inexperienced programmer can easily run into undefined, nondeterministic behavior that makes bug hunting difficult.
  • In C++, there’s a trillion ways to do anything (which varies enormously based on C++ version), and when you make mistakes of even moderate complexity (not “missing semicolon on line 174”), compilers like gcc spit out a gargantuan wall of errors that you need to know how to parse through.
  • Rust, in my experience, gives you a much clearer “good” way to do something with some room for expression, and its compiler tells you exactly what you did wrong and even how to resolve it.

The fact that the compiler actually guides you, to me, made learning it much easier than C/C++.

tetrislife@leminal.space on 02 Sep 03:28 collapse

By the vague looks of it, he has tried Rust for something he would use C for. His impression of Rust’s utility in that domain seems unsurprising.

Beyond that

I used to not question why we build anything other than “system software” in C/C++. Once I questioned that, I quickly got past the “Why not Ada/D/etc.” stage and reached the “why is so much of large software written in mid-level languages” stage. For anything bigger than, say, a Unix CLI tool, it probably is, and has always been, wrong to use anything at the level of C (C++, Ada, D, Nim, Rust, Zig, etc.).

This choice of language level for “application software” seems to be a commercial choice. The software commons is using such languages probably because contributors want to hone their job-oriented skills. It got better with Python and Ruby uptake in open projects. But, efficient, safe but simple languages, say, OCaml and Erlang, have been available for decades. Crystal is also looking good right now.

Ephera@lemmy.ml on 02 Sep 04:22 collapse

My guess is that he was using cargo build rather than cargo build --release. Relatively common for folks to complain about due to that, because beginner tutorials tend to skip that info (which is fair IMHO).

TheTechnician27@lemmy.world on 01 Sep 20:33 next collapse

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.
tracyspcy@lemmy.ml on 01 Sep 20:53 next collapse

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

_thebrain_@sh.itjust.works on 01 Sep 22:18 next collapse

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 on 02 Sep 01:07 next collapse

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.

gravitas_deficiency@sh.itjust.works on 02 Sep 04:44 next collapse

Yeah honestly this does smack of PEBKAC/RTFM

FizzyOrange@programming.dev on 02 Sep 06:41 collapse

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.

Ephera@lemmy.ml on 02 Sep 04:11 collapse

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 on 02 Sep 04:09 next collapse

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.

FizzyOrange@programming.dev on 02 Sep 07:11 next collapse

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.

unique_hemp@discuss.tchncs.de on 02 Sep 08:11 collapse

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
ISO@lemmy.zip on 02 Sep 02:44 collapse

People stopped taking Brian seriously when he helped create Go. That was pre-Rust.

Even the “talking points” here seem to be re-used from “Go vs. X” ones. Also, his experience speaks of someone who only tried Rust pre-v1.0.

Anyone who actually knows Rust, anti- or pro-, knows that what he said (partially in jest) is factually wrong.

Feel free to prove otherwise, especially the part about the performance of Rust programs. Don’t be surprised if he simply didn’t pass –release to cargo build, a common pitfall for someone in the “hello world” stage of trying Rust.

And this is why appeal to authority was never more fallacious, considering we live in a world where Dunning-Kruger is a universal reality.

thingsiplay@beehaw.org on 02 Sep 02:44 next collapse

I just rewatched an interview with Kernighan / on SkipVideos that is 5 years old. Back then he was experimenting with Rust a bit and wanted to go back. I’ll watch this new presentation or interview at UNIX: A History and a Memoir by Brian Kernighan / on SkipVideos later, so cannot comment here about the content at the moment.

And wow, I did not notice he was already 83 years young! And still teaching. Imagine your teaching being B. Kernighan.

vga@sopuli.xyz on 02 Sep 05:20 next collapse

The way this article was written was weirdly sycophantic. It’s like the meme where “everybody stood up and applauded” but in this case it happened every 5 minutes.

Well, I hope anyone will care what I think when I’m 83.

beeng@discuss.tchncs.de on 02 Sep 09:54 collapse

What was said on nixos? Tldw

rozodru@piefed.social on 02 Sep 11:10 collapse

he said he never heard of Nix or NixOS. that's it. it's a dumb article that just poorly sums up a few youtube videos of his talk.

TehPers@beehaw.org on 02 Sep 17:25 collapse

This. It’s just like “this dude is cool” and some fun Q&A and circlejerking, which is fine, but he probably should not be used as a credible source for understanding younger stuff.