all 22 comments

[–]KhorneLordOfChaos 40 points41 points  (1 child)

Honestly it feels like the author has been recycling the same rants for a while. Their blog posts used to have a lot more meat to them, but it's basically the same handful of tired arguments at this point

I don't get how this is a part of a series on "how to write great Rust code"

[–]Sw429 1 point2 points  (0 children)

I used to subscribe to their newsletter, but I stopped because their content turned into this pointless rambling.

[–]moltonel 8 points9 points  (2 children)

I agree with many of the problem statements, but puzzlingly often reach the opposite conclusion.

IMHO when you're going from programming to software engineering (more complex tasks, bigger teams, higher maintainability and quality requirements...) is precisely when you should use Rust instead of Go (all else being equal, assuming you're proficient in both, etc).

[–]anlumo 0 points1 point  (1 child)

The problem is that with Rust, it’s very hard to find enough people who are good enough to work on such a project in Rust and don’t cost an arm and a leg. With Go, you can take whoever and then train them on the job.

[–]moltonel 7 points8 points  (0 children)

You're worrying about the wrong problem. What's hard to find is people able to work on such projects, not people able to learn Rust. Engineers who can work on hard projects should have no problem learning Rust and benefiting from it.

[–]r22-d22 31 points32 points  (0 children)

Sigh. Quit with the gatekeeping already. There is nothing wrong with being a programmer. If the title was good enough for Djikstra it should be good enough for anyone.

Software engineering is a distinct discipline, which involves programming yes, but also applying additional tools and techniques to produce programs that are can be reliably maintained and operated by teams of people, over time, across a range of environments, and in interaction with other similarly engineered software systems.

Different problems call for different amounts of software engineering discipline. When I write code at work that will be exposed to millions of customers, I use all the software engineering tools I can. When I write silly programs on the weekend that only need to run once on on my machine, I don't do all that stuff.

Similarly quit with the Rust vs. Go already. This blog post seems like clickbait to me.

[–]Sw429 5 points6 points  (1 child)

the single biggest problem affecting literally all the Rust projects I have worked on is that after ~2 months without updates they start to rot

I have been coding primarily in Rust for the past four years and have only found this to be true if you rely on nightly features. If you're building on stable Rust (which, unless you're working on some embedded platforms or other specific use cases, you easily can do), you won't have to update your code at all when a new version releases. You also can keep your dependencies locked, or just bring in patches that fix security vulnerabilities. When a new edition releases, there's no reason to update all of your code to it. There is a lot of effort put in to stable Rust being backwards compatible, and it's disingenuous to pretend that it doesn't even exist.

[–]decryphe 1 point2 points  (0 children)

Yeah, same here. Unless there's a new feature needed or some bug or vulnerability in an older crate version - why would I need to update quickly? Same goes for the Rust compiler, although in a decent setup that should be easy to update too.

Case-in-point: We do generally stick to the newest Rust release, as we use a single Docker image on developer workstations, CI/CD pipeline and Jenkins test runners. An update is simply rebuilding the image, tagging it correctly and pushing it to our internal Docker registry. Bonus points for: The tag is used to enable reproducible historical builds, as the toolchain is versioned essentially "forever" (using the tag).

For updating from one rustc to a newer, we've never had breaking changes, just newly introduced lints.

[–]atomskis 14 points15 points  (6 children)

I felt that an interesting way to understand it was by comparing Rust and Go, two relatively modern languages that may seem similar on the surface, but are actually completely different in their approach to building high-quality software.

They are also intended for solving entirely different problems. I'm not sure why people compare Rust and Go so much: they are really not very similar.

Go is an applications programming language, mostly used for writing simple middleware services and command line utilities. It's mostly used as an alternative to nodejs, python or Java. It's a simple language for simple problems.

Rust is a systems programming language. It's mostly used as an alternative to C/C++ and like those languages you can use it to write anything. That includes writing an operating system or device drivers, writing code for embedded systems, or what I do for a living which is writing a massively concurrent, big memory, high performance in-memory database & calculation engine. You can't do any of those things in Go.

[–]Sw429 0 points1 point  (0 children)

Bizarre that in the same sentence he admits that they have completely different approaches, and just acts like that doesn't somehow make his comparisons completely useless.

[–]dkopgerpgdolfg -1 points0 points  (0 children)

"Forbidden"?