[troupo]

This is a very good article that doesn't shy away from downsides. Below are my personal not-so-humble opinions.

> Rust has a great developer experience. Its type system is very powerful and allows you to encode complex invariants about your system in the type system.

Usually this means: we have three people doing type-level magic, no one understands it, and when they inevitable quit no one can understand how this works and why it takes weeks to add a small change.

> Related to the previous point, the Rust community is still relatively small. It is hard to find developers with professional Rust experience.

This directly correlates with what was written previously: "Many developers enjoy working with Rust. It is the most admired language for the 6th year in a row". Enjoyment often comes from early adopters, and people trying the language for some side projects.

I'll admit, however, that Rust seems to have crossed the chasm in the adoption cycle.

> Rust has a famously steep learning curve. It is a complex language with many advanced features.

Combined with "It is hard to find developers with professional Rust experience" and "mostly training their developers on the job", stay away from it unless you know exactly what you are doing.

> more than 2/3 of respondents are confident in contributing to a Rust codebase within two months or less when learning Rust.

This is a huge amount of time. However, unclear: is this due to the language, due to being thrust into a new domain/role/job, or both.

[dpc_01234]

You can skip type system magic, and have people just keep introducing bugs that it would prevent over and over, writing more tests trying to prevent it, never quite succeeding, but overall "feeling productive" and "being agile" along the way.

Having said that - yeah, making good apis and abstractions that prevent mistakes takes time and some skill, and pays off gradually proportional to the scale and longevity of the project. And for certain things is not worth it. Being able to make a good judgment if enforcing something at the compile time / runtime / at all is worth it is part of the skill.

[troupo]

> You can skip type system magic, and have people just keep introducing bugs that it would prevent over and over, writing more tests trying to prevent it, never quite succeeding, but overall "feeling productive" and "being agile" along the way.

There's a middle ground, and I was specifically responding to the quoted bit: "Its type system is very powerful and allows you to encode complex invariants about your system in the type system."

Once people start "encoding complex invariants in the type system" it becomes an unholy mess only one or two people on the team understand. Usually an ad-hoc unspecified poorly thought-out type-level DSL dozens of level deep.

[golergka]

> You can skip type system magic, and have people just keep introducing bugs that it would prevent over and over

Personally, I found even Haskell's type system easier and nicer to use than fiddling with _lifetimes_ in Rust types. Everything else in Rust is falling nice into place, but lifetimes are painful, magical and very annoying.

[foobarian]

The survey toward the bottom was interesting; ownership and lifetimes showing up as the hardest things to learn for new users. And those are exactly the things that GC solves, or that were historically been involved in majority of security vulnerabilities.

[topspin]

The actual data toward the top was also interesting; the cost of GC is high and Rust eliminates it.

[kaba0]

The cost of GC is only high as in the cost of living in modern society is. Sure, you can technically live in the forest and build/hunt/harvest everything for yourself, but unless you have very specific reasons for that, having a house and going to the supermarket is the sane default option.

[foobarian]

Easy to learn, safe, fast: pick two

[troupo]

That also depends on GC, and the language, and the implementations of the GC.

E.g. in Erlang GC is mostly negligible [1] (but you can put undue pressure on it, and on the underlying OS), there are realtime GCs for Java, etc.

But yeah the cost of GC is never zero.

[1] citation needed

[topspin]

> That also depends on GC, and the language, and the implementations of the GC.

Nothing depends on no GC.

I'm not anti-GC. I earn most of my living using GC languages. But there comes a time when the cost of power and hardware outweigh the value of GC. When that time comes Rust is an excellent way to solve it. I am, however, very "anti" the "no such time exists" position. That has never been and will never be true.

[dinosaurdynasty]

Smaller amount of time than the equivalent in C/C++ probably.

[threatofrain]

> Usually this means: we have three people doing type-level magic, no one understands it, and when they inevitable quit no one can understand how this works and why it takes weeks to add a small change.

This is how it is in all typed languages I've used. There will always be trivial propositions which the compiler cannot check and bending around that often means ridiculous type magic. Such is the life of library & framework authors.