Hacker News Reader

Comment by krenoten | Hacker News Reader

Many people seem to be confused by Rust's lack of limitations imposed on you as a programmer. In particular, the fact that so much of what is thought of as a runtime is provided as optional libraries. You can run tasks similar to Goroutines, which are provided as a library. You can use certain types of garbage collection as a library. You have dramatic freedom and accessible choices. The possibilities are incredibly inspiring.

View on HN

In my tinkering with both Go and Rust, and liking the looks of both, I get vague feelings like Go is to Python as Rust is to Perl. This may be damning praise for some folks, but it makes me lean slightly toward Rust more than Go (slightly). There seems to be almost an anti-library culture in Go (i.e. "use the standard library" is almost a mantra in Go) whereas in Rust, there's more than one way to do it (even this early in its existence).

That said, in many ways neither language is like the one I've compared it to, probably in enough ways that it's not a useful comparison for much other than this one metric (the TIMTOWDIness of the language). But, it's how my head is processing these two quite novel (to me) languages; which would make sense, as I've written more code in Python and Perl than probably anything else, so they're the known things I compare these unknown things to.

You could say that Go is Python and Rust is Haskell, because, well, Rust is basically Haskell cleverly disguised as a C-style language so as to not scare away imperative programmers.

Could you elaborate on that? Rust has a powerful static type system, HOFs, is expression-based, has an unusually good pattern matching engine for its intended area, assumes immutability by default and uses a notation for function signatures typically associated with FP, but I don't think those are enough to call it a "cleverly disguised Haskell".

In fact, it has been my observation that the language has been getting progressively less functional since its early days. Not that I consider this to be bad.

Sure -- basically what you said: http://science.raphael.poss.name/rust-for-functional-program...

Of course it's not exactly Haskell, but it's arguably closer to FP than it is to C, yet manages to be approachable to imperative programmers. I think this is fantastic.

That would be a really tough argument to make. It goes to great lengths to give control over memory layout and control and lacks a LOT of the features of Haskell's type system. It's a lot more like a prettier D than Haskell. Not only that with every iteration it has been moving farther away from the FP paradigm.

I think you mean GHC's type system, since Rust is arguably quite close to Haskell 98 in spirit, ie. algebraic types, lambdas, pattern matching, traits = single parameter type classes.

I think the point is that it seems actively inspired by Haskell -- that the things people like about Haskell are the same things the designers of Rust want in their language.

