Hacker News Reader

Author here, I tried to write this article to be as non-biased as possible, though it was pretty difficult.

Most discussions and sources online compare Rust to easy targets, like C, C++, or Python, so we never get to really dive into the more interesting comparisons against stronger languages (especially GC'd ones). There are also some studies out there that try to measure Rust, but they measure the kinds of complexity that wouldn't translate to real-life coding.

I actually like Rust (it's probably my favorite mainstream language today besides Scala), and if you consider all the dimensions together, there are a lot of situations where Rust is the best choice. However, this article is about one specific dimension (developer velocity) and on that, Rust unfortunately has some drawbacks.

Also, the article does mention situations (concurrency) and aspects (encourages top-down, flattened architectures) that give Rust some advantages.

I tried to be un-biased. Perhaps it didn't quite show, also since the conclusions recommended languages other than Rust when focusing on developer velocity.

I mean, that's OK to express criticisms on Rust developer velocity (for instance, I totally agree that Rust doesn't particularly shine for prototyping) but then you've assembled from various parts of the internet a collection of TWENTY-ONE testimonials from people complaining about developers velocity in Rust, and not a single one of people praising Rust for the productivity boost it offers, though I can definitely assure that there are, especially for refactoring where Rust is commonly considered[1] to be first class.

Collecting pain point can be useful for the language, as it helps the Rust team to get a better vision of what they can improve, but doing such a one-sided list in an article about comparison to other languages and memory handling mechanism is at best dubious.

> Most discussions and sources online compare Rust to easy targets, like C, C++, or Python

My background is mostly Java then JavaScript and you can quote me on the fact that I found Rust to be more productive than both of them in average, especially when the project last more than a few weeks. The biggest underlying reason is different though, JS mostly suffering from dynamic typing + overall questionable language and “standard library” design, while Java is plagued by inheritance and dubious OOP patterns. When using both of these languages after Rust I also felt frustrated by the impossibility to assign strong ownership to objects, making sure they aren't being watched or mutated behind my back. Also, billion dollar mistake.

[1]:by rustaceans that is, it's not an objective measurement of any kind, but we're talking about testimonials here.

Like I mentioned in response to your other comment about this, the anecdotes were added to the borrow checking sections because that's what the initial readers were surprised about. That in turn made those sections longer. I also did mention the benefits of borrow checking (such as the concurrency benefits and influencing us into cleaner architectures), plus the downsides of garbage collection.

I didn't need any anecdotes for the borrow checker's benefits because everybody already knows them. I see how that can seem biased though, and next time I add citations to the surprising parts of an article I'll also add them more uniformly to the rest of the article as well.

Also, the article was about garbage collection itself versus borrow checking itself, not any specific languages that use them.

You make some valid comparisons between Rust and Java and Javascript, but garbage collected languages don't need to be dynamically typed, and don't need to have null, and don't need to have OOP patterns. When you compare Rust to a more modern language like Scala or Pony, you get a much truer comparison of the approaches.

That's what the article is really comparing: borrow checking versus garbage collection. Not the extra features that are correlated with them in mainstream languages.

Cheers!

Is biased and incorrent in a few places, like disregarding system programming languages with GC that also support deterministic destruction of resources.

I'm not surprised: when you read something and the part you know about is bullshit, there's a good chance that the part you don't know about is also bullshit even you can't see it.

What language have both GC and deterministic destructors, and how does it works? I'd guess it couldn't be tracing GC (because the GC runs whenever it wants, so you don't have determinism, or at least that's my understanding). Or maybe it's something like RAII for non-memory resources (with a destructor that doesn't free memory), and a GC for memory management?

Mesa/Cedar, Modula-3, Active Oberon, D, Nim, for example, not to make an exhaustive list. C# also does provide some mechanisms to dive into it, since version 7, although not as easy.

Basically you can use GC heap as usual, or native heap with untraced references, stack or global memory segments.

Value types with constructors/destructors pairs are also supported.

So you have all the building blocks to do C++ style RAII when needed, otherwise relax and enjoy the GC.

thanks

This article was mainly about memory safety approaches (GC, RC, borrow checking, etc) and their effects on development velocity. It wasn't trying to compare all languages along all dimensions. That would be quite a long article!

