Hacker News Reader

> I'm saying that Rust should seriously fight for the market C++ was able to actually carve out, rather than the market C++ dreamed it could have when it first gained traction

That's exactly what Rust is doing. It used to have a runtime, green threads and a GC, but it doesn't because that's not what C++ developers want. And recent development work has been focussed on const generics and const fn which are both keys things seen as missing by C++ developers.

What exactly do you mean by making "tough decisions", "fight for the market" and "make itself extremely appealing"? I've just re-read both of you messages in this thread and didn't find any single specific technical suggestion.

That's because I don't know how to do that, and it might not be purely technical. But what Rust is doing doesn't seem to be working. Six years since 1.0 and almost unheard-of levels of hype, market penetration isn't even at 0.1%. It's a language with Python-level coverage and Elixir-level adoption.

https://insights.stackoverflow.com/survey/2020#technology-pr... says that 4.8% of professional developers are using Rust.

From the perspective of someone who's been writing Rust professionally for the last few years, the hockey-stick curve started kicking in in late 2020 or so.

Not at work. The sum of those numbers is 500%, and the average developer does not use five of those languages at work (If anyone does).

Well, do you have evidence to support your claim that penetration is <0.1%? My impression is that it's simply not true now that most (if not all) of the FAANGs have many developers using it.

It's from a November 2019 report by Indeed of 0.1% of job postings mentioning Rust (https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/), with growth of 44% compared to 2018 (https://www.hiringlab.org/2019/11/26/fastest-rising-tech-ski...).

But you can even have a rough estimate according to your own measure. There are roughly between 50K and 100K developers working at FAANG (maybe replace Netflix with Microsoft). How many of them would you guess are using Rust?

Well, yes, of course. Rust is not made by Apple, MS or Google who can just make it new "official" language on their platform and force adoption. Also, by its very nature (low-level-ish language without GC) it cannot have Python-level adoption in modern software development ecosystem.

Why would you want Rust to target lowest-common-denominator developers and become new VB or php? All it needs is enough momentum to become self-sufficient, which seems to be actually happening now with Rust Foundation and news of its usage in some major companies that can set the trends for whole industry (Amazon, Google, etc.).

> Why would you want Rust to target lowest-common-denominator developers and become new VB or php?

Rust wants not that I wants. It seems people replacing NodeJS with it.

Could you please make specific claims here? Arguments that don't provide any examples are generally worse than useless.

I don't think Rust and C++ have the same level of abstraction, for example. Rust has ADTs and pattern matching, C++ only has product types and std::variant.

Abstraction doesn't mean syntactic constructs. It means the ability to specify arbitrary aspects of behaviour and then provide interchangeable implementations of the behaviour. When abstractions can have more satisfying implementations, you have high abstraction; when they have less you have low abstraction (i.e. you can abstract only smaller groups of things). Replacing, say, a concrete type with a trait is about as much work in Rust as it is in Assembly. It's not a feature of Rust specifically, but of low-level programming. If you want control over object layout, placement, and lifetime, it means that you abstract over things with specific low-level details, so fewer things. This isn't a problem, but a tradeoff that low-level programming intentionally makes, that no syntax can erase.

Yes and no. Let's drill down into this because the details are important.

There's a crucial distinction between input and output types in practice. For a given input type T, Rust makes it possible to abstract over `T`, `&T`, `Cow<'a, T>`, `Arc<T>` etc, by using a trait such as `impl AsRef<T>`.

However, Rust doesn't currently have existential types, so its ability to abstract over output types is more limited. You can implement, for example, `fn foo(&self) -> impl AsRef<T> + '_`, but you can't name that type. So if you want to return an enum, you can't write

```

enum MyEnum { MyT(impl AsRef<T>), MyU(impl AsRef<U>), }

```

Instead, you have to concretize the type somehow, either by boxing things up into a trait object (often but not always possible) or by exposing the generic param:

```

enum MyEnum<RefT, RefU> where RefT: AsRef<T>, MyU: Ref<U> { MyT(RefT), MyU(RefU), }

```

This is a real problem, though one that will be solved through existential types.

> Replacing, say, a concrete type with a trait is about as much work in Rust as it is in Assembly.

I'm not sure what you mean here. I'm not aware of any assembly languages which have traits. Replacing a concrete type with a trait tends to be pretty easy in Rust because mistakes are caught at compile time.

I agree that existential types can increase the abstraction level, but not to the level of high-level languages (and they increase generated code-size), because in the end there are still specific low-level details a lot of code needs to care about, like storage and lifetime.

> I'm not aware of any assembly languages which have traits. Replacing a concrete type with a trait tends to be pretty easy in Rust because mistakes are caught at compile time.

I'm not thinking in terms of language features but abstractions. The best way to see this is to think how many different implementations to a code unit I can do without making the consumer aware? That number is significantly lower for low-level languages compared to high-level languages because things that can be hidden in high-level languages, like layout, storage and lifetime, must not be in low-level ones, hence "low abstraction." Changing something in one place is more likely to require changes elsewhere. Therefore, low-level programs are more rigid, more jigsaw-like, and their evolution more difficult.

It is true that a compiler that tells you if you missed a change helps a lot, but it doesn't change the nature of the low-level language, even though it improves its ergonomics (although it's not so simple, as sometimes even correct programs are rejected) -- you still need to do all the extra work, but it doesn't take quite as long.