Hacker News Reader

Comment by jvanderbot | Hacker News Reader

There are some influential fair comparisons of compiled languages, but for the most part my feeling is that people are moving from an extremely high level language like Python or JS, and then going to Rust to get performance, when any single compiled language would be fine, and for 90% of them, Go would have been the right choice (on backend or web-enabled systems apps), there was just a hurdle to get to most other compiled languages.

It's just Rust is somehow more accessible to them? Maybe it's that pointers and memory just was an inaccessible / overburdensom transition?

View on HN

Rust is the only mainstream language with an ergonomic modern type system and features like exhaustive matching on sum types (AFAIK... maybe I'm forgetting one). Yes things like OCaml and Haskell exist but they are much less mainstream than Rust. I think that's a big part of the appeal.

In Go instead of having a value that can be one of two different types, you have to have two values one of which you set to the zero value. It feels prehistoric.

That strikes me as an incredibly niche (and probably transient) strength! But I will remember that.

It's not niche at all; it's extremely common to need this. Maybe I'm not explaining it well. For example, an idiomatic pattern in Go is to return two values, one of which is an error:

  func f() (SomeType, error) {
          // ...
  }

In Rust you would return one value:

  fn f() -> anyhow::Result<SomeType> {
      // ...
  }

In Go (and similar languages like C) nothing enforces that you actually set exactly one value, and nothing enforces that you actually handle the values that are returned.

It's even worse if you need to add a variant, because then it's easy to make a mistake and not update some site that consumes it.

To be fair even Java solves this problem with checked exceptions. It forces you to handle them or pass them on. It's really just C++ and C# that have a bit of wild west error handling.

My point has nothing specifically to do with error handling, that was just the first example that came to mind.

> Rust is the only mainstream language with an ergonomic modern type system and features like exhaustive matching on sum types (...)

This reads like a parody of Rust's fandom.

Sorry, what other mainstream language has this feature? I supposed TypeScript does, but we were talking about compiled languages.

Swift does apparently, here's an example from ChatGPT

    enum Animal {
        case dog(name: String)
        case cat(name: String)
        case bird

        func sound() {
            switch self {
            case .dog(let name):
                print("\(name) says Woof!")
            case .cat(let name):
                print("\(name) says Meow!")
            case .bird:
                print("Tweet!")
            }
        }
    }

and another with nesting

    enum Thing {
        case first(x: Int)
        case second
    }

    enum Outer {
        case ok(Thing?)
    }

    let value: Outer = .ok(.some(.first(x: 42)))

    switch value {
    case .ok(.some(.first(let x))):
        print("Matched with x = \(x)")
    case .ok(.some(.second)):
        print("Matched .second")
    case .ok(.none):
        print("Matched .none")
    }

Cool, and Swift is indeed a mainstream language, so fair enough that my original claim wasn't quite correct.

I still think it's a meaningful reason for Rust's popularity, though, given that Swift isn't used much outside of the Apple ecosystem.

> I still think it's a meaningful reason for Rust's popularity, though, given that Swift isn't used much outside of the Apple ecosystem.

If this is a meaningful reason for popularity, why is the Rust the only popular one with it (aside from Swift's popularity within the Apple ecosystem)? Shouldn't we expect other languages, those which have been relegated to the non-mainstream (including Swift outside of the Apple ecosystem), with the same feature to also be popular?

I expect Rust is popular simply because it did well in its marketing. You can't go anywhere in tech circles without seeing an advertisement for it. Which plants the seed for when the next time someone is "I think I'll try a new language"; Rust is first in mind. Swift is a great language. It would be perfectly suitable option for someone to pick up as a new language technically, but since it is effectively never advertised outside of certain Apple developer-focused venues... Case in point: You didn't even think to think of it here, and understandably so.

Scala, Kotlin and even modern Java.

> It's just Rust is somehow more accessible to them?

Going to lower level languages can be scary. What is 'fighting the borrow-checker' for some, may be 'guard rails' for others.

Not sure how much it weighs on the balance in those types of decisions. But Rust has safe concurrency. That's probably quite a big boost of web server quality if anything else.

Go's concurrency is unsafe? Rust's concurrency is automatically safe?

I am not saying you're wrong, I just don't find it any better than C++ concurrent code, you just have many different lock types that correspond to the borrow-checker's expectations, vs C++'s primitives / lock types.

Channels are nicer, but that's doable easily in C++ and native to Go.

> Go's concurrency is unsafe? Rust's concurrency is automatically safe?

Yes and yes...

Rust statically enforces that you don't have data races, i.e. it's not possible in Rust (without unsafe hacks) to forget to guard access to something with a mutex. In every other language this is enforced with code comments and programmer memory.

As long as that something is in the process's own memory.

Correct, rust doesn’t magically prevent all bugs. It just makes a large class of bugs harder to write.

.. but most concurrency is done in distributed systems, where Rust provides little to no protection.

Although making a Rust monolith would be great!

(Un)safe is a bit of an overloaded term but Rust's concurrency model is safe in the sense that it statically guarantees that you won't have data races. Trying to mutate the same memory location concurrently is a compile-time error. Neither C++ nor Golang prevent you from doing this. Aside from that

With the caveat that those data races are related to in-process memory being accessed by threads.

Which is quite good, but leaves out shared memory with other processes, or threads having data races with external resources, while corner cases they are quite common in distributed computing scenarios.

You've been really obsessed by this for a long time and I'd be interested to understand if there's some specific trigger, something weird you're doing where this seems to you like it's a data race, because I have never seen anywhere that I was like "oh, I guess this is a data race" when there's unsynchronized access across process boundaries.

Because it is touted as an universal truth "Fearless Concurrency" of how Rust beats all languages, when in reality it only applies in a very specific use case, that in the world of distributed systems it isn't even the main one we care about in regards to concurrent and parallel access to data.

So its supremacy above anything else is kind of relative, and always left of out context.

See I don't buy that it's not "the main one we care about". What kind of insane software is expecting Sequential Consistency for shared mutable data across processes? That's what I still don't have a clear picture of. I think what I've seen here is merely a race condition, which is just not a big deal.

Humans can't reason about data races because they're contrary to our normal understanding of the world, but an ordinary race condition isn't like that. Earlier I saw there was the nice cheese at the grocery store, but I wasn't sure if they had fresh bread so... I kept walking, when I reached the bread aisle I bought bread and then I went back but nope, somebody else bought the last of the nice cheese. Oh well. Race condition.

Well then Fearless Concurrency should be sold in a proper way.

In modern times the network is the computer.

But it is fearless Concurrency. If you're worried about race conditions that's not a concurrency problem that's how the universe you were born in works.

Again, no computers involved in my food shopping (well, not the part I described anyway) but there's a race condition, because that's how the universe works. Rust can't magically change how the universe works. Whereas Data Races are something very strange, and Rust can just outlaw those.

As long as it is in-process data without external factors changing it, but we are running in circles here.

I guess, I just don't buy that it's confusing/ surprising that Rust can't change the laws of physics.

Decades ago a friend wrote a software "Time Machine" (this was long before Apple's backup software) which just buffers all the audio inputs so you could do the same thing with the computer in their studio as on their Sony Mini Disc recorder - if you hit "record" it records the sound you just heard, even though that sound happened before you hit the button, because it's a mains powered piece of kit it can just buffer a few seconds of PCM samples in a loop and so it does.

Sony invented that tech because it's necessary to how the device actually works anyway (it has lossy audio compression inside it, which needs a buffer) and it's useful, so, why not. The "Time Machine" software is of course not actually a time machine, but never did any users or prospective users say "Hey, that's misleading, it's not actually a time machine, those would require a change to the laws of physics". It's just audio software, duh.

The fact fearless concurrency doesn't protect you from the dangers of race conditions is no different from how it doesn't protect you from say mob violence. Those both sound bad, but I wasn't expecting the programming language to magically fix either of them.

Reply on news.ycombinator.com