Anyway, I think you're referring to `defer`? Though perhaps you're referring to something else, as defer also appears in non-GC'd languages as well so it didn't seem like a very relevant factor in this specific comparison. I do agree that defer (and try-with-resources) can be stellar tools for GC'd languages.

Nope, I am referring to C++/Ada style of RAII.

I believe Rust will ALWAYS be beneficial compared to MMM languages because it will save time in the long run.

Programs with Rust will always be rock-stable, unlike many C/C++ programs which are more like a house-of-cards.

I'd agree with that too, but that's just my point of view and I'd respect anyone else's sensible argument of the opposite.

But this article isn't that, and to make manual memory management more appealing they had to ridiculously inflate the issues that come with ownership-based memory management…

I think it's you being biased against the article now. As I read it, it was pretty honest and really trying to find some sort of true, not just trying to bash Rust. Feels like Rust fans are very defensive against criticism of any sort, even when well intentioned as I think is the case here.

Come on, there's literally 21 citations[1] of people saying Rust slows them down, and ZERO citation of the opposite.

There's not trying to hide that they are biaised, at this point it's Kremlin-level of shameless bad faith.

[1] it looks like they've harvested Rust criticism for an entire year at this point, since they end up even quoting random discord comment from more than a year ago: https://discord.com/channels/273534239310479360/818964227783...

Author here, I tried to make this article as balanced as possible, and even talked about Rust's advantages in concurrency and encouraging cleaner architectures and the disadvantages of MMM and GC approaches (plus other aspects, see my other comment down-thread about this).

There are actually 45 citations in the article on all angles, but I think you're talking specifically about the anecdotes.

Regarding the anecdotes, I had to add more of those to the borrow checking sections because it was the most surprising to my initial readers. Very little discussion online actually compares borrow checking to higher-level languages with good development velocity; most discussion online compares it to languages like C, C++, Javascript, or Python, so this was new to most readers.

The article also explicitly mentioned that those were anecdotes and colored them differently, so that people didn't mistake them as data.

They also made that part of the article much longer than it was originally.

I can see how that could come across as biased. Perhaps I should have added citations to the other parts of the article so their distribution was more uniform.

When you look at the content itself, it's pretty balanced I'd say (hence the focusing on the other benefits of borrow checking plus the downsides of GC), it's unfortunate that's not coming through as much.

Yeah, the issue is that you've given so much room for critical citations that your article is basically a pamphlet at that point.

It may slow them down during their initial development when they're new to Rust, but I'm convinced that it will be much cheaper during the entire Application Lifecycle (ALM), not to mention customer satisfaction.

> Programs with Rust will always be rock-stable

How do you know that? Is there any data backing that up?

I've never seen any research showing that a programming language, no matter how strict (Haskell, Ada, Rust) actually improves the reliability of software, except for comparisons between memory-safe and non-memory-safe languages. It almost always goes down nearly entirely to development process and team skills/experience, showing anything else convincingly would be a huge breakthrough.

Well, here's my point of anecdata: despite Python being a very productive language and very easy to use, despite it existing for more than three decades and being perhaps the most massively learned language by aspiring programmers today, you hardly see any stand-alone application written in it. I can name not a single application that I use on a daily basis written in Python. It seems it's strongly confined to the web-server, where the environments are well controlled via containers, runtime bugs impact a single page load and fixes can be applied continuously. People don't ship Python standalone apps.

Based on the buggy and unstable Python desktop apps I have used, I have a strong suspicion that developing large applications in Python is strongly self-limiting after the initial sprint.

I'm speaking from my own experience here. I've tested a couple of Rust programs which were developed in relatively short order yet were quite complex (a Minecraft type game being one) and there wasn't even the slightest hint of instability.

Some of my own Rust code is moderately complex but never showed any signs of instability during development. I often have crashes now and again with my C++ programs. Sure, I fix those afterwards but getting it flawless every time the first time is (for me at least) unheard of.

The borrow checker only prevents certain classes of memory bugs. You can definitely still have logical bugs in Rust.

Logical bugs are out of scope for any programming language.