> I hate to sound like the rust evangelist strike force... I really do. But your complaints are exactly what it would solve...

Rust doesn't have lazy evaluation, or a particularly extensive standard library. I'm not aware that Rust has heap or thread profiling any better than Go's.

For everything else, though, yes. I found Rust pretty easy to learn (coming from Java with a bit of Python background); i haven't mastered lifetimes or coherence, but i manage my day-to-day work without needing to. No GC means no GC pauses, and if there are big slow drop cascades, they are at least confined to one thread. Rustfmt seems to be mostly reasonable. Library versioning is done properly. The type system provides generics, sum types, and strong, if unconventional, control over side effects. Godoc uses source order and Markdown. Struct fields have to be initialized. Boilerplate is minimal; in particular, checking errors is one character, and sorting detects and uses an existing. ordering, or takes a single function to define one.

Rust's library ecosystem is expanding very rapidly. I think it will overtake Haskell's in months rather than years, if it hasn't already.

Also, does anyone fancy designing a Rust Evangelism Strike Force T-shirt? Because i would absolutely buy one.

How robust/mature is it as of yet? More importantly, how are compile speeds and how much of a priority are they to the compiler maintainers? I too find it quite promising in terms of "a language aiming for the benefits of Go with the expressiveness and added easier correctness of FP".

But "promising" doesn't mean I'd replace the few use-cases where Go currently shines for me (wouldn't recommend it for any-and-all development at all, but there are select cases where I currently absolutely wouldn't use anything else) as these are those few programs where I really want to write (and later, read) exactly step-by-step "almost machine instructions" and where the only "expressiveness" needed is already fully afforded by Go and quite well at that. Dev-related mostly bulk-file-processing-based custom tooling (not bad to fire off sizable amounts of automatic background transformations from one weird format to another on file-system events etc.) .... filters through which to pipe vast/continuous data streams with just-some-processing over it .... providing out-of-process certain "low-level, must be lightning fast" tasks and logic with IPC for a higher-level codebase .... it's a great tool for such cases, especially given how simple the syntax is. Ie. the basics are grasped very easily very quickly and you don't have to recall "its pattern matching syntax and quirks, its generics syntax and quirks, its etc etc". =) I'm perplexed when teams choose to express their entire domain model or startup in Go, however.. fair game, maybe I'm missing something there

> robust/mature

Needs more context. It's more mature for some things than others, like many young languages.

> how are compile times

Not Go, for sure, but not the worst either.

> how much of a priority are they

Getting them down is a high priority, but has taken some time to make a dent in. The last few releases have all posted speed ups, and "cargo check" in the last release helps. Incremental recompilation is coming, you can try its initial implementation on nightly today. There's a lot more to do, but users really want improvements, so it is and will continue to be actively worked on.

> Incremental recompilation is coming

Good to hear, when that is in place compile times matter a whole lot less

> How robust/mature is it as of yet? More importantly, how are compile speeds and how much of a priority are they to the compiler maintainers? I too find it quite promising in terms of "a language aiming for the benefits of Go with the expressiveness and added easier correctness of FP".

I never get the compile time argument. Well I code a big Scala application and the most time it spents is integration testing. the 10 minute test suite would probably still run 9 minutes and 30 seconds on go. we heavily rely on the database and cover a lot of concurrency/parallelism things in our tests. some things which we would need to test in go, too.

the compile time argument always looks good on first, but later on it's just a dumb way to prefer a language since it never matters. (Actually even the go maintainers didn't cared for a while about the compiler performance).

Well, the thing is, with compile times of 2 seconds I can run my unit tests as fast as possible. At the same time, I'd just use a mock database for most of the tests.

It's great to be able to compile applications like kubernetes in 2 minutes.

If compile time is an issue, the new 'cargo check' tool may take some of the pain away.[1]

1 - https://blog.rust-lang.org/2017/03/16/Rust-1.16.html

More to the point, Rust is trying pretty hard on the compile time front. They've almost got incremental compilation out the door, on top of this.

Does kubernetes take 2 minutes to build? That seems super long. I csn compile juju (1mil LOC) in like 15 seconds.

I haven't compiled it myself but I've read it's something like that. Though I'm not a 100% sure.

with all dependencies (first time compiling) it takes way longer than 2 minutes.

My comment is aimed at the OP who has it very clear in their mind what Go's shortcomings are.

On the contrary, you haven't pointed out an objective issue that you have with Go. You offered some harsh remarks about the language but backed them up with praise.

I'd say you love the language, but apologetically so. You shouldn't it's a great language.

If ever you decide it's not for you then look at other alternatives, rust being one them.

> I'd say you love the language, but apologetically so. You shouldn't it's a great language.

I just think for me it absolutely shines for certain use-cases and sucks for many others, where I simply won't use it. The question then becomes "why Rust over [Haskell&friends]", not "why Rust over Go" ;)

We're asked this question a lot (I work at Pusher). I wrote up some of my thoughts on this in reply to a comment on one of our previous blog posts: https://www.reddit.com/r/programming/comments/5fyhjb/golangs....

Right now I'm keen to get more personal experience with Rust, and hopefully in the wider team. I'm particularly interested in [Tokio](https://tokio.rs/), which should address some of our concerns about the existing concurrency support.

Also, in same reddit comments there's a longer (quite argumentative) discussion on Rust concurrency that you might be interested in: https://www.reddit.com/r/programming/comments/5fyhjb/golangs...

Small update on that thread: Tokio has now had an initial release, with a lot of docs. Still much more to do, of course :)

Most haskellers are fond of Rust. However, it is certainly not a Haskell replacement; it has substantially less expressive power. This is, arguably, necessary for its impressive memory model (no GC and memory safe allocation), but it does hurt programmer productivity in many cases. I always feel constrained when I use Rust, although I can't fault the language for being that way. Rust is well-designed, but even good designs come with caveats. I prefer Haskell's caveats for most common programming tasks.

Personally, as a frequent Haskell user, I'm looking forward to replacing embedded C/C++ with Rust as soon as they get the AVR toolchain figured out and there's better support for common ARM uCs.

Luckily, LLVM 4.0 added support for AVR, and hopefully Rust can take advantage of this soon

This may be solved for Haskell as well in the near-ish future (I assume you're thinking of the GC issues) by the addition of linear types to GHC: https://news.ycombinator.com/item?id=13866787

Or Swift - Swift sneaks in sum and product types via a c-structy syntax. Once you see the type system underneath the syntax (which was devised not to scare the Objective-C horses IIRC) it’s quite pleasant.