Hacker News Reader

That talk is https://www.youtube.com/watch?v=YX3iRjKj7C0.

> Fundamentally, Haskell did not clearly solve any particular problem with other languages. There are a lot of cool things you can do in Haskell, and arguably, there are problems in other languages that aren't issues in Haskell. But the advantages of Haskell were never as clear cut as Rust

I agree with you 100%

Did C++ kill C? Will Rust kill C++?

I think Haskell wasn't there to replace anything except maybe Standard ML, and you could say it won that one.

Rust is trying to be a better C++. And it addresses C++ issues directly in ways that are relatable to C++ programmers.

Similarly for Go, it really appeals to the Java croud that wants less patterns, less verbosity, more simplicity and especially that want lower memory footprint, fast startup times and simple deployments and delivery. It appeals to the Python croud that want better performance and to use what Google uses, etc.

I think in that sense, I see languages that take hold are those that directly address some of the pain points of other popular languages. Another great example of this is TypeScript.

And I'd say, that language cannot change everything that is familiar in doing so. You got to keep around a good 70% from the language that is popular, and with that 30% you can replace with something that fixes major pain points from it.

I think when you look at Rust it does that regarding C++, it purposely stayed close to the syntax.

And when I think of Haskell, it didn't do that. It wasn't trying to address the biggest pain points of everyday programmers in some other existing popular language. It was trying to be a whole new thing, an evolution of an already niche paradigm. It didn't meet anyone 70% of the way unless you were an ML programmer.

Now Squeak I find much more interesting, because it seem like it could have blown up, I mean Smalltalk too, not sure what happened, even Sun was working on Self, and the Java, Java won. I think it was due to performance at the time.

> Rust is trying to be a better C++. And it addresses C++ issues directly in ways that are relatable to C++ programmers.

Just as importantly, it's trying to be a better C++ and it addresses C++ issues directly in ways that are relatable to non-C++ programmers.

For devs used to higher level languages, C++ is horrifying, it's a footgun wrapped in grenades, with an internet as full of legacy bad advice as VBA. Rust is a promise that you can get C++-type performance without blowing your foot off or falling into a million traps along the way unless you really want to.

Managed scripting languages you mean, C++ is quite high level and managed languages like Swift, D and C# offer similar concepts.

> Managed scripting languages you mean

No. I mean what I wrote.

> C++ is quite high level and managed languages like Swift, D and C# offer similar concepts.

Languages like Swift and C# have memory safety and automated memory management by default, unlike C++. They also don't have C++'s unique blend of language features mis-interacting with one another in rather deadly way.

Just because C++ is unsafe by default that doesn't make it less high level.

Languages like Swift and C#, or even Rust, while safe by default do also have their gotchas, do expose unsafe code capabilities, and when an application crashes or panics in the middle of a critical workflow, it is deadly no matter how it came to happen.

Specially deadly in the age of thin runtime libraries, that requiring installing half of the Internet for each basic dependency, without any sort of control quality.

For example, Rust libraries that make use of unsafe just because the authors gave up on writing the code in a proper way, but n levels deep on the whole dependency chain.

Still, it makes testing and finding bugs much easier, because you can relatively easily ensure correctness of the safe part of code, and unsafe parts get visible.

It's not as potent as say Isabelle/HOL prover or top of SML or SPARK Ada, but much easier to write, and safer than Java at memory management in practice.

(Where you get to write very thick foreign interfaces with no way to even try to make them safer, and cannot control memory allocation manually easily.)

A decent balance.

> many companies have already started building core infra in Rust. Facebook with Mononoke, Libra, Eden, and Hack. Dropbox for storage servers. Mozilla with Firefox.

You missed Amazon, Google, the Linux kernel, Microsoft, Apple, ... which big company isn't using Rust at this point in production?

The main difference between Rust as Haskell is that, while I really like doing competitive programming with Haskell, what I really like doing with Rust is shipping products to customers.

