[echelon]

> I admit that I don't have more than a passing familiarity with Nim. Rust certainly isn't the only language targeting this niche nowadays

Don't let the Nim folks fool you. Nim isn't targeting the same space as Rust. It's garbage collected.

Nim could see success in challenging Python or Golang, but Rust is rather uniquely positioned to go after bare metal (C, C++), yet have the ergonomics one would expect from Java, Python, Go, etc.

Rust is going to eat everything.

[estebank]

Just pattern matching and destructuring being in the language from 1.0 makes Rust a much different beast ergonomics wise than Java, Python and Go. It makes it different than Scala even, as it feels more cohesive to me.

There are many things that could be done to make Rust easier at the cost of bare metal semantics, which is why they aren't done, but I am quite happy with the current state of the language and even with those tradeoffs I agree that Rust has great chances of "taking over" a wide range of spaces that are currently dominated by specific technologies.

[aaron-lebo]

Rust absolutely does not have the ergonomics of any of those languages because it has lifetimes. They are things you don't worry about in those languages.

Have you done a lot of Rust? I spent considerable time in Rust, and at the end of the day, after stepping away from it, I've found multiple options with the kind of ergonomics that make development a lot more productive for me.

Rust is not going to eat everything. I'd bet money on it. Rust will likely un quietly behind the scenes powering lots of great projects, but its audience is limited. I think HN really has a weak spot for understanding how few people even know what it is. I was surprised to ask a CS grad student that's done lots of machine learning about Rust, and he simply didn't know it existed. I like Rust and all that it taught me, but we need to be realistic about its ceiling and what it is appropriate for.

[mlindner]

> Rust absolutely does not have the ergonomics of any of those languages because it has lifetimes. They are things you don't worry about in those languages.

You have to worry about them in any non-garbage collected language. There's just no compiler that checks that you're doing it correctly and is the primary source of security bugs for most software.

[aaron-lebo]

Understood. To be specific, they said Rust has the ergonomics of Python, Go, and Java, which are garbage collected languages. It does not strike me as realistic.

[Scarbutt]

I don't see how can Rust be more ergonomic than Python, can you elaborate? A data scientist doing some analysis is not concerned with memory safety, why will he waste his time fighting the compiler?

[FullyFunctional]

If "fighting the compiler" means less "debugging the app at runtime" then I'd take the former any day.

Rust (like Haskell) has a much richer language for accurately modelling and enforcing the value domain.

[steffan]

> positioned to go after bare metal (C, C++), yet have the ergonomics one would expect from Java, Python, Go, etc.

The point wasn't that it has better ergonomics than Python, it's that it has similar ergonomics, while being a bare-metal type language.

[pjmlp]

Companies like PTC don't have an issue with GC languages on C and C++ domains, https://www.ptc.com/en/products/developer-tools/perc

[tedmielczarek]

I don't think there's a bright line dividing systems programming problems between GC and non-GC languages. We use Go extensively at FullStory and it works great for a large class of problems. Rust has a compelling story for spaces where GC makes life harder or just isn't feasible. I will say that Rust being usable without GC does seem to put it in a better position around interoperability than languages with a GC, since composing language runtimes and GCs properly is a really challenging problem.

[jstimpfle]

You know what's a really challenging problem with GCs? COPYING MEMORY