Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

24 days of Rust – Rayon

siciarz.net

Post reply on HN
Print view View original

61–66 of 66 posts

Re: 24 days of Rust – Rayon

#61

Post by sixbrx »

StevePerkins wrote: post #43
lukaslalinsky wrote: post #4

I have not done any real programming in Rust, but whenever I see Rust code I'm amazed how different is it from Go, despite both having some shared use cases. Go's main selling point beyond concurrency is simplicity. And it's the simplicity that I like about it. On the other hand, it looks to me like Rust is turning into Scala.

Are there really a lot of "shared use cases" between Rust and Go? I realize that Go's creators intended for it to be a systems language. In practice though, it has found its niche in web apps or microservices, and command-line apps in the DevOps world. Rust is primarily aimed toward real-time applications that can't tolerate garbage collection latency. Of course they're both general-purpose languages in theory. But i…

> "nearly every Rust thread is has people taking shots at Go"

Often resulting from "this is so much more complicated than Go, why bother?" prodding as seen in lukaslalinsky's post above, at which point those "shots" are just asked-for information.

Re: 24 days of Rust – Rayon

#62

Post by kazagistar »

StevePerkins wrote: post #43
lukaslalinsky wrote: post #4

I have not done any real programming in Rust, but whenever I see Rust code I'm amazed how different is it from Go, despite both having some shared use cases. Go's main selling point beyond concurrency is simplicity. And it's the simplicity that I like about it. On the other hand, it looks to me like Rust is turning into Scala.

Are there really a lot of "shared use cases" between Rust and Go? I realize that Go's creators intended for it to be a systems language. In practice though, it has found its niche in web apps or microservices, and command-line apps in the DevOps world. Rust is primarily aimed toward real-time applications that can't tolerate garbage collection latency. Of course they're both general-purpose languages in theory. But i…

It's a unidirectional feud because Rust isn't limiting itself to C++ use cases. As the Async and other library infrastructure falls into place, why not use Rust for webapps, microservices, and command line tools? Just because it is suited for 0-overhead, high safety, with high level abstractions does not mean it's unsuited for these other things; or at least we don't know yet exactly.

On the other hand, Go is aware of its limitations, and thus has no need to fire any shots back, so to speak.

Re: 24 days of Rust – Rayon

#63

Post by steveklabnik »

kazagistar wrote: post #62
StevePerkins wrote: post #43

Earlier quoted context omitted.

Are there really a lot of "shared use cases" between Rust and Go? I realize that Go's creators intended for it to be a systems language. In practice though, it has found its niche in web apps or microservices, and command-line apps in the DevOps world. Rust is primarily aimed toward real-time applications that can't tolerate garbage collection latency. Of course they're both general-purpose languages in theory. But i…

It's a unidirectional feud because Rust isn't limiting itself to C++ use cases. As the Async and other library infrastructure falls into place, why not use Rust for webapps, microservices, and command line tools? Just because it is suited for 0-overhead, high safety, with high level abstractions does not mean it's unsuited for these other things; or at least we don't know yet exactly. On the other hand, Go is aware o…

I (and the rest of the team) don't really see it as a feud at all. There's always room for more languages, and we're fundamentally pluralists. There is no reason at all that Rust and Go can't or shouldn't coexist just fine.

Re: 24 days of Rust – Rayon

#64

Post by saghm »

iamed2 wrote: post #51
saghm wrote: post #41

Earlier quoted context omitted.

Because I'm one of the only people passionate about Rust at my job (and there are plenty who love Go), I'm often asked questions about Rust vs. Go, which actually perplexes me a little. Asking "What about Go?" when someone brings up Rust is essentially like saying "What about OCaml?"; the languages have a few similar features (as most languages do, IMO), but they have completely different goals and only a subset of s…

I think people compare them because they were both designed as alternatives to C++ (or at least with that in mind). What people might miss is that they were solving two very different problems: Rust aims to be as fast (or faster) while guaranteeing memory safety, while Go aims to be easy to understand and get productive as quickly as possible.

> I think people compare them because they were both designed as alternatives to C++ (or at least with that in mind).

I find it really interesting when people say this, because to me, Go only seems like a suitable replacement for higher-level C++, whereas Rust could conceivably be used in any domain where C++ would be suitable. I'm not sure if this is the general consensus or just my perception though, so this could be clouded by my bias of being a heavy Rust user.

Re: 24 days of Rust – Rayon

#65

Post by StevePerkins »

kazagistar wrote: post #62
StevePerkins wrote: post #43

Earlier quoted context omitted.

Are there really a lot of "shared use cases" between Rust and Go? I realize that Go's creators intended for it to be a systems language. In practice though, it has found its niche in web apps or microservices, and command-line apps in the DevOps world. Rust is primarily aimed toward real-time applications that can't tolerate garbage collection latency. Of course they're both general-purpose languages in theory. But i…

It's a unidirectional feud because Rust isn't limiting itself to C++ use cases. As the Async and other library infrastructure falls into place, why not use Rust for webapps, microservices, and command line tools? Just because it is suited for 0-overhead, high safety, with high level abstractions does not mean it's unsuited for these other things; or at least we don't know yet exactly. On the other hand, Go is aware o…

It will be interesting to see if Rust can prove competitive in the webapp/microservice space over time.

However, the standard library and surrounding ecosystem for all the other players "fell into place" years ago. Java and Python have robust and well-maintained (sorry Node!) libraries and drivers for everything you could imagine. The biggest draw for Go is probably that its standard library is so complete, you seldom need many outside dependencies at all. Other rising stars such as Elixir are basically web-first from the start, rather than hoping to grow into it later.

From what little tinkering I've done with Rust... it seems to have a much steeper learning curve than other languages, and an ecosystem with few database drivers and only a couple of half-baked web frameworks (http://www.arewewebyet.org). I don't mean that disrespectfully, since it clearly has generated a lot of excitement in other niches.

However, I personally don't really care about those other niches. We web folks are a much larger community, and for the most part we don't really care whether or not a language uses garbage collection (web apps are more likely to be I/O-bound rather than CPU-bound). So while I would love for Rust to become another serious option, it's basically optimized in the wrong direction for the web mass market... and lags years behind in the ecosystem support that they care more about.

Re: 24 days of Rust – Rayon

#66

Post by Veedrac »

pjmlp wrote: post #30
dikaiosune wrote: post #7

Earlier quoted context omitted.

Closures in Rust are stack-allocated and LLVM can inline them and optimize them as if they're any regular imperative code, for one thing. This means that there's less overhead from managing the iterator chains, and that they're statically dispatched which saves on runtime indirection. The borrow checker also makes sure that you don't accidentally mutate non-thread-safe data from your parallel iterators.

Regarding closures, that is also possible in Java and .NET, just you don't control when it might happen.

In Rust, each closure has a unique type, and derived expressions are templated on that type. This is key to making them statically dispatched, which is important for making the base case (sequential) fast.
Post reply on HN