As far as I can tell, there is some Haskell inspiration in the form of typeclasses (traits in Rust), but almost everything else that resembles FP has a more common denominator in ML. (Even Haskell's type classes have some common lineage with SML Functors)

Reminds me of hop and house (haskell based OS) http://lambda-the-ultimate.org/node/299 ~ 2004

> Rust is basically Haskell cleverly disguised as a C-style language so as to not scare away imperative programmers.

This comment is very condescending. It makes it seem as if C programmers are ignorant and Haskell programmers are enlightened. Haskell is a garbage collected, lazy, pure language which makes it unsuitable for many of the domains C-style languages are used in. These are also qualities not shared by Rust, which may explain why there is less resistance in its uptake by C programmers.

Oh, come on. Don't take things so seriously. There are tons of Haskell programmers who don't know C, too, and Rust is just as much of a way for them to reap the benefits of C as it is anything else.

> Haskell is a garbage collected, lazy, pure language which makes it unsuitable for many of the domains C-style languages are used in.

Don't be so sure! [1] You could simply use Haskell as a metalanguage to generate a C program that does what you need, just like they did with copilot. No Haskell runtime needed.

[1] https://github.com/leepike/copilot-discussion

I'd say Rust is more like C and OCaml had a baby.

An amazing compliment, IMO.

Which library provides goroutine like concurrency in rust?

With 1.0, rust no longer has a runtime at all, so official support for libgreen was actually dropped. However, between sync::mpsc, sync::TaskPool and sync::Future you can produce similar results.

All those deal with threads. Rust 1.0 will have multi-threading just like C++, Java, etc. It is very different from how Goroutines work and do not offer similar benefits at all (specifically for network services).

libgreen while it existed scaled very poorly and consensus among rust developers seemed to be that, it cannot be improved without compromising some of the core features of rust like no-GC and zero-overhead calls to C libraries.

Even with Go it's a fairly bad idea not to use Goroutine pools for request handling if you're writing low-latency services. You can get isomorphic results with a future pool and channels.

It is not about whether goroutines need to be pooled. Goroutines work very differently from how OS threads. They are scheduled at the user-level by using non-blocking system calls to perform network IO on multiple OS threads. They are also partially pre-empted on function calls.

Whether goroutines need to be pooled depends on the application. For example, the default HTTP creates ones per connection and seems to be used without any problem in production at a lot of places. Creating them is much cheaper than creating OS threads. In fact, libgreen threads were faster to spawn than libnative ones in rust when it existed.

Rust and Go have different trade-offs when it comes to concurrency and each has its benefits and drawbacks.

I'm not saying that a Goroutine is a thread. My point was, you have the ability to write your own systems for your own tradeoffs. Feel free to write a schedulerless coroutine system or an Erlangesque reduction counting scheduler, or even a full reimplementation of the Go scheduler. You can pin Goroutines to threads to ask them to act a little more like them, but that's about as far as you can go. While you are right that Go's system is great for some tasks, there is no reason why Rust can't form a superset of its functionality, in time.

Whether goroutine-like mechanism is possible in rust without compromising its core values is not clear, since libgreen attempted it and failed.

Something like async..await is in the cards and I guess rust does have plans to implemented it sometime in future, but that will require compiler support and can't be done just in libraries like you claimed in the first comment of this thread. While it will not have same runtime characteristics of goroutines, it'll provide similar benefits to program structure.

All that said, rust definitely offers a lot. I'm only contending the claim that the language is flexible enough to implement something similar to goroutines purely as a library.

Huh interesting... how does Go do it under the hood?

This is a good read on the Go scheduler. http://morsmachine.dk/go-scheduler

There is nothing that would prevent an implementation of Go's scheduler in Rust, and libgreen duplicated its functionality pretty comprehensively. Rust's scheduler was more advanced than Go's scheduler in some ways—it did work-stealing in a completely lock-free way, for example.

The only fundamental difference between Rust and Go here is in stack management. In Go, goroutines start off with a small stack, and they can grow because the language is now pervasively, precisely garbage collected and all of the pointers into the stack can be rewritten. In Rust, that wasn't an option because it isn't garbage collected; it used to use the old Go approach of split stacks, but the same problems were encountered. There was also significant backlash against the problems that continue to be an issue in Go and were an issue in Rust—the FFI (cgo in Go's case) was slow due to having to perform stack switches, most importantly.

Yes, that's what I meant when I said it not clear whether goroutines can be replicated as a library in rust "without compromising rust's core values". In fact, I mentioned no-GC and zero-overhead C calls.

Since libgreen did have massive stacks and one could not spawn 100s of thousands of tasks without changing system limits like overcommit, it was not really a comprehensive duplication of goroutines.

This is really interesting. One or both of you all should write a blog post on it because I'm eager to learn more.

I love C. Love Go. Love the idea of Rust though I've never tried it, and I just want to know more.

> Since libgreen did have massive stacks and one could not spawn 100s of thousands of tasks without changing system limits like overcommit

Well, you could customize the stack size, and we did when running stress tests like that. You don't need to change system settings. The only difference is that you have to know how much stack your "goroutine" is going to need up front.

Oh no, flashbacks of C++

Want some simple concurrency? Here try boost::asio... or boost::thread... or... libev... or libuv.

Now every project has a different concurrency model woven into it. Why isn't there a good solution in the stdlib for this common need?

Everything mentioned in the parent post is in the standard library.

> Now every project has a different concurrency model woven into it. Why isn't there a good solution in the stdlib for this common need?

Because every concurrency/parallelism approach has tradeoffs, and there is no one right implementation for all cases, and rusts intended primary use case is low-level and broad enough that there's not even one approach that's probably good enough for most cases.

Reply on news.ycombinator.com