In my free time, I don't use Rust, right now I mostly use Idris2. But the main reason I can do that is that since we moved from C++ to Rust, nobody really call us on the weekend anymore to fix something that can't wait till monday.

> nobody really call us on the weekend anymore to fix something that can't wait till monday

I'm freakin sold, gonna learn rust now.

The Linux kernel isn't using Rust in production. They've said they're open to the possibility, but that isn't even a start.

All our linux kernel module and driver development have been using Rust for a while. I've written a Linux kernel module in Rust that we use in production, and so have many others.

What the Linux kernel is discussing is how to integrate these kernel modules and drivers into the Linux tree. They are not discussing whether this is worth doing, but how to do it. Linux is quite stable if you stick to the right APIs, and maintaining these out-of-tree is not too bad, but the current situation is not sustainable in general.

For us it doesn't matter, because our code is not open source. But it matters to quite a bit of people.

Sure, but out-of-tree third party modules and drivers is not what the comment I replied to said.

> Google, ... which big company isn't using Rust at this point in production?

I worked with C++ at Google recently. I didn't see any push to switch to rust and I don't know of a single production server running rust binaries.

Edit: The best evidence that Google doesn't use rust in production is that they don't have an official protocol buffer implementation in Rust. Until they have that nobody will use it for servers at Google.

https://developers.google.com/protocol-buffers/docs/cpptutor...

You're assuming a specific kind of deployment. Google does more than servers. Currently, the big known projects are:

1. in ChromeOS, via crosvm (they collaborate with rust-vmm with Amazon, who originally forked crosvm for Firecracker)

2. in Fuchsia, whose employees also have helped significantly with the language and implementation on company time

3. Smaller projects, like sponsoring some font tooling work

Additionally, the Chrome team has a branch with Rust code in it and they're evaluating it currently. We'll see.

why is there no source? What is the point of comments like this if it doesn't have source?

It should be easy enough to google. So I didn't bother.

* ChromeOS: https://chromium.googlesource.com/chromiumos/platform/crosvm...

* Fuchisa: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master... (I picked this bit sort of at random because it talks about a bunch of stuff)

* https://raphlinus.github.io/rust/druid/2019/10/31/rust-2020.... ("Runebender is generously supported financially by Google Fonts, for which I am very grateful, as it makes it more of a serious and professional project.")

* Chrome: https://chromium-review.googlesource.com/q/project:experimen...

This is as direct of links as I can give, but there's a ton of commentary around all of these topics; they've been covered on HN before, even.

> You missed Amazon, Google, the Linux kernel, Microsoft, Apple, ... which big company isn't using Rust at this point in production?

You could have said the same thing about Haskell (hell, you could even say MS invented Haskell, or at least MS research people, fwiw) . It's absolute meaningless. Big companies have many projects and in random languages.

I never get called to fix stuff on weekend unless I get a nice pay check for my weekend going bust, no matter what language we get to use, so is the beauty of union agreements affecting everyone across the company.

That’s nice of course, but I’d argue that not getting called at all is still better.

Did you threaten them that you would change languages again if they called you over the weekend?

> Fundamentally, Haskell did not clearly solve any particular problem with other languages.

Marketeers have a saying: "Its a lot easier to sell asprin than vitamins."

In other words, if someone says "This is giving me headaches" then someone with a solution for that headache will find it a very easy sale. But if your product pitch is that your general health will improve, your immune system boosted, yada yada, that's a much harder sale to make.

For Haskell original purpose it is hugely successful. It is a fantastic language to test new ideas and for functional language research. Think about how big of an impact it has had on languages like C#, Scala, Kotlin, and Swift.

SPJ has said Haskell's motto has always been "avoid 'success at all costs'", so it's perhaps unsurprising they're not concerned with industrial applicability, which doesn't mean it's particularly dead in the water or anything for other uses.

Also, just going off the substitutions, Ruby is alive and well with a major release on the horizon, many top startups got their start with it and the community is still growing. If Rust is the new Ruby, it should be pretty damn happy about it.

Ruby is nothing compared to its original hype bubble.