[tedmielczarek]

> Sounds like they could have had the same things with a much easier language like Nim. Unless they are using a lot of Rust exclusive features?

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, but it has done a lot of things right and we're not the only ones using it. There's no perfect language, they all have positives and negatives. Rust is still new enough that the ease of hiring developers can be a negative, so choosing an even younger language would further exacerbate that problem. Rust also has enough usage these days that we can get a lot of things from crates.io without having to write them ourselves. I don't know how Nim compares but it's pretty hard to get there without having enough adoption. Finally, Rust has had a bit of a trial by fire in terms of making it usable for integrating into existing codebases and shipping production code to users. I was at Mozilla and helped lead part of the Firefox Quantum work to integrate Rust into Firefox. We ran into a number of issues that we surfaced with the Rust team. Those issues generally were fixed in upstream Rust so everyone using Rust benefited from that work. I don't think that's too high of a bar for other languages to clear but it's a lot easier to recommend Rust knowing it has been through that already.

> How true is this?

I joined FullStory in December and some of my first changes to the codebase were large refactors, well before I understood how everything worked. None of them caused any major regressions that I'm aware of. My experience over 5 years of using Rust is that if you make the compiler happy you are pretty likely to have working code.

[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