Rust vs. Go | Hacker News Reader

Rust vs. Go

blog.ntpsec.org

481 pointsingve580 comments

From ESR's conclusion is this:

> For comparison, I switched from Rust to Go and, in the same amount of time I had spent stuggling [sic] to make even a <100 LOC partial implementation work, was able to write and test the entire exterior of an IRC server - all the socket-fu and concurrency handling - leaving only the IRC-protocol state machine to be done.

I don't think this is an unusual experience. I'd consider myself a journeyman programmer with 16 years of experience and probably a dozen languages under my belt. Learning Go was unique: after 3 days I felt productive; After 2 weeks I sort of looked around and said "is this it?" Go gets out of your way for the most part, and performs as advertised.

For a lot of programmers, for a lot of projects, that's exactly what you want.

I've attempted to learn Rust a few times, and it always feel like I'm moving uphill.

Rust is awesome for a number of problem spaces, so I'm not knocking it. And Go _isn't_ awesome in a lot of ways (vendoring, I'm looking at you). But it feels like there are a lot of core, language-level things Rust needs to improve to attract more non-genius developers.

The thing with Rust is it doesn't let you get anything wrong. It's both a strength and weakness. There's a million edge cases that you can just ignore in many modern languages.

A large part of the reason Javascript has taken off is it's ability to "get out of your way", however you pay for that in the long tail of issues and undefined things.

Many projects in software are trying to prove out a concept, and in those cases is makes sense to move fast and find out if the core thing you're doing works. However in problem domains that are well understood or have strict performance/memory requirements Rust really shines.

I think there's a strong argument that this is a subset of software(and probably not the majority) however I feel that unless you're taking a project to 100%(remember the last 10% takes 90% of your schedule) ESR's comparison isn't fair.

Whereas in C you can introduce subtle errors that might take forever to trigger, or silently corrupt things. Go still allows data races. Rust eliminates this.

So, I guess you can "ignore" stuff in other languages and feel like it's working, with less guarantees it is actually right. Most of the things you need to do in C, Rust just codifies and enforces.

Quick iteration on concepts is actually helped by not having to do extensive testing & maintenance work to keep your system from 500ing, which a static type system can help you do. The fact that dynamic languages don't care about your bugs is actually a hindrance.

What dynamic languages have as an advantage is that they allow you to more readily change your system as your understanding of the requirements change. This is where static type systems have traditionally been very weak - they create roadblocks for evolutionary change.

What would be great is a type system which catches your bugs but doesn't block you from evolving. I actually think Rust's use of type class polymorphism ("traits") goes a long way toward that goal, once you learn it.

Flow does this. Never used Typescript but I assume it's similar. Flow really shines though because the typing is totally optional and has almost no impact on the JS patterns that you want to use.

20 years journeyman here. If I could write my experience I would write what you did word by word about my feelings with Go and Rust. And I've tried many times - you nailed it.

As an aside, I keep seeing people don't "get" this, and it is painfully unclear to me - why?. Perhaps the pool of people with 15-20 years that are still doing programming is very small, so they make very tiny noise.

>15 years programming here, from VB6 to JS including C(++/#), PHP, Java, Scala, many Lisps... I "get" what you mean, I just want to give my perspective:

When I tried Go I just didn't get what it had to offer. It felt like the wheel, reinvented. I was like "That's it?". I can see how that's appealing but, for me, Rust is a stepping stone on what we should expect from programming languages of the future.

A new language with a new paradigm is going to take longer to feel productive in, especially when the tooling and libraries aren't quite there yet. I can see how that's not good for someone who wants results now.

Rust's ecosystem is very much in its infancy. I expect 2017 to be a great year in terms of both language ergonomics (e.g. see Rust Language Server) as well as stabilization/standardization of very important things like how to do concurrent I/O. If your niche is distributed computing (e.g. I/O bound servers), yes, Rust is currently not going to satisfy you.

I think comparing Rust and Go is not fair for neither of them and, even if both are advertised as "systems languages" they are actually very different beasts filling their unique niches.

I'm excited for Rust to improve. I keep wanting to use it, but I don't have any projects that need to be faster than I can make them with Go (and frequently with less effort than the naive Rust impl). If Rust's ergonomics improve enough (tooling, std lib, and core language), I might be able to justify it. Fingers crossed!

> Perhaps the pool of people with 15-20 years that are still doing programming is very small

I'm at 20 years of paid, professional coding, and 30+ if you count my Apple IIe/gs days and fooling around with C++ as an undergrad.

It took me about a week or two to make friends with the borrow checker, and mostly those were self-inflicted wounds from trying to write aggressive zero-copy code.

I think that Rust works very well for certain coding styles, but the learning curve is much higher for other coding styles. If you've been scarred by C++ and you're used to treating variables as mostly immutable, the learning curve is pretty reasonable. But if you work in a style with a lot of mutability and you've never wrested with "const char *" versus "std::string" in C++ (which both exist for a good reason in C++), there's more to learn. So I could legitimately see it go either way.

My handy litmus test: Do you utterly despise C++, or do you have a complicated love-hate relationship with it? If you fall in the latter group, you may fall in love with Rust on the first try. If you've never even used C++ enough to have an opinion, then it's possible you might not care about high-performance static languages and the prices they pay to go fast, and so Rust's trade-offs might not even be interesting to you.

Ha! I always tell people I have a complicated love-hate relationship with C++. It was my tool of choice for writing games for 20+ years (combined with Lua for scripting). I knew all the C++, and loved, yet hated, it.

Maybe I'll give Rust a go after all. No pun intended. ;)

One of my standard programming interview questions is, "what's the worst part about your favorite {language, framework, ORM, ...}?" I find that if you've used something to its fullest, you usually have a measured and reasonable response to that question[0]. If the candidate isn't as experienced as they claim to be, often the response will be along the lines of, "Well, nothing really."

[0] Unless that something is Rails templating because dang, that is some crazypants there.

Templating can't be the craziest thing in Rails. In fact, I can't remember the last time it gave me any trouble. Are you just talking about how ERB specifically works, or how templates are invoked/rendered? Or is there just some insane metaprogramming stuff in its implementation (there always is with Rails)?

Mostly it's about how the templating process itself works. I once had a strange bug involving how a variable was (not) bound in the view, and I believe I lost count between 20 or 30 steps from when the controller tried to render the view until someone or another called ERB.new.

Interesting,I absolutely despise C++, and I find rust to be incredibly nice (though admittedly, I'm a neophyte, I've barely had to use lifetimes, so I may be unaware of my own lack of knowledge).

What are your reasons for despising C++?

So to be fair, I haven't used a lot of C++, but what I have has been unlikeable.

I'm a pythonist most of the time, although I've done a not insignficant amount of work in C, but I like high level languages more, and C++ feels like the worst of all the worlds. It is complex and bloated (templates) and magical and all kinds of things. I think I summed it up one day by saying that, as a newbie to C++ my frustrations with the language were summed up by a 0 argument object constructor having no parenthesis if it was stack allocated, but heap allocation or arguments require parens, because the 0 arg constructor would conflict with a function prototype if it had parens.

There's so much bloat and cruft and oldness that the language has baked in inconsistencies and gotchas and so much stuff (which of the 12 different kinds of pointers should I use) that it is horrible to learn.

Rust on the other hand has complex semantics, but they are well defined, sensible, and logical. Sure I sometimes want to smack the borrow checker, but the reason why isn't "someone made it this way before I was born and now I'm stuck with the results".

I need to write C++ every now and then and I don't dislike the modern C++ itself, but the tooling is a bit rough to use.

Getting dependencies from the system is a big PITA and the build tools, as in cmake, seem to require as much knowledge as the language itself.

Having a C++17 with a tool like Cargo building static binaries and just the right versions of the libraries would make my life with the language much easier.

The complicated lifetime stuff is pretty rare to run into unless you are doing some tricky things, like custom zero copy parsers or data structures or whatever.

The most important tricks I've learned are:

- Return types should usually be owned values, input types should often be references (or AsRefs). "Be explicit in what you return, and general in what you accept".

- If I'm going to be pointing into an array, its often easier to just pass around indexes instead.

Yeah I learned to return values and accept references very quickly, had to entirely refactor my learning project a day or so into it, but that was for the best.

I've only used C++ since C++11, avoid polymorphism and raw pointers, and actually kind of like it.

With the mix of affection and disdain one traditionally feels for a younger brother, i refer to Go as "systems PHP". It may not be a sophisticated language; it may not produce beautiful code; it may, arguably, even have inexcusable flaws. But it is astoundingly easy to learn to the point where someone can be productive with it.

This is a terrifically powerful, and very unusual, advantage for a language to have. Master programmers won't be choosing it as their tool of choice. It won't be used to attack the craft's hardest problems. But it allows a huge number of people to write programs they otherwise would not have been able to write, and, conversely, a huge number of programs to be written which otherwise would not have been written. There's something rather "quantity has a quality all its own" about it. As with PHP, this is something of a mixed blessing, but it certainly puts a dent in the world.

Master programmers won't be choosing it as their tool of choice. It won't be used to attack the craft's hardest problems.

I see almost the opposite, with many new distributed systems being written in Go.

I use a lot of this distributed systems tooling on a day-to-day basis: Docker, Kubernetes, Vault, Pachyderm, etc., etc. It's all brilliant and innovative software and I'm glad to have it.

But every time I need to dig down into the source code, I quickly realize why Docker falls over all the time with weird bugs, and why Vault's high-availability backend for etcd falls over once per week, and why Kubernetes is capable of inspiring such epic love-hate relationships.

There's a ton of code in Docker where nil can sneak in, and where the types of certain data structures are harder to determine than they should be. Sometimes nil represents "none", and sometimes the empty string does. There's a bit of multithreaded stuff in Vault's etcd backend (or was) that doesn't understand the corner cases inherent in concurrency.

I'm totally convinced that these new distributed tools are awesome and a boon to our industry. I just wish that somebody had a long conversation with a good type checker and thread safety checker at critical moments during the implementation process.

This may be a classic case of the "New Jersey approach": https://www.jwz.org/doc/worse-is-better.html Software that's sufficiently innovative and which works will be forgiven odd corner cases and bugs.

> But every time I need to dig down into the source code, I quickly realize why Docker falls over all the time with weird bugs, and why Vault's high-availability backend for etcd falls over once per week, and why Kubernetes is capable of inspiring such epic love-hate relationships.

Vault's documentation clearly states to not use ETCD as the HA backend.

Docker's problems stem from their bone-headed decision to start with a client/server architecture that they've been unwinding ever since. They should have started with small composable tools that integrated well with the existing infrastructure (init systems, file distribution, and security infrastructure). Instead they started with an architecture where everything goes over an HTTP socket through a daemon with high probability for contention, deadlock, and failure. None of that has anything to do with Go. They could have built that abomination in any language.

I can't speak for Kubernetes. I have not used it in anger yet.

> Vault's documentation clearly states to not use ETCD as the HA backend.

Yes, when I reported bugs against the etcd HA backend they said they were going to add more prominent warnings to the docs, if I remember correctly. :-) I think the underlying bug comes from overly optimistic multithreading code using CSP, but I stared at the code for several hours and couldn't see how to make it unambiguously correct.

We now have our own in-house Redis "HA" backend that I wrote which appears to be rock solid in production, but which temporarily disables Vault during Redis restarts. So it's really "fake HA" but it works nicely for our use case and never requires manual intervention or embarrasses us during business hours. I refuse to set up and administer an entire Consul cluster for a single leader-election lock. Managing Consul has its own complications: https://www.consul.io/docs/guides/outage.html

> Instead they started with an architecture where everything goes over an HTTP socket through a daemon with high probability for contention, deadlock, and failure. None of that has anything to do with Go.

The Docker daemon's wire protocol suffers from a kind a of sloppy thinking about data types, in my opinion. Consider this line in a Rust Docker client: https://github.com/faradayio/boondock/blob/bf29afb0c78f8d5d6...

    pub Ports: Option<HashMap<String, Option<Vec<PortMapping>>>>,

Here, the `Option` types say, "This might be a JSON `null` value on the wire." So the `Ports` member might be `null`, or it might contain an empty hashmap, which in turns contains values that might be `null`, or might be `PortMapping` value. The corresponding Go code is extremely unclear (at least in most similar situations) as to which values can be `null` on the wire.

There's a lot of really foggy specifications going on in the network layer of the Docker server. It's not bad in the way that certain old Unix servers like `csvd` were bad, but I feel like Docker could be better if Go demanded more clarity about data types.

On the other hand, Docker is clearly a raging commercial success, and it actually works quite nicely (at least if you use Amazon's ECS to manage your clusters). So maybe I'm just being overly fastidious. Clearly all this new Go-based devops infrastructure is hugely successful, even if many of us get frustrated with it now and then.

Still, I really wish that more programming languages forced you to be clear about which values can be `null` and which can't. Hoare called it his "billion dollar mistake": http://lambda-the-ultimate.org/node/3186

I'm still unconvinced Docker's choice of using Go is the primary culprit for their problems. If Docker had started bottom up they would have been forced to design tighter contracts between the components from the beginning (regardless of language).

Ultimately it's the architectural decision to couple everything that allowed them to be loosey-goosey with internal-only interfaces. Why bother specifying them thoroughly if you can update all components simultaneously and have no dependencies outside of your control? I'm sure a tighter language would have helped in the small, but their problems are categorically big problems that I believe transcend smaller and more localized failings.

My experience using Consul for the Vault backend has been pretty good. Yes, you have to manually go in and clean up old nodes after a restart, but that isn't too bad. So far (knock on wood) we haven't run into a situation where a replacement node has refused to join the cluster or the cluster has out-right failed.

That said, I do wish they would put the effort to properly integrate with Etcd. We've gone through the motions of setting up and managing a highly-available Etcd cluster for quite some time now and are more confident running it than Consul. I'd rather standardize on Etcd myself, but I'm not inclined to swim upstream. :)

I'm not sure what that has to do with things like race conditions that randomly result in "kill and delete" erroring and leaving the container in a invisble, dead state, with a totally useless error message. There are a lot of resources to keep track of in a system like docker and esoteric error conditions, and pretty poor tools to help you do it correctly in Go.

I have yet to see Go code among that class of projects that I would consider bad. I find Go to be a kind of equalizer -- the low ceiling prevents masters from moving upwards in syntactical/semantic complexity, and the high, uh, floor prevents junior developers from doing too much obviously bad. There are plenty of edge cases a newbie can cut themselves on (the addition of unsafe pointers is an antique, Victorian footgun that you'd not expect in a modern language), but overall, Go's forced simplicity normalizes code quality to a degree that I've not seen elsewhere.

Docker's faults do not come from Go, and the same goes for Kubernetes.

Well I do hope analogous tools appear in Rust and show design soundness of Rust. For now I remain sceptic that Rust is perfect language for large, complex, high-perf highly concurrent software.

Rust Roadmap says this much for production use:

"Production use matters for the obvious reason: it grows the set of stakeholders with potential to invest in the language and ecosystem. To deliver on that potential, Rust needs to be part of the backbone of some major products.

Production use measures our design success; it's the ultimate reality check. Rust takes a unique stance on a number of tradeoffs, which we believe to position it well for writing fast and reliable software. The real test of those beliefs is people using Rust to build large, production systems, on which they're betting time and money.

The kind of production use matters. For Rust to truly be a success, there should be clear-cut reasons people are employing it rather than another language. Rust needs to provide crisp, standout benefits to the organizations using it."

https://github.com/aturon/rfcs/blob/roadmap-2017/text/0000-r...

Is that because go is such a great choice, or because it was written by a famous guy for google?

You could read the top level article and find out?

That seems rather elitist and dismissive. Why wouldn't master programmers use Go if it's the right tool for the job?

The craft's "hardest problems" are tackled with C or C++ (embedded and real time stuff) or with R, Python, Fortran, Matlab (scientific stuff). Some of the most used and therefore most scalable systems on the web use Java, PHP (and variations of PHP), C#.

None of those languages strike me as being both elegant and state of the art at the same time.

Meanwhile the "weapons for a civilized time" such as Lisp or Haskell haven't really gotten a major hold in either a Fortune 1000 company or the software giants on the West Coast.

It's like there's no correlation between "hacker points" for a programming language and the actual results delivered with that language! I'm being ironic, there isn't any. I'm open to someone proving me wrong though...

Well, you usually don't choose languages based on their technical merits, but rather on the ecosystems around them. These depend on popularity which you get by having traction, which you get by being quickly productive. This is why very tolerant or very familiar languages succeed. Being chosen as one of the blessed languages that are taught in universities is also, of course, priceless. A killer framework (Hello, Ruby) can also do wonders.

Not that this defends the very poor syntactical choices that Lisp and Haskell and their communities have done (minimal grammar is not a good thing! One-symbol names are horrible!), but a lack of popularity is not as damning as it sounds.

> Well, you usually don't choose languages based on their technical merits, but rather on the ecosystems around them

Ecosystem is part of technical merit, but I'd agree that in many cases (particularly non-software firms), languages aren't chosen by technical merit (including ecosystem), but for social reasons.

I can't bet for everything, but a lot of sophistication has been put into making Fortran, C, and Java very fast and efficient, for different but meaningful values of "efficient". They are very sharp tools, if not most elegant.

> Meanwhile the "weapons for a civilized time" such as Lisp or Haskell haven't really gotten a major hold in either a Fortune 1000 company or the software giants on the West Coast.

Last I checked, the list of publicly acknowledged production Haskell uses included several significant ones in Fortune 1000 firms, and various Lisps have seen production use at major firms, both inside and outside the software industry.

Sure, Haskell and Lisp (and APL and any other language you care to mention) is used somewhere, in some Fortune 1000 company, but that's a far cry from having gotten a major hold. Just because a group of futures traders in one HSBC office use Haskell to price a certain type of future you cannot really say the Haskell has a major hold at HSBC.

Upvoted because it absolutely is elitist and dismissive - it's a fair cop!

To pedantically respond to your question, note that what i said was that master programmers "won't be choosing it as their tool of choice", by which i mean that it won't be the language they dream about being able to use on their next project. Of course, if Go is the right tool for the job, a sensible and honest programmer will use it.

Well I was all ready to disagree with you and then you had to go and be reasonable.

That's a fair point.

If you have not done it already, I recommend that you give Lua a try. There's a "Learn Lua in 15 minutes" thing that you might like.

To me, Lua feels like "Javascript done right". I only find the `end` syntax very annoying to write.

Configure your editor to do it for you, just like most people do for closing braces.

Then you'll just have an annoying editor and an annoying language.

Exactly. I learned Javascript after Lua, and it was pretty similar, except a bunch of clearly worse design choices, and a pile of complexity mostly related to the web platform. (Why is this magical? Why aren't returns symmetrical to inputs? Why are the semicolons and other syntax so silly? Where are the cooperative coroutines? Why are the types and conversions so much more complicated without adding any additional value? Why all the extra ceremony around what is fundamentally the same prototype OOP system? Etc, etc.)

Yes, except for 1 based indexing.

Go does not deserve this comparison. It is a well-engineered and conceptionally sound language, quite the opposite of php: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

It isn't PHP-bad, but it isn't a great example of clean, orthogonal design. The only generic data structures being maps, arrays/slices, and channels, is not indicative of a "conceptionally sound" language.

Don't get me wrong, it a great, practical, engineering-oriented 90% solution kind of language; "conceptually sound" seems like computer language theory got involved, and it didn't.

I would never think "conceptually sound" has anything to do with PLT. Seems like an odd definition...

Do you have any specific examples of 'core, language-level things Rust needs to improve'? One of the most important goals of the 2017 roadmap is making the language more accessible, any actionable feedback is welcome.

Are you only asking the person you replied to? I have some topics I think indicate shortcomings in the language itself, but when I've brought these to the attention of core Rust developers in other threads of discussion the result hasn't been fruitful.

Which topics, and which threads of discussion?

I've had several discussions with you over the last couple years. I create throw away accounts on Hacker News, Stack Exchange, Reddit, Slashdot, Rust Users, and so on because I value my privacy. I don't want to tie my throw away accounts together, so I won't include links.

My experiences discussing anything Rust related with you has generally gone like this: I list several things I think are problems. You refute a small nit in only one of them and neglect the rest of the message. Giving the impression that you've successfully refuted everything I've said, you tag on the stick-your-tongue-out smiley :P

I've had other discussions with other core Rust developers. As should be expected, the conversations go differently for each.

Feel free to link them to remind me of the arguments that I'm neglecting. :P

You're interested in the links, not the arguments. I can't see how this is going to be fruitful.

I'm interested in the arguments that the links contain, but I'm starting to see why I apparently never bothered to fully answer you in the first place...

I'm not seasoned at all; but trying Go a day made me, more than productive, creative.

I started to combine channels freeform and enjoy new ideas every minute, almost no cruft, almost no dead ends ... that's a rare thing.

They did circle the concurrency pretty neatly in a nice usable interface.

> And Go _isn't_ awesome in a lot of ways (vendoring, I'm looking at you

It's worth noting here there is a large, active team from the open source community working on fixing vendoring and package management right now. I believe the target is the Go 1.9 timeframe (end of Q2ish this year).

I find that somewhat surprising. Are the dozen languages under your belt essentially variations of the same OO paradigms? I am mostly a javascript programmer, and a beginner at haskell, and I found Rust difficult not not that difficult.

A friend of mine put it into good words: Go and Rust are two big conclusions, to big follow-ups to the C and C++ world.

Go is an easy, fast, and very parallel language. Go is exactly what google needs, in all regards. It makes sense why Go exists, it makes sense why google is creating a way to migrate from python2 to go. Go is easier than hard C and Go is fast.

Rust is the safe follow-up of C, but more familiar than Haskell, Caml and such. It's a pain to get working, it sucks to program in, it requires so much thought, it's just a bloody fucking fuck. But once rust runs, it works and there's a very very good chance it won't break.

And that's also the reason why we'll probably build firewalls and hardened OS in derivatives of Haskell and Rust, and we'll build Google 2 and Facebook 2 in Go. And in my book, that's a good thing.

> It's a pain to get working, it sucks to program in, it requires so much thought, it's just a bloody fucking fuck.

I could not disagree more! Rust is a great joy to program in. I would rather program in Rust than any other language.

Rust is challenging for many people to learn. That is very different.

Language design is about trade-offs:

The borrow checker and ownership model is a huge tradeoff. Even those very experienced in it still fight it from time to time. Go made a different trade, they chose GC. And GC _is_ easier. But it has computational overhead (well today anyway).

Consider the cascading implications. Rust has a trait for Copy vs. Move types. This means every type has an implicit, and unknown behavior, on certain assignments:

    let v2 = v;
    println!("v is: {}", v);

You can't actually tell me whether the above code compiles without consulting other parts of the code. That's not the case for Go. It is thus simpler and more intuitive to program in.

But it is a trade-off. Go as a language must have a GC. It will never be suitable for certain tasks as a result.

Go also has less compile time checking. This means faster compiles, quicker dev cycles but less compile time safety. Go chose easier here again. These trade-offs are what make rust seem "difficult" in comparison to go. I don't know if you can ever "fix" them.

Exactly this. If you're a massively parallel web service, who cares about some GCs, and who cares about crashing like 0.01% of all transactions? Monitor it, crash it, fix it, deploy it, move on.

If you operated a nuclear reactor with this mentality, I'd be concerned. If you're operating acme.org with that mindset... godspeed?

If you're running amazon.com with that mindset, 0.01% of transactions is millions of dollars a day.

If you're running amazon.com, a project that takes 2 weeks longer to complete is hundreds of millions of dollars of lost sales.

The thing is if you don't want to fight the borrow checker you can use RefCell and Arc/Rc. People are discouraged because then you lose a lot of architectural advantages that come with Rust but nothing is keeping you from writing unsafe{} and RefCell in the places where you know things are safe but can't formulate something that Rust understands.

I suspect that if you can't formulate it into something rust understands, you don't understand it well enough to know it's safe.

I am a member of the Rust language design team, I am very aware that language design is about trade offs.

I find the ownership model has non-performance advantages in that I find it provides strong design pressure to factor my system well. I would not describe my experience as 'fighting' the borrow checker - I feel positively when the borrow checker sends me back to the drawing board, because it teaches me things about my system I had not properly comprehended.

(There are areas where the borrow checker is overly conservative, but I never hit these in practice.)

> You can't actually tell me whether the above code compiles without consulting other parts of the code. That's not the case for Go. It is thus simpler and more intuitive to program in.

I'm sorry this is just silly. Here's some Go code:

    v2 := v + 1

You can't actually tell me if the above code compiles without consulting other parts of the code, because you don't know if `v` can be added to `1`. In Rust, type inference is only local to a function, so you will be able to determine from an actual compile-able code snippet whether or not that use after move is valid.

Go also actually might not compile on the exact example you cited (translated to Go, of course) because that code contains an error if `v2` is never used after it is assigned.

In general, you cannot reason about the correctness of incomplete code snippets. This is not specific to Rust.

I think you've missed my point.

The ownership and borrowing model may provide many benefits, but those benefits come at the cost of complexity (as defined by Rich Hickey in Simple Made Easy). I have never found the owning/borrowing thing to be very hard. But it is _more complex_. There are _far_ more fundamental concepts baked into Rust then Go. And the interplay of those concepts creates complexity. It requires more knowledge and inherently complicates more things.

The parent that started this says "it requires so much thought". What that means is they have to hold a lot more concepts in their head. It's not that any one concept is hard. It's that holding all those concepts and the interplay in their head at once is hard(er). This is what people mean when they say "Rust needs to improve to attract more non-genius developers."

A huge portion of things you have to think about in the ownership/borrowing model simply doesn't exist with a garbage collected language. You just _don't_ have to think about a huge set of things at all.

Type inference is an example of this tradeoff that both Go and Rust agreed on. This adds complexity and decreases clarity in both languages. The upside is expressiveness and conciseness. We could always make you specify the type with a declaration (like C) and then the snippet you posted would need less external reasoning:

    int v2 = v + 1;

While you can't fully reason about any snippet of code, the more core language level concepts I have to address with any snippet the _harder_ and more complex it is for me to consider them.*

I'm _not_ trashing Rust here. I'm just stating that some of the good tradeoffs you made here leave the language inherently more complex and thus difficult to use. There are _upsides_ to that. You gain safety, performance, and "pressure to factor [your] system well". Simplicity is very far from everything.

When you're writing acme.org most of those tradeoffs are may not be worth the complexity. When you are writing a safety critical system they damn well are.

*PS on the subject of code snippets and compilation. As engineers, the primary audience of our code is other engineers. As such, I always find some programming language debates have real insight when addressed by my Strunk and White (no really). Consider the following two sentences:

The compiler must know the lvalue. It may then use it later on.

Too me this is the English language equivalent of type inference. We know "it" is "the compiler" based on previous statements. Using pronouns too often in a sentence makes it unclear. Using them too sparingly makes it tedious (and also often difficult to read).

A similar balance holds with concepts the reader must address in a given paragraph. This is the line we all dance when we write code. How many concepts must we hold at once to comprehend what is written?

Is it creating an additional complexity cost or simply exposing an existing but often ignored cost?

It seems a bit like pointers, higher level languages will hide these details from you but you still have to know what they are and how they work, in addtion you have to know how the garbage collector works (that's a big complexity cost right there). In the same way that c forces you to be aware of pointers the borrow checker forces you to be aware of ownership.

> A huge portion of things you have to think about in the ownership/borrowing model simply doesn't exist with a garbage collected language. You just _don't_ have to think about a huge set of things at all.

I'd like to introduce you to resource leaking and the Android activity/context lifecycle...

Just because you don't have to think about them doesn't mean that they aren't concepts that you should still be applying in GC'd languages. You'll just get bit by them when you least expect it or your load crosses some invisible threshold.

That said there's a valid point in that the large majority of software doesn't push the performance/memory threshold enough to make it a primary concern.

A portion is not all. GC doesn't solve all resource leaks. It does solve the problem of lifetimes.

It also doesn't solve all your lifetime issues. Do you know that the library you passed your object to didn't take a reference?

With GC'd languages you say "I don't care" to the lifecycle question which can(and will in any moderately complex software) come back to bite you.

That's not a lifetime problem. The object is still appropriately alive if referenced. The lifetime in the GC and free sense simply means that while an object reference exists it should be valid. See http://web.media.mit.edu/~lieber/Lieberary/GC/Realtime/Realt... for example.

GC doesn't guarantee you won't have resource leaks (of which memory is one). It guarantees that when you no longer reference an object it will be freed and that while you have a reference its valid. That's the lifetime problem. The Rust docs call it the same thing for that matter...

Maybe not strictly lifetime problem, but the unexpectedly extended lifetime can cause problem. The caller switches which object it is working on and now the live object in the library is disconnected. Or, if it is mutable, changes could be done by the library at a time which break caller expectations.

I've found that in GC'ed languages (like Python or JavaScript) not taking care of "lifetime", easily results in logic bugs. Better than crashes* - but still problematic.

* Maybe not always better either. Not crashing may lead to silent data corruption. And obvious problems (like crash) tend to be fixed faster than subtle ones, in practice.

Garbage collection does not actually solve the problem of lifetimes. At least not in the gc'd languages I am intimately familiar (c#/java). I cannot comment on whether or not Go solves the problem of lifetimes because I don't know the language well enough, but I feel confident that if it does solve the problem, it is with garbage collection in conjunction with another concept

Only if you restrict your definition of "lifetimes" to include memory. That said, memory isn't necessarily the only resource regulated by a lifetime, and that's why I prefer non-GCed languages for most things.

Your invocation of Rich Hickey's excellent talk is very confusing to me. It seems like you're using "simple" the way that he used "easy." What is "complected" in Rust's type system? Just because there are "many" concepts, doesn't mean those concepts are entangled. I don't even agree there are that many - Rust lacks inheritance, reflection, and all of their attendant concepts.

In contrast, I find the way Go builds concurrency into the language 'complex' in Hickey's sense. Similarly the way that slices and maps are parametric, but other types are not. The implicitness in interfaces. The way capitalization determines privacy. Go seems like a very 'complex' but 'easy' language.

However, I'd even say I'm not convinced that I want my language to be simple. I want my system to be simple; its possible that by abstracting over an inherently complex domain, and by limiting my choices, a complex language can encourage me to create a simple system. I think ownership encourages the creation of simpler systems. I think a well factored system and a simple system are synonyms.

Binding and use of a variable is complected with its lifecycle in Rust. Which is further complected with type sytem via traits. To quote the docs:

> We’ve established that when ownership is transferred to another binding, you cannot use the original binding. However, there’s a trait that changes this behavior, and it’s called Copy. We haven’t discussed traits yet, but for now, you can think of them as an annotation to a particular type that adds extra behavior.

That's two additional concepts that interplay with variable binding. Two more _implicit_ concepts at that. In contrast maps being parametric doesn't affect other things (other than some syntax which is v0v). It is an additional concept to understand yes. But it's not intertwined with the other language features.

> However, I'd even say I'm not convinced that I want my language to be simple. I want my system to be simple; its possible that by abstracting over an inherently complex domain, and by limiting my choices, a complex language can encourage me to create a simple system. I think ownership encourages the creation of simpler systems. I think a well factored system and a simple system are synonyms.

I agree with you here (especially the later part). Again I do like Go, but I'm not fanatical on this subject. Languages can _certainly_ push you to best practices. Do Rust's? It's probably pretty domain specific.

Copy is essentially operator overloading (it is a simplified, restricted, moves-or-doesn't overloading of the assignment operator), which is always implemented through traits. I agree that operator overloading complects the behavior of built in syntax with the polymorphism system, but the alternative seems worse to me.

However, I don't think binding and use of a variable is 'complected' with its lifecycle. These are semantically significant concepts that I like Rust helping me manage, irrespective of their impact on machine memory.

Also, I should be clear that I do web development professionally and I think the best practices Rust encourages are absolutely applicable to that space, and general application development. That those practices are also high performance in Rust is almost incidental.

Go has one GC benefit that a lot of other GC wielding languages do not; avoid using GC whenever sensible. Variables that are strictly local are almost always allocated on the stack, so a function return has free built in GC; a sizeable number of allocated variables never hit the heap. Compare that to say CPython where everything is allocated on the heap.

That's an unfair comparison. Python is notoriously bad with memory/speed in every flavor

I have yet to understand why people are always trying to compare Go and Python. Python isn't made for the same use cases as Go is. Can Go do the work Python can? To an extent, yes. Can Python do the things Go can do? To an extent, yes. Python will always be slower with the CPython runtime.

In short, I agree with you.

In the case of Google Go was developed in part to take over some of workloads previously done in Python; a language that is comparably as easy to develop in, with better tools and better performance. I suspect this is why the comparisons keep popping up.

>In the case of Google Go was developed in part to take over some of workloads previously done in Python; a language that is comparably as easy to develop in, with better tools and better performance.

Go definitely performs better, buy I think it'd disingenuous to claim that Go has better tooling.

Just by being a statically typed language, Go does have far better tooling and indeed many languages seem to copy its tooling concepts.

What Python does have is a far richer third party library base.

>What Python does have is a far richer third party library base.

I assumed this is what you were talking about. i.e. Ipython, Jupyter, pdb, etc.

numpy pandas scikit-learn beautiful soup libraries for geo, geometry, tags, parsers etc etc. Python has an enormous base of sophisticated third party libraries.

FWIW, I've been programming in both Rust and Go for years and I can't really perceive a productivity difference between them.

I think it's uncontroversial to say that Rust has a tougher learning curve. But once you're past that, I think the jury is still out.

GC is not easier when you care about how and when memory is allocated/deallocated

I don't know, that is the kind of comment you used to hear from LISP programmers about how their program was really an elegant mathematical proof of its own correctness.

That's great until you try to do some real world things with it and run into endless impedance mismatches.

Rust isn't quite so far up its own butt, however the developer community doesn't seem to realize that there's a massive gap between the toy example programs in their documentation and the level of knowledge needed to build something worthwhile.

"Go is a blub language" was actually my hot take on this article.

> the developer community doesn't seem to realize that there's a massive gap between the toy example programs in their documentation and the level of knowledge needed to build something worthwhile.

I don't think Servo and rustc itself are "toy example programs".

Are Servo and rustc in the Rust documentation? Literate programming of some sort? Maybe you're replying to a different criticism.

I've been through the Rust Documentation (doc.rust-lang.org) and Rust By Example (rustbyexample.com) several times now, and I have to jump on IRC to get answers to (what I think should be) some pretty simple questions.

If you think something important is missing from the docs, please open an issue. Steve Klabnik is very keen on making the documentation as useful as possible.

Steve seems like a genuinely helpful guy, but I'm not sure my most recent headache is a documentation problem so much as a deficiency in the std/core library. I was trying to write a generic function that called abs() on some of the arguments. Here's a simplified version:

    fn simplified_example<T>(a: T, b: T) -> T
        where T: Copy + PartialOrd
    {
        if a.abs() < b.abs() {
            // some irrelevant math goes here
        } else {
            // slightly different math goes here
        }
    }

I'd like to be able to call this generic function on anything that has a .abs() method. That includes i8, i16, i32, i64, f32, f64, and so on. Is that a shortcoming in documentation or an unfortunate consequence of Abs not being a trait? Several people on IRC recommended the rust-num/num crate, but that has several other deficiencies, and I don't think I should need another crate (unwanted dependency) to call .abs() on f32 or f64. With help, I came up with a workaround, but this was harder than I think it should be.

The grandparent poster said:

>> the developer community doesn't seem to realize that there's a massive gap between the toy example programs in their documentation and the level of knowledge needed to build something worthwhile.

I have to agree with him. The level of Rust-specific knowledge required to get the absolute value of a number/type in a generic function is pretty significant. The example above is just a small part of a library I'm working on and only one example.

We tried to get a trait hierarchy for numerical right four or five times; it's really hard. So yeah, you have to use num or make your own at the moment. It's true this is less than optimal; it's just not an easy problem. For just abs it should only be a few lines of code to make your own; three for the trait, and five times two for the impls.

> We tried to get a trait hierarchy for numerical right four or five times; it's really hard.

I'm clearly not an expert in Rust, and as such I realize my opinion isn't worth much, but it seems to me any attempt to build a numerical hierarchy will result in something fragile. Scheme has a well thought out minimal hierarchy, and even without all the complexity from all the fixed sizes I don't like theirs either. However, it's alright because they have dynamic typing as a release valve. C++ templates dodge the problem because they act more like duck typing, and I think I understand why Rust won't go that way.

Instead, I think you should abandon the goal of trying to create a hierarchy and just treat each small concept as a trait. Rather than creating Signed for things with a sign, and Float for things that are floating point and so on as in the num crate, create Abs as a small concept in its own. Then anything on which you can call .abs() implements the Abs trait. This includes things which aren't "signed", such as unsigned numbers and complex numbers - all of those have a useful (even if sometimes trivial) definition of .abs()

Trying to build a hierarchy reminds me of the stereotypical examples of bad object oriented design - I'm sure you know the cliches where Human derives from Ape, then Mammal, then Animal, etc... A hierarchy is like trying to build a directory tree, but numeric traits are more like labels on your gmail messages. Traits seem more like mixins or interfaces.

You'll end up with a lot of one or two method traits, but you'll also allow people to implement those traits for their own types and implement generic functions over those traits. The Float trait is a really good example of why categorization/hierarchy is unlikely to work well - That trait requires methods like .min_value() which don't make sense for complex numbers, but it is also the interface for .sqrt(), .exp(), and .ln() which have very good definitions for complex numbers. The Float trait in the num crate does not allow me to make generic functions over f32 and Complex<f64> if I want to call .exp().

> For just abs it should only be a few lines of code to make your own

Yeah, the IRC people helped me find a different workaround, but I agree that I'll just make my own trait instead. However, the .abs() methods already exist on all of the signed built in types and so I'll probably call mine .mag() on a Mag trait to avoid confusion (I'm not sure if there would be a collision/compilation error if I used the same names?). This also allows me to implement Mag for unsigned types which is useful for generic code (for examples L1 norms of vectors).

Btw, the docs for i64 have some cut-and-paste errors where they indicate i32 but almost certainly meant i64.

This is a pretty neat idea -- I think I'll try this the next time I need to work on numeric code.

This is already the approach taken with the operator overloading methods with single-method traits like Add, Sub, and so on. Arguably things like .abs() and .exp() also logically belong in the same category and therefore should be implemented as small traits of approximately one method each.

Yeah, that might work, but then it leads to an explosion of traits...

The examples are cut and paste errors in a sense; as it says at the top of the page, the examples are going to often use the wrong number type, because all that code is generated by macros, so for now all the number docs have to use the same type. It's a bug that needs to be fixed, but it's not a trivial one.

> Yeah, that might work, but then it leads to an explosion of traits...

Yes, there are a lot of common math functions, but why is that bad? The alternatives are worse.

> The examples are cut and paste errors in a sense; as it says at the top of the page, [...]

I understand, sorry about that. I didn't see the comment at the top of the page, and I wasn't sure you knew.

Maybe, maybe not. Sounds like a good RFC :)

Also, no worries about the bug! I much prefer over-reporting than under-reporting when it comes to these things.

> Maybe, maybe not. Sounds like a good RFC :)

I'll think about it, but honestly, that sounds super unpleasant. I've seen the bike shedding that happens in those kinds of discussions, and I think it would be difficult to convince any decision makers that there is even a problem if they haven't stumbled upon it already. I don't think many of them do numerical computing, and the language and libraries already scratch their non-numerical itches.

That's fair; I will say that numeric computing is an area we care about. Still working on some of the precursor stuff to make it great, though.

There's a _lot_ of ways you can go in a general purpose programming language; I don't think it's something that "nobody has hit", they just use the workaround of making their own trait(s) and it hasn't been enough of a pain to try and spearhead a change.

You're treading on uncertain ground by insulting Lisp. :)

> It's a pain to get working, it sucks to program in, it requires so much though, it's just a bloody fucking fuck

What sucks about programming in Rust? What makes it a bloody fucking fuck? I disagree on both these points:

  * Rust enums and move semantics make writing state machines a pure joy.  Far nicer than in C++ or Go.
  * Pattern matching (both fallible + infallible) is very developer friendly.
  * Option<T> and Result<T,E> are totally brilliant.
  * It's trivial to add and version-fix a dependency on an external library with Cargo.
  * Rust's ownership and move semantics help you to write cleaner, easier to understand code.

How does move semantics make writing state machines better? I can understand powerful enums, but I'm not familiar enough with move semantics to envision what you are referring to. Do you know of an example available somewhere?

It ensures that you consume a state at most once. You can kind of visualize state 'moving' through your functions - going in through the arguments and out through the returned value.

Example: http://insanitybit.github.io/2016/05/30/beyond-memory-safety...

TL;DR: compile time checking that your state machine transition is correct.

Thanks, I'll take a look.

I wrote you a little example but i think you need to know rust to really understand it :(

https://is.gd/FlBCJ0

you cannot uncomment the comments in the main function and use it wrong, the compiler prevents you to compile this code.

these two sections from the book may help understad this

https://doc.rust-lang.org/book/ownership.html

https://doc.rust-lang.org/book/references-and-borrowing.html

if you're more into videos this may help

http://intorust.com/tutorial/ownership/

http://intorust.com/tutorial/shared-borrows/

This is really cool, thanks!

Can you explain the purpose of your '_unconstructable'?

If a struct is public, and all its members are public, you can just create a new instance of the struct with braces (in that case, it would be `OpenSocket { data: 12 }` - or whatever value you like), not what is necessarily correct. By having a hidden zero sized struct member, you need to use the library's api to construct them.

Sure. It is a private field(no pub) preventing you from constructing that type with a literal. It is of type "unit" '()' so it does not add up space for the type. "unit" has only one value that makes it "zero-sized". because i did not supply an "constructor" to that type it is not constructable outside the module and can only created by types in the scope of the enclosing module. Its more or less a private constructor known in C++/Java ... etc.

Steve Klabnik has a more complete write up regarding this http://words.steveklabnik.com/structure-literals-vs-construc...

It is basically a hack to export the type but not the type constructor. It stops people from doing things like

    let new_socket = OpenSocket { port: 12 };

Nice example. I was learning Rust over Christmas so I see how it works. But one issue I have is that from the outside it's not obvious that your `close()` method will take ownership of `self`. I'd probably prefer it if there was some (compiler-enforced) convention that made it obvious to clients that `close()` would consume `self`.

As it stands, Rust code can break the principle of least surprise, since what happens in a method can affect the associated instance variable (in this case `open_socket`). A user could easily write several lines of code and only discover that `open_socket` has been moved into a method at compile-time.

I found myself having very small coding-compile iterations when writing in Rust to catch issues like this (but that was also undoubtedly due to the fact I was learning).

Is there a pro tip to avoid this issue?

> it's not obvious that your `close()` method will take ownership of `self`

I'm in the middle of reading the Rust book right now, so this may be dumb, but... Isn't this exactly the point of using a naked `self` instead of the reference `&self`? If it's not a reference, `self` is consumed by the method. At least that's my current understanding

If you mean that the one-character difference is very small for such an important semantic distinction, I might agree.

As for the state machine example, I like it a lot as well. It's very similar to the idea of "making illegal states unrepresentable" from the OCaml world: http://fsharpforfunandprofit.com/posts/designing-with-types-... (This particular post is F#, but the idea is general.)

> Isn't this exactly the point of using a naked `self` instead of the reference `&self`?

Yes it is, but you only see it's a naked self if you look into the method. From the outside there's nothing in the name to indicate that it doesn't take a reference. So potentially it means that for every method call you need to check that it takes a reference to `self` instead of ownership. This would be especially annoying with third-party libraries.

The alternative in other languages is the error (using a socket that has been closed/resource that has been semantically moved away) is only found at runtime. The compiler flagging a mistake like this exactly the point of having the compiler and is a great example of how Rust helps defend against mistakes. Compiling early and compiling often is a great way to develop, IME.

In Rust, I personally don't think about moving vs. not until the compiler tells me I have to, because it usually doesn't matter. Rust previously required moves to be explicitly marked, but it wasn't worth it in practice: http://smallcultfollowing.com/babysteps/blog/2012/10/01/move... (see "Wait, doesn’t this make it hard to know what your program does?" in particular.)

Seriously, you are arguing with emotions, not arguments. It's pointless.

No, he's listing useful features.

GP meant to say GGP is arguing against emotions, not arguing using emotions. He's accusing GGP's detractors of emotionality, not GGP.

All but the last point will make your code easier to understand and program with. It's not an appeal to emotions at all - those are exactly the features I liked about Rust, and wish more programming languages had.

I don't talk about his points at all. I'm talking about shit like "it's just fucking fuck" - it's emotion, not an argument.

He was quoting the parent comment.

I would say that "it's a pure joy!" is the same thing in reverse. The parent and grandparent are both simply comparing subjective emotions.

People who say Rust is hard are probably skipping on reading the really well written Rust book. I'm not a genius in any shape or form, but I am able to write decent Rust apps just fine. I've written an IRC bot in Rust and am working on a file utility now.

It took me longer than 4 days (almost two weeks) to just read the rust book (part time), so yes you're not going to get from 0 to 100 in just four days. If that's your benchmark, how fast you can get going, then you're right Rust isn't for you. But nobody would expect anyone to get up to speed with C++ in just four days.

Rust is a systems programming language with a focus on security and performance, not a play toy for people looking to write small scripts.

>>People who say Rust is hard are probably skipping on reading the really well written Rust book.

Do you need to read a really good Go book to be productive in Go? If not, I think the OP's point stands, no?

I believe he's saying that the Rust book[0] is very good (and completely free).

[0]: https://doc.rust-lang.org/stable/book/

I'm not sure that's fair.

There are certain languages which are different enough from traditional semantics to need an explanation. While others are similar enough to be "obvious" if you've used a semantically similar language before.

To give a specific example, Powershell. It is semantically a very different scripting language from almost anything else in the market. Extremely well designed and powerful, but you'll want to sit down and read an actual book on how it works to get to handle on it because you won't have the mental map already to do so.

Overall this is why the programming language market is so predisposed for new languages looking and feeling like old languages. People just aren't comfortable stepping too far outside of their comfort zone semantically (even if they'll happily do so for a few new language features and libraries).

Yeah one of the best things about Go is how familiar it is, you can pick it up and run with it very quickly.

One of the best things about Rust is that it's a paradigm change, it takes time to get your mind around it but it is worth it if the language fits your use case.

> People just aren't comfortable stepping too far outside of their comfort zone semantically (even if they'll happily do so for a few new language features and libraries).

I'm not sure that's fair. It seems more likely that people who choose "boring" languages do so because they have things to build, and want to pick a language with a good risk/reward value. Not out of some academic interest or comfort calculation.

I think that focusing on how long it takes to be productive is a mistake, within reason at least. How well does it hold up once I'm knowledgeable with the language matters a lot more. If it takes me 4 days or 3 weeks to be productive, ok, that's fine, but it needs to be a good solution once I'm there, because I'll spend years using it potentially.

The really, really important thing about the time it takes to be productive in a language is selling the language to other people. If it takes 3 weeks to learn enough Rust to make interesting projects, then it's going to be absolute hell convincing a team of largely ambivalent co-workers to use Rust, because 3 weeks is equivalent to months of weekend tinkering. You're restricted to using Rust either when it has mass adoption, it interests your devs, or the domain needs provable safety guarantees.

On the other hand, if someone can pick up Go and produce a side project with two weekends worth of messing around, they're much more likely to be supportive of the language.

Obviously this isn't ideal, but I don't know how you'd fix the problem.

Do you really want people on your team who think that having to read a free book and investing 3 weeks to learn a new language is too much of an effort?

Firstly, when the initial impression of a language is that it's not fast to code in, people seem to assume that it will remain unproductive in regular use. This is clearly the case with ESR, and is a problem that's relevant to the Rust community in general.

Secondly, as per the Rolling Stones, you can't always get what you want.

Sometimes you don't have a choice. You don't want those people but they are forced on you.

It's strange the short term focus that is accepted in what are nominally professionals.

It may very well be out of your hands. I wasn't able to convince my coworkers to use Kotlin for an android app, even though at the end of the day I was the only one coding it. And Kotlin takes a few hours to pick up if you know Java.

Maybe they are spending those three weeks learning something else. There are thousands of things that "every programmer should know" and thousands more that "every human should know", and you will never have time to learn them all.

If you've come from an ML background you'd need a good book to be productive in Go, and jump straight into Rust. Go is more C-like which makes it easier to pick up coming from C, not absolutely easier.

Do you have the sources for your IRC bot somewhere? I have a bot written with Ruby in a quite big channel and I have this tendency of writing it with a new language every couple of years. An IRC framework with Rust and Tokio would be fun...

I have the source, but it was more a process of me learning than something intended to be used by others. The source code is not online. It can read from a toml config and connect to multiple servers and respond to commands. It's pretty cool. I had it up at Github for a bit, I can put it back up, but this is an anonymous account so I wouldn't share it from my Github. I'm not sure how to share it. :\

put it up on an anonymous gist, if you want

Instead of writing an IRC bot, I have written an IRC client in Rust here: https://github.com/FreeFull/ircclient . Beware, I haven't put much effort into making the code clean or well documented. Writing an IRC bot would be easier than a client, because you wouldn't have to deal with reading from stdin, and you'd be able to keep everything single-threaded. The IRC library I use doesn't have any tokio support yet.

> not a play toy for people looking to write small scripts.

That's actually a reasonable beginner's use for Rust though [0]. It's easy to do and will expose you to enough of the language to be a learning experience, but not so much that you could get badly stuck. And the benefit is that it's a lot easier to share binaries than it is to share scripts that rely on a particular interpreter being installed.

[0] http://www.chriskrycho.com/2016/using-rust-for-scripting.htm...

It's not that easy to accept binaries compared to scripts I can open and see what they do.

You could store them as source files with a hashbang, and make something like "rustrun" which compiles a single Rust source code file and runs the resulting executable? That should take ~15 minutes.

I do wish there was an actual Rust interpreter.

Why? Rust is a systems-level language. It's not designed for scripting. If that's what you want, use Python/bash/{yourFavoriteScriptingLanguage}.

Well, if you can interpret it then its easy to build a repl, and repls are nice.

"being interpreted" in not enough to have useful repl. You also need to be dynamic and introspectable. There are interpreters for C, but it doesn't make it suitable to use with repl.

there's nothing bad about interpreting a systems language. there are C interpreters available, too. i'd argue it'd be a very useful feature since the compile times of rust are one of its biggest pain points right now.

There is a dead project named `rusti` (fails to build on Rust nightly >= 2016-08-01) that can interpret Rust source, and a newer project named `miri` (last commit 3 days ago) that interprets MIR output from the compiler. Several of us in the community, me included, would like a REPL, so I'd keep an eye on these projects to see if they go anywhere.

The big thing for me in this regard is not worrying about dependencies (in a lot of cases). With Rust, when someone asks me for a script that does X, I can compile and ship a binary and they run it end of story. With python, I say "ok, now install python version whatever, then install pip, and then pip install all this stuff, and finally run my script"

I was with you until your last paragraph:

> Rust is a systems programming language with a focus on security and performance, not a play toy for people looking to write small scripts.

If you're suggesting Go is a play toy, you're wrong.

I could see how this statement could be construed as inflammatory, but I don't think he was implying that Go is a play toy. He was implying that you can't make a judgment on the language based on making play toys (the toy IRC client mentioned in the article).

Yes this is correct. I do not in anyway think Go is a toy. It's a fine language. I love kubernetes and it's written in Go. A lot of people took that statement to mean that I thought Go is a toy and I didn't mean that, so I apologize.

> not a play toy for people looking to write small scripts.

IMO this tone or slights against Go will hardly endear Rust to people. Rust's superiority should stands on its own. Not just you I have seen this sentiment many times by Rust enthusiasts on reddit and elsewhere.

Go already has successful companies like Docker, CoreOS etc literally built using Go. There are 100s of companies using Go productively. Very large software like kubernetes, docker, etcd are written in Go and they are not toy scripts.

I did not mean to imply that Go is a toy language. The Go developers are very smart engineers and they made a great language. Sorry if it came across that way. I was more making a point about putting some effort into learning Rust. I did not mention Go anywhere in my comment but I understand why people thought I intended to slight Go. I didn't.

I encourage everyone in this thread to not take things personally. Rust vs. Go conversations are going to cause a lot of angst on both sides. I also encourage people not to assume or read into comments, where someone states that "Rust is not a play thing", they are not implying that Go is.

For some people who've spent the time with it, Rust is a godsend, but that does not mean that by believing so they implicitly hate Go in anyway.

Go clearly has a lot of people who love it as much as people who love Rust, and because they overlap, there will constantly be a conversation of which language to pick for cases where it looks like both could be used. As such, the learning curve for Rust will always be an impediment, to its adoption, which is sad, b/c in all my experience it's the only language that I've used which inherently answers every core issue or fundamental bug that I've encountered in my career. This is why I'm really excited that the Rust core development team has decided to focus on development experience heavily this year.

Your point is fair about trivializing the other party, even implicitly.

Docker and CoreOS are not really successful companies...it's hard to say if any of the companies in that space will be successful.

Adding a quick opinion here: I worked for one of these companies (working with libraries written by all of these) and it's just a matter of personal taste. Docker, CoreOS, Hashicorp, etc. are "successful" (which is hard to confirm for now) because they can gather a lot of open source contributions thanks to the easy Go learning curve. I don't think this would be the case if they used Rust instead. Go is definitely not a play toy and you can build scalable and reliable software with it. The problem with Go in my opinion is also its ease of use, it's incredibly easy to write sloppy/buggy code with panics/data races that become increasingly hard to debug. I've had my fair share of frustrating experiences debugging concurrent code with hundreds of goroutines or investigating random data races on complex distributed systems code. I've yet to see that happening with Rust after four months of using it, the compiler does an incredible job at preventing these.

While Go's frustration often comes from debugging sloppy concurrent code, the frustration with Rust is often about having your code to compile. But once it compiles, it runs beautifully. Some prefer the former, I personally prefer the latter. Also, I think the argument of increased productivity with Go should not be the main argument, because the time you save writing a large program, you will probably lose trying to debug a deadlock (which could still happen in Rust but harder to make happen) or a random data race that the race detector couldn't catch (or in a vendored library).

If I had to define the experience with both languages, Go is the instant gratification option, you feel productive quickly, the language is easy to learn with a forgiving syntax sometimes at the expense of correctness. Rust is the delayed gratification option, frustrating at times, very hard to learn and master but offering strong safety guarantees with an elegant syntax (which is a personal opinion).

Also it's a controversial topic in the Go community but the lack of generics...

Rust has its downsides too, for example the slow compile times or the lack of maintained libraries for some core functionalities but overall, programming with Rust is a much more enjoyable experience once you start getting ahead the learning curve.

One last thing: It is hopeless trying to learn Rust in four days without very good resources/books. I recommend "Programming Rust" from OReilly if you really want to dig into the language. It's incomplete at the time of writing but still one of the most useful resource out there (with the free Rust ebook). My knowledge of Rust dramatically increased after reading it and I felt much more confident writing larger programs.

Go is a language that is used to write on top of things. Rust can, maybe, be used to write the things Go are written on top of.

This sentiment (or slight) is the same as always said of C and C++, that they are used to make real things (systems and infrastructure, foundations), and the sentiment (and slight) is there because there's a lot of truth to it.

Which language was used to write our *nixes, windows, the biggest web servers (apache, nginx, IIS), haproxy, mysql, postgresql, oracle db, etc, etc? C/C++, of course. What else?

Docker is just a front end/abstraction layer for the features already in the Linux kernel (written in C). You can write, what's essentially just automation tools, like this in any language.

I don't think what you write in this post is a testament to any strength of Go. If currently there exist a testament to its strength it must just be the fact that it's used; adoption rate/popularity, although I have not seen the numbers.

> Docker is just a front end/abstraction layer for the features already in the Linux kernel (written in C).

That's actually a perfect example of "systems programming", in the true sense of the phrase. And it is done in Go, because it can be done in Go.

I write small scripts in Rust all the time. It's perfectly suited to it even though it's not an interpreted language.

Mind telling what kind?

Just little things like importing content from JSON files. It's not ideal but cargo makes it pretty easy so it's not that bad either.

I'd be better doing it in another language, I'm doing it mainly to keep getting familiarity with the language.

I've went through the rust book, unfortunately I learn better through actually trying to do things while looking at the API reference. And the rust documentation is frustrating for that, simply because everything is expanded by default and there's no concise list of functions available.

(In my case, I wanted to print out the name of the executable. Having to convert OsStr to something I can print, I understand - the filesystem encoding can be different from the console encoding. But it took longer than it should to find a path between the two.)

I mean, pressing the button to collapse the documentation isn't very hard http://i.imgur.com/rcI3JG5.jpg

I never had to print an osstr yet but it seems fairly straightforward when looking at the docs? There are three obvious functions one could use, each for different use cases: https://doc.rust-lang.org/std/ffi/struct.OsString.html

  os_string.to_str() // returns Option<String>
  os_string.to_string_lossy() // returns Cow<String>, replacing illegal characters
  os_string.into_string() // returns Result<String, OsString> - String if the data is valid, stays OsString for error handling otherwise

I believe Rust is hard, and I certainly did not ignore the Rust book. I haven't really read it in about a year though, since abandoning this project http://joelmccracken.github.io/entries/a-simple-web-app-in-r...

Well, let's see. I was following rust's development for a while, but waited until 1.0 when it seemed it might be kind of stable. All that trivial and obviously correct code turned out to be a kind of wrestling match with the compiler. Far from a pure joy, it was rather frustrating. Set it aside for a while, but then came back recently figuring maybe I'd take another look but instead of starting from scratch I'd pick an existing project and poke around with it. First project I looked at had a requirement that one use the nightly compiler check out, but not just any nightly, specifically the one from last Tuesday. Then I looked at another project, and this also required nightly, but this time it was the one from the Thursday before last. Fuck. This. Noise. I'm not learning a language where every project requires a separate compiler.

I'm totally fine learning the borrow checker. It's a investment I see value in. Even if it's just in me learning about solid rules for sharing variables. But that nightly shit you describe is scary as fuck and makes me very concerned about the future of the language. Post 1.0 this shouldn't be an issue!

I consider libraries using a nightly Rust to be proofs of concept, not actually usable tools. This might be possible in the future, let's push these features to the stable Rust and maybe we could have this kind of libraries in the future.

I always use stable compiler. Never had a need for nightly.

The main blocker on stable was a feature called "custom derive" or "macros 1.1" which will be stabilized in the 1.15 release in February. At this point any library tied to a specific nightly is using some extremely cutting edge features.

There are a couple of fairly popular libraries that were nicer to use on nightly Rust (serde and diesel), but could otherwise work on Rust stable. The "nicer to use on nightly" is going away with the next stable release of Rust. Other than that, the vast majority of the ecosystem is on Rust stable.

Yeah, I constantly ran into this when parsing JSON. I hope you are right and it will be over soon.

Unfortunately "the next stable is the one you want" has been the story for quite a while now. Since this is ostensibly a thread comparing with go, I'll note that their story is more like "the next release will be better, but don't wait for it".

> Unfortunately "the next stable is the one you want" has been the story for quite a while now.

I don't recall anyone ever saying this, where "the one you want" means "the one that supports procedural macros".

We have had this discussion for a very long time, and it has always centered around serde and diesel. Those have been the biggest nightly users since 1.0, and probably before then.

> Unfortunately "the next stable is the one you want" has been the story for quite a while now.

Not really. serde and diesel have been more convenient on nightly for a long time now. It is only just now that we can say the "next stable" because that's when the particular feature they need will be stable.

> I'll note that their story is more like "the next release will be better, but don't wait for it".

I can't wait to use Go's `sort.Slice` function[1], but I'll have to wait for the next stable release.

Seriously though, I'd say the key difference between Go and Rust on this venue is that while Rust is stable, there's still more stuff we'd like to add. To that end, we encourage experimentation by making the acquisition of a nightly Rust compiler really easy. This naturally leads to people experimenting with nightly and publishing crates that either use it or require it. This is a necessary part of experimenting with new features and getting feedback.

Go's scope for experimentation is much smaller. Their changes are much more incremental and conservative. It's a really nice benefit of using Go.

My point is: this is a trade off and it should be presented as such. In Rust land, it requires that you---the user of Rust---ignore crates that require nightly or ignore features of crates that require nightly.

[1] - https://tip.golang.org/pkg/sort/#Slice

It's not really scary.

Very few projects require nightly features and of those that do, most of them will work on stable in just a couple of weeks!

Plus you can easily switch between versions with rustup!

> most of them will work on stable in just a couple of weeks!

Until they don't again because clearly the authors have no interest in being on a stable compiler release.

> Plus you can easily switch between versions with rustup!

I don't think people are complaining because switching versions is hard. Just unnecessary, risky, and yes kind of annoying.

> Until they don't again because clearly the authors have no interest in being on a stable

This is false, most uses of nightly are because of macros, which will be stable in the next version of Rust.

> Until they don't again because clearly the authors have no interest in being on a stable compiler release.

Then use an older version of the package. Unless the package in question was relying on some "nightly" feature that never made it into stable, then you should be fine.

I feel like every other crate I've run into claims to require nightly.

In reality, they often work perfectly fine on a reasonably-modern stable, and simply haven't updated their documentation and READMEs to indicate "oh yeah, this nightly feature is now in stable, so just use a stable that's newer than version so-and-so".

Please, if you see this, file an issue against the project, so we can clearly mark those crates as working on stable.

1.0 was what, 1.5 years ago?

I'm not convinced the problem will just go away. Not as long as people are obsessed with the new hotness language features that require a compiler from the tuesday before last.

Cargo also makes me wary. How do I know what I'm choosing is any good, and if it is will it still be around next year. Nature of 3rd party libs I guess.

Cargo doesn't require that you use things from crates.io without vetting them. It's possible to, say, write everything yourself, or only use specific crates that you've decided are good (whether that's by reading the source, or only using the ones published by the Rust developers, or some other criteria) and even go as far as explicit pinning to specific versions of them in your manifest (although this isn't particularly necessary: Cargo pins versions by default, and won't upgrade without you explicitly asking for it).

The problem really is that you have to vet them at all. With golang's standard library, it's all going to be supported to some degree. (I believe the same happens with rust's standard library, it's just much smaller.)

Basically, some people like having a curated library set; others do fine without and are happy to find things to use. The former set doesn't like rust as much in its current state.

The crates published by the Rust developers themselves seem quite similar to the standard library for this purpose. (But, yes, things like this are not as discoverable as they should be; it is one of many things people are working on.)

We have the Rust nursery as a curated library set.

> wrestling match with the compiler

I went through a similar experience in Haskell. It is worth going through until you get to the point where it is no longer a wrestling match, because then you are just as productive but any code you write is checked much more thoroughly than in a more weakly typed language.

> Fuck. This. Noise. I'm not learning a language where every project requires a separate compiler.

I guess just wait until it stabilises then.

> I guess just wait until it stabilises then.

Which is when? 1.15? 1.50? 2.0?

What was the point of that whole "1.0" thing?

Touche! I remember a place where I worked where the first version was 3 because they figured customers wouldn't trust a version 1. I guess these guys went for version deflation.

It's right now, with 1.0. Just don't use libraries that require nightly. Libraries are not the language. The language is stable. If your requirement is stability, then use the stable version of rust with stable libraries. That's what I do.

Are you unfamiliar with semver and the promises it makes?

This is a rhetorical question, as there's no way you've been around here so long without knowing what it is. For everyone else, however, the notion is that code written for 1.0 will continue to work for additional 1.x releases. It says nothing about iterating on not-yet-baked features--that's what nightly is for, and as they become baked they become part of 1.x releases. They're not breaking backwards compatibility; the major version remains the major version.

That's basically an artifact of the combination of Rust's immaturity and its conservative stability policy - once a language feature or API is supported by a stable compiler, it needs to keep working more or less forever. So a bunch of features still require nightly, so some projects target nightly, and the big ones may pin to specific nightlies. But the amount of breakage is vastly lower than it used to be (especially pre-1.0), and even in the year-and-a-half since 1.0 a lot of different bits have been stabilized, so that sticking to stable Rust no longer feels like being handcuffed. The biggest unstable feature left is compiler plugins, which should get a rudimentary version stabilized Real Soon Now. With that and maybe specialization in place, there should be little reason for projects to stick to nightly.

Was this project rocket.rs by any chance?

Very few projects require the nightly compiler and fewer still a specific version of it, but rocket is highly experimental and kind of a special case.

The simd crate required nightly the last time I tried.

I talked to burntsushi last week about stabilizing SIMD in Rust, and he says he's got about to release an RFC very soon. :) Due to this, I'm hopeful that stable SIMD will land this year.

Thats great news!

Welcome to the downside of version pinning. Now that we have version pinning, developers don't need to make versions forward compatible. Misery is when one program needs packages which use different pinned versions of something. There's probably some namespace hack to allow that.

This is compiler version pinning. At least .toml files don't support that. Yet.

Do you really expect any project to have nightly builds that are forward compatible? The whole point of regular development builds is to have a place to test and do experiments... which is pointless if every experiment needs to be supported forever.

The "namespace hack" in Rust is having the "stable" namespace: a compiler that rejects all unstable code (and is forward compatible), so that people don't accidentally get pinned.

If someone wants to pin to a specific development version (of anything), there's nothing the project can do about that, other than being closed source and only publishing stable artifacts. Tooling like rustup that makes it easier to pin means that people who choose to experiment can still use stable by default (easy to switch back) and that others can easily collaborate on the experiments, both of which seem like strict positives.

Perhaps another incarnation of the rule that work expands in response to productivity improvements. You can improve efficiency, but instead of saving work people will find more ways to create new work.

> I'm not learning a language where every project requires a separate compiler.

All the libraries I have needed for my projects in Rust support stable. Maybe shortly after 1.0 some people were not playing by the rules yet.

The only exceptions I've found are some truly elite macro things and stuff to support code generation.

The biggest hurdle people seem to have with Rust is that it makes you very aware of the difference between stack and heap allocated data. For someone coming from a garbage collected language (or even in some cases C) that's a pretty big hurdle to get used to. I've found Rust to be amazing to work with, but it does feel like a struggle sometimes when all I want to do is allocate some structs without having to faff about with Box types.

Honestly I feel like peoples biggest issue with Rust is that they're trying to write things in Rust that don't actually need Rust. They want the ease of use that you get with a garbage collected language and then get annoyed when Rust forces them to worry about allocations and cleaning up after themselves. C++ should have the same issue but its been around long enough that most of those details have safely been wrapped behind STL and other abstractions to the point where most people don't need to worry about them. Perhaps in time Rust will reach that point as well and everyone will be using the equivalent of Boost that abstracts worrying about whether something is a Box<ARC<Foo>> behind a nonthreatening layer of macros.

Go has the same distinction (stack vs heap), but the GC means you don't need to care about the lifetime of the data.

To your other point, it saddens me that Rust isn't well-suited to higher level applications. You need very strict performance requirements before it makes sense to pick Rust over Go (you can squeeze a lot of performance out of Go, and even optimizing Go is friendlier than writing naive Rust IMHO).

I think this might depend a lot on how you approach Rust. I find the functional/procedural mixture to work nicely, and find I'm much more productive in Rust than Go (or Python or Java, modulo available libraries). I'm writing web services and code generators, so not particularly low-level code.

I've written a decent bit of Go, and I understand why a lot of people like it, but I don't think it's inherently better for application development.

Maybe, but I think your case is atypical. I came from a C++ background, so I'm well-acquainted with navigating a huge feature matrix and thinking about memory management, but I'm still much more productive in Go simply because the feature matrix is always very small and I only need to think about memory management in hot paths.

I want to be comparatively productive in Rust, I just never seem to get there because of the huge volume of decisions (even if the decisions are mostly easy) that need to be made for even straightforward code units. I think what I really want is Rust lite, or Go with generics and abstract data types.

I could absolutely be atypical; prior to using Go and Rust as my main tools, I primarily wrote Scala, and I'm sure the functional and type-driven approaches have left deep grooves. But that would still be a way of approaching working with Rust, wouldn't it?

None of that is to make a value judgement, just an observation; but I would still argue that the language can be used in a highly productive manner. Nonetheless, it's perfectly reasonable to argue it's not worth adapting to it, especially if Go is already solving your problems and keeping you productive. I switched because Go's design doesn't seem to fit me very well, and I continually tripped on issues that I don't encounter in Rust. (So yes, perhaps I'm quite odd.)

I do understand the want for a Rust-lite; the thought has crossed my mind more than once. So far, Swift seems closest in many ways and may get close once the Linux/cross-platform story starts looking good.

> I could absolutely be atypical; prior to using Go and Rust as my main tools, I primarily wrote Scala.

I'm not saying Rust is easy, but I have also a long Scala and some Haskell background which made it easier to learn Rust. For me the hardest part was that I've never really wrote any proper C++ or C, although I could read them quite good. Refereneces and RAII caused some gray hairs, the type system not that much.

> I just never seem to get there because of the huge volume of decisions (even if the decisions are mostly easy) that need to be made for even straightforward code units.

Well this is true for all languages! You need to think hard for every decision you take with languages like Ruby or Python. Things like how will this look like after a year, will the junior developer be able to extend it, will there be data races and so on.

Rust just enforces you to do this. And it makes life much easier when you don't need to worry about some silly mistakes you made, because the compiler will catch them.

>Well this is true for all languages!

That is unfortunately not true enough.

Rust has a brilliant solution for some really burdensome issues that C++ developers have. A lot of C++ code tends to make assumptions about ownership and lifetimes that are not formally spelled out anywhere in the code. It's all over the place, it increases cognitive load, it makes the code brittle and less modular than it could be. Rust fixes that without negatively affecting performance whereas all C++ workarounds like shared_ptr and defensive copying are incomplete and/or have a negative performance impact.

But Rust also insists on enforcing its ownership rules between variables within the local scope where it doesn't help much and feels needlessly restrictive and convoluted. I can't say I know Rust well enough to tell whether working under these restrictions can become second nature and stop being a burden.

Also, users of garbage collected languages don't have many of the ownership and lifetime issues that C++ developers are forced to think about. Especially where objects are immutable, ownership is not a concern at all.

So I think Rust is an answer to one question: How can I have detailed control over resources like in C++ without inheriting all the hazards of C++ as well.

While I agree that programming necessarily involves a lot of decisions, I hope we can agree that there is a spectrum of complexity among programming languages. My point is that the likes of Rust and C++ introduce a huge volume of decisions that wouldn't exist in a simpler language, like Go. That said, if you think all languages are as complex as C++, I'm not sure we can agree on much...

> Go has the same distinction (stack vs heap)

No, Go does not have that distinction. This is even in the Go FAQ: https://golang.org/doc/faq#stack_or_heap

Yes, it does have the distinction. From your link:

> When possible, the Go compilers will allocate variables that are local to a function in that function's stack frame. However, if the compiler cannot prove that the variable is not referenced after the function returns, then the compiler must allocate the variable on the garbage-collected heap to avoid dangling pointer errors.

As you can see, Go uses both the stack and the heap; however, unlike Rust, it doesn't require users to know where their variables live to write correct programs.

I believe, the distinction that orclev mentioned was that in Rust, you specifically have to be aware when something is allocated to the stack or heap, but in Go, you don't have to since the compiler deals with it. Obviously Go allocates to both stack and heap, it's just that the user doesn't need to know which.

Fair enough. I simply meant that Go's semantics let you reason about what lives on the stack vs what lives on the heap much like you can in Rust (though in Rust it's clearer still because there is no escape analysis at all). While you don't need to know from a correctness perspective, you can reliably reason about what will live on the stack vs heap in a way you can't in, say, Java.

No, you can't really reason properly about what lives on the stack. As the Go FAQ say, you can safely assume a variable will be allocated on the stack if you never take a reference of it, but that's not always clear as it seems. For instance, if you call a method on your variable, you can't immediately know by looking at the method whether the receiver is by-reference (pointer receiver) or by value. If you're using a pointer receiver, the variable's address may be taken, so the compiler has to perform escape analysis.

Once you take the address and escape analysis is performed, you've got no way to easily reason about what's on the stack vs. what's on the heap, without delving into the gory implementation details which may be changed in future versions.

Since Go isn't C++ and doesn't have a huge and complicated standard that guarantees compiler optimizations, you can't really reason about what's going on.

This is essentially the same situation as Java, although the Hotspot JVM's escape analysis is probably less 'basic'.

That is one reason to choose Rust, but that is far from the only reason to prefer Rust over Go. I've found that algebraic data types and pattern matching have become irreplaceable parts of my programming toolbox, to the point it is painful to work without them. Rust also has a powerful macro system that Go cannot match.

This is not to say that Rust is better than Go in every way, but performance is far from the only facet when I compare the two.

> The biggest hurdle people seem to have with Rust is that it makes you very aware of the difference between stack and heap allocated data.

What do you base this belief on? I'm very comfortable with C and assembly. I am very certain I understand the difference between stack and heap allocated data, but I've found lots of other hurdles in learning Rust.

What were the hurdles that you encountered?

One difficult aspect of Rust relative to Go must surely be generics and trait bounds. This is something it shares with Haskell and Scala. For people coming from those languages (like myself) the stack/heap thing is the most salient.

> What were the hurdles that you encountered?

> One difficult aspect of Rust relative to Go must surely be generics and trait bounds.

Conceptually this isn't bad at all. I understand the value and mechanism of specifying the required traits for types to a generic function. However, I just posted an example elsewhere in this discussion where there simply isn't a trait for the method I want to call. That was certainly a hurdle for me, and the workaround wasn't satisfying.

I mostly understand the semantics of borrowing mutable vs read-only references, and I'm pretty sure I understand the purpose and value of the concept. However, specifying lifetimes is completely different than any other language I've ever used, and I've used a couple dozen languages over several decades in my career. I haven't gotten past that hurdle yet.

> the stack/heap thing is the most salient.

I'll stick with my statement that I understand the stack and heap well enough (from a C or C++ point of view), but composing Box, Cell, Ref, RefCell, and friends is a non-trivial hurdle.

Theoretically yes, for a C/Assembly programmer you're aware of the difference between stack and heap allocated data, BUT the cognitive load is different because those languages don't differentiate them in a particular fashion, it's all just pointers and offsets at the end of the day. Rust on the other hand, because of the Box type makes it very explicit where exactly some piece of data lives. It's also relatively uncommon to stack allocate any kind of larger structure in C or assembly, almost by default that kind of thing is done in the heap, where Rust makes it really trivial (default even) to do so on the stack even though that's rarely the correct decision.

Depending on your background there probably are various hurdles to overcome in learning Rust, I'm not discounting that, but the most uniquely Rust one is the stack vs. heap issue, particularly since that combined with issues around shared state are the sources of most of the headaches you'll run into when fighting with the borrow checker. Pretty much every other feature of Rust is similar enough to another language that if you have experience elsewhere you won't find it particular troublesome. References are easy to understand if you know C/C++ (and to a lesser extent C#). The type system is easy to understand if you know Haskell or Scala (and to a lesser extent JavaScript/Python). The generics system is pretty much the same as Java, C#, Haskell, Scala, or C++ (and probably others).

Rust IS a complex language, but it also provides a unique feature set and has some fairly unique goals. IF you need or desire the features Rust provides, pretty much ONLY Rust is going to get you what you want. C, C++, or Assembly potentially can deliver the same functionality, although it's questionable whether their ergonomics will be better or worse than Rusts for a given task, and they almost certainly will be more bug and error prone. Rust lets you have all the fine grained performance tweaking (or just plain low level access) you can get with C/C++/Assembly, while also giving a strong peace of mind that your code is correct and error free. It's also arguably easier than C++ although that comparison is a bit Apples and Oranges, C++ has a great many years of tweaking and experimenting behind it so things like Boost go a long way towards providing something like a most optimal (from a ergonomics standpoint) C++ experience that ignores all the languages pitfalls and sandtraps. Rust on the other hand has just barely hit 1.0 and the community hasn't even discussed, let alone come to any kind of consensus on the best way to tackle various issues yet. Rust will get there in time, but it's still early in the process and it shows.

Bottom line, if you need the features Rust provides, but aren't comfortable with how young the language is and want more hand holding, C++ (or maybe C) is probably the language you want. This isn't to say Rust is a bad language or you shouldn't use it, I think learning and using a new language is reason enough and the certainty Rusts type system and borrow checker provide is a very strong argument in its favor, but you need to be aware of what you're signing up for when you make that decision.

> the most uniquely Rust [hurdle] is the stack vs. heap issue

I can only speak for myself, and I politely disagree. So far, explicit lifetimes (both the syntax and the concepts) seem like the most uniquely Rust issue.

> [if you] want more hand holding, C++ (or maybe C) is probably the language you want.

Heh, if you think C++ holds your hand, I'm not sure we're on the same page. What I know of C++ was hard-won after reading many books and fighting with the compiler for many years.

Sorry, it wasn't exactly clear from the context but by hand holding I meant more in terms of the resources available. C++ by its very nature has tons of great libraries, tools, and various kinds of documentation. If you can think of it, someone has most likely written a tutorial about how to do it in C++. Additionally there have been entire forests worth of books written about various facets of C++. Rust in contrast has few libraries, fewer tools, and little to no documentation for most of what it does have. This isn't to say Rust is bad, it's simply new and building up documentation takes time.

> [...] Rust forces them to worry about allocations and cleaning up after themselves. C++ should have the same issue but its been around long enough that most of those details have safely been wrapped behind STL and other abstractions to the point where most people don't need to worry about them.

Also, C/C++ comes with the venerable "kill the process GC" that makes it easy for beginners and other mortals to feel good about code even when it not strictly is good. Rust is all about making that kind of quality mandatory.

> Rust is all about making that kind of quality mandatory.

This is why I think the best characterization of Rust is "an Anti-Sloppy Programming Language".

I'm learning rust now, this isn't even my first attempt. I know Go really well and C reasonably well and I can say Rust is much harder. If you want specifics: I can tell you that I've found changing a type from HashMap<String, u64> to HashMap<T: Hash+Eq, u64> within one of my projects to be extremely hard. I've read the rust documentation, and had to resort to reddit several times. I'm stuck dealing with mutable/immutable borrow issues to accomplish relatively simple tasks like searching for entries and removing them. In go these issues don't exist. I'm sure I'll figure them out eventually, and I'm a fan of rust, but it's a confusing frustrating grind.

My understanding is that the rust team has put 2 priorities ahead of everything else: zero cost abstraction and safety. Given those constraints they've done a fantastic job in the area of ergonomics, but I don't know if it will ever be easy. Maybe rust is as easy to use as it can be.

Have a link to your code?

> HashMap<T: Hash+Eq, u64>

I can take a wild guess that T is a generic type defined on either the method, struct or impl in which this HashMap is declared. It's on the method/struct/impl. You don't necessarily need the type bound on the struct, but you do on the impl declaration:

struct MyStruct<T: Hash+Eq> { map: HashMap<T, u64> }

impl<T: Hash+Eq> MyStruct<T> { pub fn insert_something(&mut self, my_key: T, my_int: u64) { self.map.insert(my_key, my_int); } }

try it here: https://is.gd/RwUpQx

Please don't hesitate to ask for help on #rust-beginners. I was in your situation last May, and hanging out on IRC was an excellent experience. Rustaceans, generally speaking, will bend over backwards to help you work on your project.

This is one of the more reasoned differentiation I have seen between the two languages. Funnily enough, it's in both of their mission statements. It clearly shows too in the resulting languages.

"It's just a bloody fucking fuck" is reasoned?

i continue to be astonished that D gets left out of these discussions. it's more capable than go and easier to use than rust, which would make it look like the sweet spot for a lot of people moved to compare the two. (that said, every time i've tried to use the language the tooling around it has been a miserable experience. that might have changed in the last couple of years.)

I've never used D, but I think it was written before the developer community was ready for a new language.

Now that developers are ready for new languages, D is already an "old, failed" language.

It reminds me of selling a house. If you put your house during a hot market and go into contract right away, but then your buyer can't come up with the money and it falls out of contract three weeks later, bringing your house back on the market it's now no longer "newly available!", and everyone thinks that, because it didn't sell in the first week, there must be something wrong with it.

My personal entirely uninformed opinion of D is exactly that: It's an older, "failed" language. It's not on the upswing in popularity. It didn't catch peoples' hearts and minds. And if only because of network effects, therefore it's not worth learning, simply because no one else is learning it, and so therefore its ecosystem isn't expanding exponentially.

Success of technologies is far less merit than one might expect. See: VHS vs. Beta.

You are right. D had some serious failures in the version 1 times, which tainted its image. However, the community is still growing. Slower than Rust, but moving in a positive direction.

During the last year the D foundation was founded and is spinning up operations. The 2016 D conference had a visitor record again with over 100 people. Downloads are growing over the years [0]. The package manager dub is now fully integrated. You can find success stories on the blog [1] and companies using it [2]. There are books.

[0] http://erdani.com/d/downloads.daily.png [1] https://dlang.org/blog/ [2] https://dlang.org/orgs-using-d.html

It was also commercial and closed source in it's early years wasn't it? I don't think there is a place for commercial compilers anymore.

It will be a shame if that's the case.

Why is that? History with commercial compilers have shown them to create nothing but vendor lock-in.

More choice, I don't want an open source mono-culture.

D was always Open Source and free as in beer. It was not Free Software, which is a problem for inclusion in Debian main et al. You get the package from a third-party repo.

The reference compiler backend is still only free as in beer, so there seems to be no way to include "DMD" in Debian. However, LDC (reference frontend + LLVM backend) is practically in sync with DMD today.

The advantage of DMD is faster compilation. LDC gives you faster programs. So, for development I prefer DMD for the faster iteration.

Was it restriction free or did it have limitations on things like stack size like a lot of commercial compilers did?

No restrictions. There was nothing you could pay for in D.

The backend comes from the Digital Mars C++ compiler, which is/was commercial. That is probably the source of the confusion.

when i first saw d (years back), it merely seemed like an attempted c+++.

the syntax seemed extremely similar, as if they took c++ and just tweaked it a bit, rather than working at least somewhat from first principles.

seemed almost comically pointless at the time. no doubt it's evolved since then.

Go is describes itself as "a dumb down language", because according to Rob Pike, "young engineers at Google are too stupid to understand C++ or Java" or something like that.It's true you can learn it in 3 days and be productive with it.

Learning D and Rust requires an effort Go proponents are not capable of.

Another problem is that both D and Rust try to replace C++ and C respectively. But C++ and C developers would never switch to anything else as they feel comfortable using the later, even despite all the gotcha of manual memory management.

Most people using Go today come from Python,Ruby,PHP,JS and co, not from C or C++ or Java. They want performances, without paying a price for "complexity". D is fine today, but it lacks a community behind it and a good ecosystem for web development.

If Rust had garbage collection, it would certainly be more popular but it's not going to replace C anyway. We are stuck with C and C++, they are not going away.

I understand why Rust is what it is, I also understand that most developers don't want to deal with explicit move semantics and lifetime management. Rust isn't going to seduce Ruby,Python,PHP or Javascript developers. the later only want better performances and think Go is good enough. They don't care about explicit memory management.

I'd like to see a version of Rust with garbage collection. The language itself is good.

> I'd like to see a version of Rust with garbage collection. The language itself is good.

Why? What is the added value?

The syntax is nice, pattern matching, traits and generics are nice. The added value is a language with a better type system than Go in Go's space (web development). I don't want manual memory management or to have to care about regions, lifetimes or borrowing.

We have pattern matching, traits, generics, etc. in Scala (and OCaml?) already. The syntax isn't the same, but draws from the same lineage. If you took away the memory management, I think Rust would be just another ML descendent and I don't know what the motivating feature for the language would be.

I could be off base. I haven't programmed in Rust. I've just skimmed through the documentation and little code projects written in it every once and a while.

The added value is that you can implement things that need garbage collection. Like, say, a scripting language.

More importantly, it could be very useful to interact with code in garbage collected languages while having Rust model of the behavior of the garbage collector using its type system.

D was also trying to bring a ruby/python-like experience to the C++ developer. can't say how well they've succeeded, but I feel it's definitely a strictly better language than C++ at this point. from my perspective its main weakness is not being able to generate a runtimeless library that I can call from other languages; without that it doesn't offer enough over ocaml for me to use it, but that would have been a killer feature. (rust does offer that, which is why it's on top of my to-learn list right now)

> But C++ and C developers would never switch to anything else

There are many people who considered it and rejected, or even moved to other languages. C++ developers with existing large codebases may never switch to anything else, but that doesn't mean that the rest of the world is stuck. People are writing databases, browsers, operating systems and device drivers in rust right now and eventually some of those will become successful project defining state of the art.

> I'd like to see a version of Rust with garbage collection. The language itself is good.

There are myriads of languages with GC. There are very few modern ones without it.

I share a similar sentiment. However, the language I'm referring to is Nim. It's just so damn expressive.

I'd like to point you here: https://news.ycombinator.com/item?id=13314770

TLDR: Rust did the hard work of convincing others to try it out and evangelize the language, and as a result, it has become popular and has grown a strong community.

Grumpy isn't a way to move from python2 to go. It's a way to keep using python2 with the performance benefits of no GIL.

Isn't it transpiler ? I think they trying hard to move away from python2 to go, but they had massive amount of code written in python2.

I think your logic is not sound . If they wanted to use python2 (only with their own runtime which does not have GIL) instead of switching to go (eventually) they would write a runtime instead of transpiler ?

Please correct me, I am not 100% sure.

Once you get past the learning curve, Rust is a joy to work in, and you can switch your mind off to things that the compiler can help you with. The trouble is that it takes longer to grok than the four days most people give it. It's not really something you can bash into submission based on past experience with another language.

Ah, this rings so true.

I've tried to get into Rust on/off and each time I'm left feeling like I needed a semester of instruction just to write a trivial program. Each attempt to go back to it, I would immediately hit a wall.

Go, on the other hand, felt quick to pick up. While I don't use it a lot, it's focus on a few composition patterns, and really sticking by that, made it easier for me to learn and come back to when I go back to my Python-centric existence.

Rust on the other hand, I haven't thought about nor touched, outside seeing an HN headline.

"Two big conclusions" is a good way to put it.

I would phrase it like this:

• Go is a useful, safe subset of C (with a rather expanded libc.) Go lets you do fewer things than C (e.g. hard real-time things; processor-optimized things) but for most people, they don't need those things, and delving into them was what seeded the bugs into their C/C++ projects in the first place, completely unnecessarily.

• Rust is a formalization/codification of idiomatic C++. It's not a subset; it's a rethink, like Plan 9 is a rethink of Unix. You can do everything in Rust that you can do in C++, and the compiler will catch (nearly) all the bugs you would have left in the equivalent C++ project.

In other words, Go says "you don't need this"; Rust says "if you're so sure you need this, let's ensure you do it right."

For any given piece of code, either Go's assertion or Rust's assertion could be "correct." You either need the things only Rust lets you do, or you don't.

For a large codebase, though, I expect the answer is actually nearly always going to end up somewhere between. Big apps or libraries always have that one part that does heavy lifting and has to go fast, but go fast correctly; and 99% that doesn't.

Thus, I envision the future of many "systems software" codebases to look like this:

1. (1% of LOC) an "engine" library, written in Rust, which compiles to a C-ABI shared object;

2. (3% of LOC) an "engine wrapper" library, written in Go, which imports the "engine" object using Go's C FFI and then exposes a safe Go API to it—and also, the tests for the engine library, written in Go because it's easier;

3. (96% of LOC) the app itself, written in Go, which calls into the "engine wrapper."

Isn't calling into "C" (or Rust, in this case) expensive in Go because it seeds to switch stacks?

Expensive in Go, but not in Rust.

I am aware, but the parent of my post suggested writing the "engine core" in Rust, and the other 99% in Go. Does using something that isn't Go for 1% of an application to do the "heavy lifting" and be "fast" really make sense when there is a significant cost that must be paid whenever moving between that core and the rest of the application? I imagine such a situation would need a lot of benchmarking to make sure that the end result is actually faster than writing the entire program in Go.

Sorry, I thought you were asking. I agree, I don't think it makes sense.

Imagine something like NumPy. Go code to play with numbers; Rust code to actually do matrix multiplications et al. Since the "hot loop" of such code would be in the Rust part, not in the Go part, you don't see much overhead.

Or, consider Firefox. Firefox's rendering engine will soon be Servo (Rust). I presume that its networking and its Javascript engine will eventually go the same way. Eventually, the only stuff left written in C in the Firefox codebase will be "glue code": business-policy logic that doesn't do heavy lifting, and doesn't need speed. In other words, the exact type of code where Go's "you'll be safer without this" assertion applies. Firefox as Go + Rust: why not?

In Go 1.8; due this month, cgo calls got half as expensive. They all ready are OK as long as you are smart about them.

"Expensive" in this case is measured in tens/hundreds of nanoseconds, so it might be okay as long as your Rust code is long-running.

Bradfitz (a member of the Go team) has said he would love to see OS / kernel level stuff done in rust and every thing above it in go.

I feel like there are lots of better languages to use than Go if you're just going to call into Rust for anything performance-sensitive. There are dozens (if not hundreds or even thousands) of other languages out there with C-compatible FFI and/or APIs; why use Go?

> Rust is a formalization/codification of idiomatic C++

Idiomatic C++ favors values and copy semantics. Rust favors references and move semantics. C++ has function and method overloading, and Rust does not. There are so many places where Rust chose exactly the opposite of "modern" C++ that calling Rust a codification or formalization of C++ makes no sense at all to me. Rust has some great features, and C++ has a lot of warts, but Rust is definitely not an improved C++.

Rust seems like a reaction to problems in C++, but for many design decisions I think they erred on the side of doing the opposite of C++ and ignored the things C++ does well.

> ignored the things C++ does well

What are you looking for that Rust is missing?

I wouldn't use the word "missing". I believe several of the Rust language designers are very familiar with C++, and to say that something is missing implies it was an oversight or an accident, or maybe they'll get to it later. Instead, I believe they don't value some of the powerful features in C++ and ignored the fact that other people find those features very valuable.

Here's an example that has bitten me several times now. Try and implement the following C++14 code in Rust:

    template<class T>
    struct Something { T a, b; };

    template<class S, class T>
    auto operator *(const S& x, const Something<T>& y) {
        return Something<decltype(S() * T())> {
            x*y.a, x*y.b
        };
    }

There are ugly workarounds, and I'm certain they have their reasons, but it's so much simpler and cleaner in C++.

> You can do everything in Rust that you can do in C++, and the compiler will catch (nearly) all the bugs you would have left in the equivalent C++ project.

This is a bold claim, IMO somehow misleading. To "do everything you can do in C++", you have to use the unsafe part of rust, where you essentially lose of the compiler guaranty. Second and maybe ever more importantly, rust never promise the remedy to "nearly all bugs", the universe of bug preventable is a well-defined limited set.

> A friend of mine put it into good words: Go and Rust are two big conclusions, to big follow-ups to the C and C++ world.

Go isn't a replacement for C; you can't use it for many forms of low-level systems programming, because it has a runtime. Go provides a high-performance replacement for things you might otherwise write in Python or similar, and in that capacity it works quite well.

Rust can do anything C can; its capabilities build upwards from bare metal, not downwards from higher-level languages. It intentionally doesn't have a runtime, and its approach to avoiding garbage collection (namely borrow checking) provides safe memory handling without a runtime at the expense of being a novel language feature without analogue in other languages. Much of the learning curve in Rust comes from that.

I think we like to say things like "C has no GC so it's good for kernels, Python has a GC so it's good for blah blah". In reality, we've definitely written plenty of "python level" (application level) software in C, and the same is happening in Rust.

> In reality, we've definitely written plenty of "python level" (application level) software in C, and the same is happening in Rust.

Oh, absolutely; you can certainly write higher-level code in Rust, and it makes for a far more comfortable experience than writing higher-level code in C. I didn't intend to suggest otherwise. And the ongoing futures work helps Rust address several additional areas that Go does well.

However, I don't think it makes sense to group Go and C together, syntax aside. Go cannot replace every use of C, because of its runtime and related expectations. (You can push it into some low-level environments if you make accommodations for its runtime, but you can do the same for languages like Python. You wouldn't necessarily want to do so in production, though.)

I agree with all of that except that I don't see Rust as the safe follow-up of C but rather as the anti-thesis of C. Indeed knowing C will not help you. They're both imperative and that's pretty much it.

I've found Rust to be quite enjoyable, sometimes the borrow checker is annoying but you get used to it pretty quickly.

I only play around with it for personal projects but I would have thought that if I went from scratch and spent four days on it like the article stated that I'd be pretty productive.

I wouldn't put Go as a follow up to C world. More like to Java one. But Rust is indeed a follow up to C/C++ world.

Well yes: touted as 'a better C' but I suspect they've succeeded at 'a better Java'. But it's more fair to say that Rust is a _retry_ at creating a C++-like language organized around concepts of safety and ML-like features ('like C and Haskell had a baby' as one person put it.) You can get _quite confused_ applying C++ concepts blindly in Rust ;)

> It's a pain to get working, it sucks to program in, it requires so much thought, it's just a bloody fucking fuck.

It's too bad that you feel that way but lots of people like programming in Rust and don't like programming in Go. I have never before had to pay so much -- in terms of type annoyances, packaging workflow and boilerplate -- for so little.

> to attract more non-genius developers

It's not like that, it's not hard to need geniuses, it's just too different for most people. And different takes time to learn. Which is definitely a design flaw for a language aiming for some adoption. I don't think they can improve it at this point, but they can provide a lot of value where other languages are weak.

Your comment and others on Rust here sound a lot like people learning Haskell. There is a similar frustration with fighting the type system and weird concepts (Monads). I believe lazyness is the biggest problem with Haskell and Rust is eager, so Rust should be more successful than Haskell.

The Go comments sound a lot like Java in the early days. Easy language. Quick to get started. Easy to get lots of programmers. If desperate, just train them. Today Java is not so simple anymore, because the Pros wanted more features (eg Generics). I believe Rust will get Generics at some point. Typesafe containers are too useful.

I think you mean "I believe Go will get generics." Rust already has generics: https://doc.rust-lang.org/beta/book/generics.html.

I certainly hope the Go authors can find an implementation of generics with a set of tradeoffs that appeal to them. Typesafe containers certainly are extremely useful.

I like generics as well, but this comment (and embedded links) made me appreciate why Go doesn't have them yet:

  https://news.ycombinator.com/item?id=9622417

I agree, the value in generics/templates is in not cutting and pasting an algorithm or container to handle multiple types safely. A true macro system (and Rust's is pretty good one to model after) also solves this problem, and I wonder if Go would ever consider adding such a thing. It seems like a safer approach.

Did they consider the OCaml approach of "generic modules"? I would combine it with C++-style instantiation. By having it on the module level instead of functions/structs, you should be able to avoid the linker bloat. Are there OCaml users in the Go community?

Also, there is the hybrid method between C++ and Java, which C# implements: Instantiation for value types and type erasure for reference types.

> Did they consider the OCaml approach of "generic modules"?

Heh, I certainly can't speak for them, and I don't know what they've considered outside of that link. I also don't know C# or OCaml well enough to say if Go should/could adopt their strategies. However, Java's generics aren't very satisfying, and I think Go is wise to not jump in prematurely.

Hygienic macros (as in Scheme or Rust (Nim? Elixir? Julia?)) seem like a more mature concept that could solve most of the problem.

This is the same experience I had with Go, I come from a Python background, I learned how to write webapps in Go and now am comfortable writing programs in Go. I don't find the lack of generics to be an issue.

This is an interesting thing I realized after I read the postmartem report of why "rethinkdb failed".

Users want something they can get and build apps with quickly, rather than something feature perfect four years after they want to build apps.

Go essentially answered the question, "I want to write a webapp, don't want to use Python or RoR, what do I use?". It is because of the easy to understand syntax and the powerful stdlib they were able to answer that question.

The language is amazing. I don't have any idea about Rust, so won't comment on that.

> I've attempted to learn Rust a few times, and it always feel like I'm moving uphill.

Isn't this also because it's actually quite a bit different from other languages? I think how difficult something is to learn is largely dependent on how similar it is to something you already know.

I can see how from a business standpoint, being able to start coding is great, but I also feel a bit sad when I see people not really giving a language a real chance, especially when a week or two may not be all that significant in the long run, whereas choosing a technology is potentially pretty significant long term.

I'm not quite willing to dismiss Rust merely for being hard to learn, but after poking around in both Go and Rust for a few weeks, I feel like I could build a project in Go (slowly, and with a lot of googling), but I don't feel like I could build anything in Rust without a lot more learning.

Rust has the same problem as C++ (to a lesser degree; maybe it'd be more fair to compare it to Java), in that if you're a casual coder who dips into a bunch of different projects in a bunch of different languages without ever really specializing, it can be overwhelming. Go is much more readily accessible; partly because it is less ambitious, and partly due to philosophical differences. I can read most Go code, today, having only worked through "A Tour of Go" on the website; I can't even begin to read Rust code after similar time/effort invested.

So, yeah, Rust really is hard. It may be necessary complexity to solve the problems they wish to solve. But, it means I'm unlikely to ever have the time to invest to make it a part of my toolbox, unless it becomes my primary job; whereas I'm already almost there with Go. I'll probably build something real in Go within the next month or two. It can be something I do for fun, in my spare time, and I can expect to get useful results.

I want to like Rust. I'm just finding it hard to get to know Rust.

I wouldn't worry about trying to learn enough about Rust to be able to develop something in it before you try. It is an extremely difficult language to learn. I tried reading over the section in the book about ownership and borrowing a few times and just didn't get it. For me and the other rust developers I've worked with, the best way is to just dive in, fight the checker and eventually it will make sense.

For me I feel like it took time but I've formed a good intuition and understand of the rules, but I would have a very difficult time formalizing a description.

> I want to like Rust. I'm just finding it hard to get to know Rust.

      -- every single developer

I feel this conversation will be slightly different in 2018. The Rust team set their goals and vision for 2017[1][2] and the theme of the year is largely "ease of use."

I'll quote some of the proposed vision statement here:

  # Rust should have a lower learning curve
  
  Rust unique features make it valuable, but also means there's a lot to learn.
  A common refrain is "the first couple of weeks are tough, but it's oh so
  worth it." How many people are bouncing off of Rust before they get through
  those first couple of weeks? How many team leads are reluctant to introduce
  Rust because of the training needed? 1 in 4 survey respondents mentioned the
  learning curve.
  
  Some potential avenues: improved docs/training materials; improved compiler
  errors; language improvements (e.g. things like non-lexical lifetimes).
  
  # Rust should have basic IDE support
  
  For many people—even whole organizations—IDEs are an essential part of the
  programming workflow. In the survey, 1 in 4 respondents mentioned requiring
  IDE support before using Rust seriously. Tools like Racer and the IntelliJ
  Rust plugin have made great progress this year, but compiler integration has
  yet to get off the ground, and there's a lot of room to do more.
  
  # Rust's community should provide mentoring at all levels
  
  The Rust community is awesome, in large part because of how welcoming it is.
  But we could do a lot more to help grow people into roles in the project,
  including pulling together important work items at all level of expertise to
  direct people to, providing mentoring, and having a clearer on-ramp to the
  various official Rust teams. Outreach and mentoring is also one of the best
  avenues for increasing diversity in the project, which, as the survey
  demonstrates, has a lot of room for improvement.

[1]: https://internals.rust-lang.org/t/setting-our-vision-for-the...

[2]: https://github.com/rust-lang/rfcs/pull/1774

Rust's community should provide mentoring at all levels

This was an issue as I learned. With widely popular languages, googling a simple question like "reverse a list javascript" or "sum an array php" comes up with a hundred different suggestions and discussions.

With Rust, most of the discussion is very low level, often by people working on Rust itself and usually the rare answer you find is terribly out of date.

Just having a more stable language so answers don't become obsolete is a big step, but it will still take time for those very basic questions to get answered.

Are those real example questions? Cause I stackoverflow program a fair share, but those seem a little bit low level for any language, and if you google those for Rust, I end up with the docs for Vec and Iterator, which contain exactly the reverse and sum methods. And this isn't some case of "fuck you read the entire docs", the methods contain extensive built in examples (copypasted from their respective method docs):

   let mut v = [1, 2, 3];
   v.reverse();
   assert!(v == [3, 2, 1]);

   let a = [1, 2, 3];
   let sum: i32 = a.iter().sum();
   assert_eq!(sum, 6);

I'm not saying everything is simple, and there are hard parts of rust to learn. But as far as solving simple problems, I haven't ever had an easier time then with Rust.

Are those real example questions?

No, they were just off the top of my head, not to be taken literally.

And the docs aren't organized as a tutorial. If I don't know what a method or type does, or even that it exists, I'm not going to know to look there for examples.

Ok fair enough. Those two examples though are specifically not good examples, and its hard to improve documentation without specific examples of what is missing.

I've found the Rust community on Reddit to be very helpful. Every one of my questions, from borrow checker errors to compiler internals, has been answered within a day.

> I'm not quite willing to dismiss Rust merely for being hard to learn, but after poking around in both Go and Rust for a few weeks, I feel like I could build a project in Go (slowly, and with a lot of googling), but I don't feel like I could build anything in Rust without a lot more learning.

I can totally relate to this: I spent almost a year reading blog posts about Rust or comments on /r/rust, between the first time I read the Rust book and the time I fell confident enough to write m'y first Rust software (a cli tool).

In the meantime I learned Go in three days and I was able to work with it.

Why did I continued to learn Rust your may ask ?

Comming from web languages, learning Rust was a pilgrimage. I learned so much about low level computer sciences: what is memory locality, what's a data race, how does a memory allocator work, what is inlining, etc. It was definetly worth the time I spend on it.

And now that I'm proefficient with both Rust and Go, I can tell I prefer Rust by a large margin. Rust is a really well designed language, with a really nice community and a decision process designed to improve the language with feature real people need. Whereas Go is a monolyth controlled by its creators built around the dogma of symplicity at all cost, and they usually reject users proposal for improvements.

Besides the politics, Rust is way more expressive and going back to Go is always boring because of the boilerplate. It's also way easier to shoot yourself in the foot in Go than in Rust, by ignoring error, misusing a shared variable (forgetting to use a lock, or using it improperly) or dereferencing a null pointer.

In short IMHO Rust is more difficult to learn than Go, but you learn more and when mastered, the language is more helpful.

To all of you strugling learning Rust: carry on, it's worth it ! And also, don't wait and go on #rust-beginners [1] on IRC[2], it's really helpful.

[1] from a web browser: https://client00.chat.mibbit.com/?server=irc.mozilla.org%3A%...

[2] irc.mozilla.org

Rust and Go are not readily comparable. Rust is a systems language aimed at the same domain as C++ and, to an extent, C. Go is more akin to Java and Python. ESR almost admits this:

"Latency and soft-realtime performance

"Again, zero-overhead abstractions and no stop-the-world GC pauses give Rust a clear +1.

"It is worth noting that Go came nearest disqualifying itself entirely here. If it were not possible to lock out Go’s GC in critical regions Rust would win by default. If NTP’s challenges tilted even a little more towards hard real time, or its critical regions were less confined, Rust would also win by default."

As an aside, if ESR couldn't get Rust's ownership model, I wonder how long it took him to internalize how not to write memory bugs in C?

i guess it was in a way easier because the C compiler doesn't call you names if you make a subtle bug and rustc states its opinion about your work in no uncertain terms. it's harder to get going in rust, but once it goes, it usually doesn't stop.

Unless you read segfaults and core dumps as insults, of course :).

You learn to love the compiler. It becomes a symbiotic relationship, and the cycle times for refactors and debugging are short because you get such quick up front feedback. Your productivity certainly takes a hit initially though.

A symbiotic relationship is an apt way to phrase it. Most of my invocations of rustc aren't even to actually compile an executable. Typically I'm running something akin to a cargo-check[1] to ask rustc some questions about my codebase: What type did you infer for this binding? Are these generic bounds precise enough? How long can I keep this reference around?

In C++ I loathe generic programming, a template instantiation error is something I fear. Whereas in Rust I knowingly compile broken generic code all the time, because the errors are (usually) good enough to help me fix it.

[1]: https://github.com/rsolomo/cargo-check

> Rust and Go are not readily comparable. Rust is a systems language aimed at the same domain as C++ and, to an extent, C. Go is more akin to Java and Python.

In a sense yes, although Go compiles to native code and offers completely different performance compared to an interpreted language like Python, and no JIT warmup periods of JIT compiled languages, and no dependencies on runtime environments or virtual machines, and from the outside runs confusingly similar to a native C application.

Also, C/C++ is such huge languages that they are in use in _far_ more scenarios than low level systems programming. Maybe that was the intention when they were designed, but usage exploded on e.g. Windows before the days of .NET and many still prefer it over .NET due to performance. Even if these are then desktop applications using Win32, Qt, or even MFC. C is also heavily used in development of e.g. GNOME applications with GTK+. Also a huge field of non-system level desktop applications. C / C++ is also usually preferred for games development.

This is why I think there's room for Go even in the context as a C/C++ successor simply because of the field where C/C++ is used is just so darned huge, although I do agree that if the application here is a close-to-metal application where you don't have time to wait more than a millisecond on a garbage collector or need complete control over memory use, Rust may be more useful and in this sense yes, be more like a spiritual successor to C as well.

> As an aside, if ESR couldn't get Rust's ownership model, I wonder how long it took him to internalize how not to write memory bugs in C?

Rust's type system, like any type system, is limited. It enforces a certain style of safe programming and will reject other styles of safe programming.

The compiler is also not great at explaining why something is wrong. I'm not knocking the compiler writers, because it's a hard problem and they're putting serious effort into it. But from ESR's perspective, he's writing code that is safe (according to a style he's developed over decades of programming) only to have it rejected with an explanation that doesn't make sense. It's frustrating.

There are ways to improve the learning experience. You can improve documentation, improve compiler error messages, and improve the type system itself (e.g. non-lexical lifetimes). The Rust team appears to be taking all of these seriously.

I think the people who make it past the initial frustration are those who believe that it will be worth it. I'm a huge fan of type safety guarantees. I've also followed the development of Rust enough to know that the people making decisions are good at designing languages. So when I'm frustrated, I remind myself that this is probably all worth it.

But reading ESR's write-up, he's clearly not coming from the same place. He believes that Go and Rust both have "strong type systems", which is clearly false. He complains about Rust exposing an unsafe construct like mutexes without realizing that Rust mutexes are much safer than in C. But to be fair, he's also thinking about a specific project that needs an efficient epoll-style mechanism and Rust is just not there quite yet.

The concurrency complaint is strange, as almost nothing in it is correct.

1. Rust never "course corrected" to implement CSP, and as far as I can tell ESR is making that up.

Rust actually implemented channels and tasks as builtins first, with no mutexes or shared state available--those came later. At some point we saw the opportunity to reduce the complexity of the language and move the language closer to the metal by moving channels and threads to the library instead of keeping them as primitives. Mutexes and reader-writer locks followed a year or two into the language's development--in fact, they were partially implemented on top of channels at first. In fact, the motivation was essentially "hey, look at this neat thing I can do with borrowing: safe mutexes!", not "let's get rid of channels".

2. The idea that channels are going away is also untrue. I've heard a couple of people wish that channels could be removed the standard library and moved to the nursery since they're a fairly complex implementation, and embedded users might want a slim libstd. But nobody has ever floated the idea of channels just vanishing outright in favor of shared state and mutexes: it's absurd. Moreover, the standard library is stable and must be supported going forward, so we can't make that change even if we wanted to.

3. Go has mutexes as well. They're right in the library in the "sync" package. They're fairly idiomatic too: embedding a mutex in your structure as an anonymous field so that your structure can inherit the Lock() method is common.

4. ESR needs to be clear about exactly what defects can arise with mutexes. If he were to enumerate them, he'd find that Rust's type system is carefully designed to avoid them.

A very useful post. Can you answer his complaint about epoll as well (maybe you did already, and I don't know rust will enough to identify your answer).

I thought this comment about epoll explained it pretty well: https://news.ycombinator.com/item?id=13431639

Ah, right. It does.

I assumed that the claim about channels going away was a reference to this: https://github.com/rust-lang/rust/issues/27800

That's not at all the same as channels going away.

I keep going back to the Simple Made Easy talk by Rich Hickey, creator of Clojure.

Easy vs Hard as in: - Easy to learn - Familiar looking - I know most of it already vs - Hard to learn - Nothing works as I'm used too - It's all new to me

Simple vs Complex: - Its parts are self-contained - The parts don't depend on each other - Quick to get something done once you understand it vs - Can't separate the parts from the whole - Each part depends on other parts - Slow to get something done even if you understand it

Most programmers and businesses value Easy vs Hard, because they think about themselves, not delivery of great quality software. If you focused on delivery of great quality software, you'd conclude hopefully that easy vs hard doesn't matter as much as simple vs complex.

Having said that, I think Go is easy, and for the most part, it is also pretty simple. While Rust I'd say is hard, but also very simple. Its simple in Rust to make correct software, but not easy. C is easy, but complex. C++ is kinda hard, and also complex.

So both Go and Rust are great improvements. Go chose to still be easy, at the detriment of how far it could innovate, but it still innovates. This approach is pretty smart, because what will happen probably is that a lot of people will move to Go, as it is not a very hard change from what they know, and then they will move to Go + 1, and then Go + 2, and then Go + 2, and eventually they'll end up at Rust, or something similar. Doing it that way is easier.

You're missing a key element from Rich's talk: Complexity occurs when things are complected. That is, when two separate concerns are tied together.

There's lots of this in Rust, especially in the form of premature specialization. If you define a struct or a method in Rust, you might be forced to make some decisions about lifetime, static vs dynamic dispatch, memory representation, mutability, etc.

These things are tied together deeply in order to create a tractable space in which the type solver may operate. Granted, this may also create a tractable space in which for you to think about these same issues, but that doesn't mean its any less complected/complex.

And yet that's inherent complexity, not accidental complexity. The way that other languages simplify this is by hiding the complexity behind a garbage collector, which Rust's domain can't tolerate.

I don't necessarily disagree.

Although in the context of the simple vs easy notion, I suggest you grep this page for "inherent complexity":

https://github.com/matthiasn/talk-transcripts/blob/master/Hi...

He talks about the inherent complexity in resource contention.

I will point out one choice quote:

"It's making things complex because that's a decision that needs to be made by someone who has better information."

Rust addresses this by forcing you to highly parameterize code statically, which is probably the least bad solution we have right now for this sort of stuff in a low-level language.

I know Rust is complected somewhat, that's why I specified that it's simple to write correct programs in Rust. So in that perspective, it's very simple at tackling such a complex problem. You'll find doing so is even more complected in C.

I'd agree that to me that's just inherent complexity. Let me explain.

Imagine the safest language ever, literally, by design, it prevents all bugs, except for functional ones.

Now implementing anything to the extent that there's 0% bugs is inherently complex. It might be so complex that possibly no program ever written even achieves this, in any language.

That hypothetical language would not be able to make that complexity disappear, because it's part of the problem space, and not the specific design of the language.

In most languages, we avoid this complexity by ignoring it. We allow buggy software. We generally say, as long as the bugs that exist either don't occur in practice, or don't impact users that much, it's good enough.

But, let's go back to Rich's talk. Why was he talking about Simple vs Complex? Because complex code leads to bugs. If your language's complexity leads to bug free software, the argument would change. In this case, just work harder to understand the complexity and get it done. You're then guaranteed safety.

Rust is by no means this language, but it's the closest we have currently in that space. Because of that goal, it's tackling quite a lot of complexity. Maybe some of it is accidental, and Rust2 could improve on that.

Having said this, sometimes it's fine to allow bugs, if it allows productivity. Use Clojure in those cases :p

> Learning curve

No pain, no gain, but sure.

> Translation distance

62K lines sounds like typical C with no code reuse to speak of, A clean-slate rewrite I'd hope would be much smaller, though admittedly talking about corrode and c2go speaks of the other direction.

> Concurrency

No mention of Rust being data-race-free and Go not; unacceptably lax.

> > While I give the Rust designers credit for course-correcting by including CSP, Go got this right the first time and their result is better integrated into the core language.

Wat. Rust was originally all about CSP too, but they went away from that because there was no need to stay. You can still do all the channel stuff you want but there's little benefit force that idiom. Go's special support for this is like....special-cased generics right?

> epoll

Mio? (sure future-rs is not yet ripe, but mio alone is last I checked.) Overall, ESR seems sprinkle in lot of hatred of dependencies (bloated standard libraries are such a crutch around not having a good ecosystem), which I personally find laughable as the brightest future of FOSS is large-scale code and abstraction reuse as Haskell, Rust, and the like, are just making mainstream.

> 62K lines sounds like typical C with no code reuse to speak of, A clean-slate rewrite I'd hope would be much smaller

Um... you can derive the amount of code reuse in a project given no other information than the number of lines of code?

I mean code reused from upstream libraries. An internal abstract should either be moved out, or probably isn't that interesting anyways.

If your abstraction has a real-world vs purely mathematical / programmatic purpose, it probably sucks.

Functor > UserLoginFactoryBean.

This is confusing. By far the most words of any concern in this piece are dedicated to a root concern that Rust doesn't have a select/poll abstraction, and that idiomatic network code simply allocates a task per socket. But that's true of Golang as well; not just true but distinctively true, one of the first things you notice writing Go programs.

Au contraire: Go has a built-in 'select' keyword that lets you wait on a set of arbitrary (blocking) channel operations. Start up blocking I/O in goroutines, and select on channels that give you the results.

A goroutine is a "task" though. And typically you spin up a goroutine for your select, and hang your current goroutine on its completion.

Seems pretty similar to me.

For networking, it's using epoll() under the scenes; depends on what exact non-blocking operation you're using, though.

See this very very old HN thread:

https://news.ycombinator.com/item?id=3565703

(Hopefully the standard library has improved since then.)

Channels are not network sockets; select cannot be used to wait on a set of network sockets.

(Early versions of Go had a "network channel" concept, but that was removed from the language: https://softwareengineering.stackexchange.com/questions/1540...)

That's not access to the raw system's select/epoll.

It just happens to offer a similar model (and have a select operation).

select{} has nothing to with select(), epoll etc. It works on channels only, which are not implemented using those syscalls.

https://www.reddit.com/r/golang/comments/1aajw0/just_landed_...

While this confused me a bit too, there's definitely an epoll implementation in the golang syscall package which I'm guessing ESR was planning on using instead of net? Rust doesn't have such a thing in their std lib, although tokio seems perfect for this

Edit: Does "But that's true of Golang as well" refer to the one thread/socket model or not having epoll? I may have misinterpreted what you were saying...

It would be extremely janky to write a Golang network server coded directly to select/poll. You would lose most of the networking libraries for the transactions based directly on it.

(I know it's doable; I did it for a portscanner, where I needed fine grained timer control. But I had to forego the Go networking stack to do it.)

Golang allocates a _goroutine_ per socket. Those goroutines are actually scheduled using epoll (https://golang.org/src/runtime/netpoll_epoll.go). Goroutines are _very_ light (8KB stack size) and don't incur nearly the same cost as a thread in a "context" switch. While for some (honestly very small) subset of problems they are still too large most people will never need to worry about them.

I have production systems which run several 100k goroutines at once with very little overhead.

Wait, the only way to do concurrent network programming in Rust is to allocate an OS thread to every connection? That doesn't sound right.

And it's not right. Rust programs can use epoll directly or through abstractions like mio and tokio.

Thread-per-connection is the simplest way to do concurrent networking in Rust using only libstd, but it's not the way that most Rust programmers would actually use (at least, not for a production server handling a large number of connections).

IIRC that's the only option in the standard library, but event loop and coroutine implementations are available from the crate ecosystem.

Rust Core team member here. Out of the box, the Rust standard library only provides very basic networking support [1]. If you want to process requests in parallel, then yes you need to spawn an OS thread to process the request. We went with this model because we wanted to have the standard library be portable across all our supported platforms, and there isn't really a great standard for doing portable IO.

Instead, we're layering platform-specific code in external libraries. At the raw C-level bindings, we have libc [2] and winapi [3]. For higher level APIs, we've got Mio [4] which abstracts the system APIs, and now Tokio [5], which uses futures to simplify async operations.

We're just working our way up the stack. All of these are being developed by members of the various Rust teams, so they're as "official" as everything else we're doing.

[1]: https://doc.rust-lang.org/std/net/ [2]: https://crates.io/crates/libc [3]: https://crates.io/crates/winapi [4]: https://github.com/carllerche/mio [5]: https://tokio.rs/

No, there's tokio, but it is not in the standard library.

    Goroutines are _very_ light (8KB stack size)

2kb, actually.

That's curious, as I've always considered 2 pages (1 unallocated) the absolute lower bound for a thread stack size (1 page of actual, allocated memory for stack, 1 page unallocated as a guard page to detect overflow.)

If a goroutine calls into C, and the C code overflows or otherwise writes ‼Fun‼ onto the stack¹ … can it clobber an adjacent stack of another goroutine or other memory?

C code runs on a larger special stack (that's part of the reason calls to C are slow). I don't know whether or not guard pages are added.

There are no added guard pages.

> While for some (honestly very small) subset of problems they are still too large most people will never need to worry about them.

This is also true about OS threads!

It's worth noting that the author is Eric S Raymond, who we all know of...

I'd definitely agree that at this point Go is better for network services, and the learning curve / documentation / infrastructure of Rust is a bit scattered. I believe that as Rust matures it'll be better for the non-server stuff (no GC, etc.) and eventually become competitive with Go in this space. I'm quite fond of both languages, though!

Yes, he is notorious, but the reasons for his notoriety aren't specifically and instantaneously relevant here. Your statement is indirect, but still quite clearly praeter hominem.

I think it is very relevant - the author of "The Cathedral and The Bazaar" tried out two fashionable new languages, one coming from a corporate team and one designed by a community ... and went with the Cathedral option. As a fan of both languages, I just find it very interesting!

I'm not certain how you concluded Go was the Cathedral option. I came to quite the opposite conclusion: you'd better cross yourself and genuflect in Rust.

I agree. Go seems to have adopted a worse-is-better approach in a few areas and according to this article, it's paid off.

Go started out to address the problems of a particular large corporation with a gigantic C++/Python codebase, and was conceived by a small team of well respected industry experts.

Rust started out as the new generation engine of an open source browser, conceding that no existing language met its needs, and has been community driven since that point, often making breaking changes in pursuit of the ideal.

Go has indeed been very open to community input, but of the two, it seems clear that Rust is the bazaar, and Go is the cathedral, no? I'd love to hear how you arrived at a conclusion to the contrary.

From the outside, Rust and Go were both originally developed by corporations eventually with community involvement. The credit line for Rust has been changed from the original Mozilla to the Rust Project Developers. Go has remained Google.

https://github.com/rust-lang/rust-packaging/pull/49/files

But I don't see this corporate history as at all indicative. By comparison, Unix was originally developed by Ma Bell whereas Lisp was developed by a community. My view is based more on the resulting languages rather than the process that got them there.

Again, though, this is from the out outside.

To be fair, Mozilla is a very different sort of corporation than Google. Notably the Mozilla Corporation is owned by the Mozilla Foundation which is a non-profit.

(As a disclaimer, I'm a biased ex-intern.)

Rust was created before Mozilla got interested in it: http://www.steveklabnik.com/history-of-rust/

For anyone else who gets confused by this empty-seeming page: it's a slideshow. The right arrow key moves through slides.

Rust was in development for 3 years before Mozilla's involvment.

I would also note that Rust's development model is a lot more open, Go doesn't even accept pull requests.

Go does accept pull requests, just not GitHub ones: https://golang.org/doc/contribute.html#Code_review

(I don't disagree with the premise though, Go does seem to be less community-driven than Rust; e.g. Rust has 3 mozilla employees in the top 10 contributors for the most recent release[0], where as Go has 9 Googlers in its top 10[1].)

[0]: https://github.com/rust-lang/rust/graphs/contributors?from=2...

[1]: https://rakyll.org/go18cls/

It also seems to require a CLA and a bunch of other barriers. Everyone's on Github - not accepting pull requests on there (without a CLA) limits the contributor pool.

The copyright for Go has been

  Copyright YYYY The Go Authors.

ever since its public release in 2009. Google only holds the copyrights for the subset of contributions to Go made by Google employees, but there's no Google credit in the sense you're describing.

Rust may lambast you at compile time. That gives you more security and less need for genuflection at run time.

I totally appreciate that value proposition. I chose Rust over Go.

My apologies, I can see the rails now.

He actually addressed precisely this issue on his personal blog: http://esr.ibiblio.org/?p=7303

OTOH, something he doesn't mention in the article is that he's a big Python fan. And Go seems to appeal to the same developer base.

If you read why ESR is a Python fan, it turns out to be similar to the reasons he liked Go in this article: ease of learning and a simplicity that led to writing working code on the first run.

http://www.linuxjournal.com/article/3882

> a simplicity that led to writing working code on the first run

...whereas Rust optimizes for the property "Once it compiles, it's probably going to work flawlessly on the first try."

You do spend a lot of time having a conversation with the compiler first. But I like that mode of working; even in Ruby, I have a long "conversation" with my unit tests before I ever run anything.

> writing working code on the first run.

Rust very much lets you write working and less buggy code at first run, if perhaps not the first compile.

Indeed, it's a mentality I don't share, but I understand the attraction of a gentle on-ramp. Of course, a bit of time spent understanding why Rust made different decisions might have been illuminating.

Would we be discussing this if it were anyone else writing a language review after 4 days? And for a 62kloc project?

Have to agree with you there, the post is mostly light on details, but it's interesting that ESR can't get over the borrow checker. I wonder if he really tried or was already set on Go anyway.

This seems like a common enough complaint. I don't think there's a conspiracy theory against Rust. :)

No, I meant it that Go already felt like the right tool, so unless he could get into Rust really quickly, the decision was already made.

Ah, my mistake!

I think this really over emphasises the difficulty in writing code with a different programming language. The hard part is generally finding a good solution to the problem you're working on...

When I've worked with Rust, 90% of the time I found it just as easy as working with something like JavaScript or Python. However 10% of the time it becomes much much much more difficult. And those times I often end up going in the wrong direction, reading documentation and trying to apply a solution which doesn't fit (i.e. no syntax that will make things work because I am fundamentally doing the wrong thing).

For example, the other day I tried solving a problem in which I had to do an in-place matrix transposition on some slices and I was getting a bunch of compile-time errors for everything I tried. I googled later on and found this [0], which makes it seem like I would have needed to use `unsafe`, however maybe that's just a misunderstanding and there is a safe way.

People are making it out to be harder than it actually is. The semantics aided by the compile-time errors make most problems quick to solve. It's very expressive and gives types which help to avoid fragile code (e.g. `Result` and `Option`). The only times that it becomes difficult are when you need to reach for a solution but do not know what to search for, and I think this could be improved if some of the errors linked to related topics, and once the IDE support improves.

[0] https://athemathmo.github.io/2016/08/29/inplace-transpose.ht...

I like it because usually that 10% of the time is where I should really be focusing my attention.

Just glancing at that code: the use of unsafe is more or less only there to avoid initialization & bounds checking. Basically it's an optimization, and I don't think there's anything there that couldn't be accomplished in safe Rust.

I have an idea as to why the author approached it this way: typically Rust wouldn't let you take out a mutable borrow to a vector while you're iterating over it. If Rust did allow that and you modified the collection then the iterator might reference freed memory!

A common way around this is to just use a typical `for <range>` loop and index into the array directly to limit the scope of the mutable borrow to _a single iteration of the loop_ and not _the lifetime of the iterator._ However indexing in Rust incurs a speed penalty for bounds checking, and the unsafe code here lets you skip those checks.

Really all the unsafe code is doing is saying: "I promise to initialize `rowcol` entries, and I won't try to access anything outside `rowcol`. Please don't burn cycles worrying about it Friend Compiler."

It looks to me as though this could've been written as a vector initialized with all zeroes (which possibly isn't even that expensive, since modern OSes heavily optimize the case of giving you a zeroed page.) Then in the hot loop the author could've just used iterators to avoid the bounds check. Using an iterator for that should be fine in this instance since you're immutably iterating over one matrix, and the only mutation happening is in the new transposed matrix.

That all being said: transposing the matrix in-place would run into exactly that scenario. now you could still do it in safe rust, you would only need to add the unsafe code if you wanted to turn off the bounds checking for maximal performance.

The latter half of the post is pasted from a previous blog post last week, which has been discussed at length at https://www.reddit.com/r/rust/comments/5nl3fk/rust_severely_... and https://news.ycombinator.com/item?id=13385530 .

TL;DR: we have some concerns. :P

I find his conclusion strange, he counted the score as 3 points for Go in ease of learning, ease of converting a C code base to it and concurrency. He also gave Rust 3 points in zero-overhead deployments, better latency and real-time performance, and better security and safety.

I agree 100% with this scoring. I'm not sure though why he weighted the 3 pros of Go as more important for NTPsec since the goal of the project are: "Our goal is to deliver code that can be used with confidence in deployments with the most stringent security, availability, and assurance requirements." Given this goal I would personally say that safety, security, deployment ease and performance are critical, which given his pros and cons would make Rust a better candidate.

It seems that the author places a lot of emphasis on the maturity and future prospects of various libraries. I'm surprised that Rust was so quickly dismissed as tokio seems to have a bright future ahead of it.

What I do think is a fair point is Rust's learning curve. With that in mind I would like to suggest a third alternative: Nim.

Support for epoll/kqueue/IOCP has been in Nim's standard library for a while now and is already very mature. The learning curve is probably somewhere between Rust and Go. In addition Nim also offers a GC that is predictable and controllable.

Given how demanding ESR is with regards to 10+ years stability, Nim hasn't even reached 1.0 yet. I love Nim and your contribution to the Nim ecosystem, but yeah, convincing ESR with 0.16.0 isn't happening.

Nim could be ideal for applications like NTP that require speed, portability and low memory footprint.

I wonder if the ease of development already outweighs the efforts required to keep up with the language growth pains and writing wrappers for system libraries where needed.

the maturity and future prospects of various libraries.

The current maturity and future stability. Tokio's own page says, as of a week ago says:

"Today we are publishing the preliminary version of the Tokio stack, 0.1!"

tokio is far from mature and its claims of stability are even less so. I can't think of many Rust crates that I'd seriously put in the "this seems actually stable and mature" bucket as yet. That's in part because Rust itself is only recently stable (and given how recently it's pretty generous to call it stable).

One big advantage of Go is that core packages exist for most of the things you might want to do on a server. Those packages are mostly maintained by Google employees and are used within Google, so the packages are exercised and maintained. Rust, like Python, has a large collection of packages maintained by random people and not under organized maintenance or testing.

"Corrode" needs to get a lot better before it is useful. Look at the Rust it generates.[1] It transliterates C into unsafe Rust. That's not too helpful. Doing such a translation well is a hard problem. The translator will need to figure out exactly what needs to be mutable where, which means building a graph of the program across function boundaries.

[1] https://www.reddit.com/r/rust/comments/4rv0uh/early_stage_c_...

I am not sure it is possible to auto generate safe Rust code, due to the nature of C.

You'd have to do a lot of flow analysis.

The first step would be to make everything const that can possibly be const. Const stuff can be borrowed non-mutably. Then make all variables have as narrow a scope as possible, even if this means putting in more bracketed blocks. Variables which are not initialized at declaration should be combined with their first assignment whenever possible.

Then you have to analyze what can have single ownership and what can't. Non-single-ownership data has to be refcounted. That makes the borrow checker happy, but may result in excessive refcounting if the analyzer can't track usage through complex code.

Pointers need to be analyzed for usage. If there's no pointer arithmetic, it can become a Rust reference, maybe with a "Some" if it can be nil. If there's pointer arithmetic, the pointer is going to have to be represented as a reference and a subscript.

You need a standard C library in Rust, with Rust safe equivalents of all the string functions.

It's a big job, but not impossible. It might be a marketable product.

Well, couldn't you then be making a safety-checking tool for C? If you can do that, it shouldn't be hard to translate from there to safe Rust.

> It transliterates C into unsafe Rust. That's not too helpful.

From the author's perspective it is helpful. If the goal is to make an existing C project memory safe without sacrificing performance and memory efficiency, one way to do that is to rewrite it in (safe) Rust. An automated direct translation from C to (unsafe) Rust would result in a body of code that would not (completely) satisfy the borrow checker. But some significant portion of the code would, thus reducing the total work necessary to translate the project to safe Rust.

The thing is that you can satisfy the borrow checker by (manually) modifying the Rust code resulting from the automated translation, or, alternatively, you could modify the C code in such a way that the automated translation results in Rust code that satisfies the borrow checker. If you can manage to write C code that automatically translates to safe Rust, then the safety guarantees of the borrow checker also apply to the C code.

So the automatic translator can be used to apply Rust's borrow checker (and its safety guarantees) to C code. This would be one way to, for example, bring a degree of memory safety to embedded platforms that are not supported by Rust, but which do support C. Pretty sneaky, no? (Of course, some of Rust's memory safety is achieved through run-time checks rather than the borrow checker, so it doesn't completely solve the problem for C.)

But satisfying the borrow checker is still a lot of (mental) work, and as I've pointed out, there is an easier alternative. It would be much easier to write an automatic translator from C to SaferCPlusPlus[1]. And even for embedded platforms that don't support modern C++ (or at least its standard library), you can pull the same trick, as SaferCPlusPlus also uses a degree of static enforcement of memory safety (although not to quite the same degree as Rust's borrow checker.)

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

> By four days in of exploring Go I had mastered most of the language, had a working program and tests, and was adding features to taste.

I felt this way too but then realized the advanced topics of Go really take time to get right. Writing correct concurrent code is non-trivial as you need to tailor your solution to the problem at hand. There is no one size fits all way to write concurrent code. In some cases a mutex makes sense whereas channels work better in others.

Programmers must be diligent when using these tools as well because of deadlocks, data races, or go routine leaks. I think this is an area Rust excels in with its ownership model that eliminates these problems.

> For comparison, I switched from Rust to Go and, in the same amount of time I had spent stuggling to make even a <100 LOC partial implementation work, was able to write and test the entire exterior of an IRC server - all the socket-fu and concurrency handling - leaving only the IRC-protocol state machine to be done.

That's basically my experience with rust and go.

go is stupid, but I can write it. It's stupid needing to write the same for loop over and over again, but it's an obvious for loop that doesn't have any surprises, and everyones for loop looks the same.

rust is smart, but I can't write anything in it (yet). Some of rusts features would be nice to have in go.

> same for loop over and over ... obvious for loop that does'nt have any surprises.

Really? Tell me what the output of this short bit of golang code is before running it then if it's so obvious. The first one is only a for loop, nothing else, the second output line is a for loop and some channels + goroutines, but nothing too complicated.

https://play.golang.org/p/g4Pd5ebrWp

I've seen these issues in the wild more times than I care to admit. Go is a trashfire. They wouldn't compile in rust.

Your code is tripping over a complexity of closures, not directly loops. I don't think you can write a straightforward loop that has confusing behaviour without also using closures. Your "but nothing too complicated" underplays that.

My first example did not have a closure. Simplified further: https://play.golang.org/p/ttdmropzSu

It's literally about nothing but how the 'value' variable in go for loops is handled by the language.

To make it worse, a common solution is to do this: https://play.golang.org/p/BTRs_TCQdu

That code looks like line 10 shouldn't be needed, does nothing, and during someone elses refactoring it might be deleted and result in the code blowing up again. No warnings, just silent data corruption.

The second one is a bit complicated, yes, but again I've seen them in the wild. Again they wouldn't have compiled in rust.

You're still being clever in that first example. `string` is a weird data type in Go, and `[]string` doubly so. You're going out of your way to find a confusing example, but that's not what the original poster was saying, which is that you can write a simple loop over and over again that doesn't have surprises.

Bah, the HN markup dropped my asterisks in those types.

This resonates with me in a lot of ways. I really object to a lot of Go's design, but I also feel Rust is too much of a struggle at the moment.

When I write performance critical code in Rust I can see how I'm rewarded for all the mental gymnastics and token salad of Rust.

But when I'm writing something that's difficult or complicated in the business/algorithm sense but not performance sensitive, then I just can't let the syntax obscure the semantics.

The code has to look as simple and readable as ruby/go/Swift/c#/Python/kotlin/Nim -- or the language has failed me.

Right now I feel it's often the opposite. When I write low level Rust code the type system is usually ok. For higher level code I usually find I need more noise and type overhead (more explicit lifetimes, more Box<Rc<T>>). That I think is a big problem.

Rust, like C++ is "you pay for what you use" - but what they mean is performance. I wish it was readability. I almost wish the default was a higher level language with lots of heap allocation etc, and you explicitly declare when you don't want that (c.f C# unsafe/stackalloc and similar)

> I almost wish the default was a higher level language with lots of heap allocation etc, and you explicitly declare when you don't want that (c.f C# unsafe/stackalloc and similar)

I don't know if that's really possible. Aliasable mutation just doesn't play well with the kind of memory model that Rust has. If you introduce unrestricted aliasing and mutation like most other languages, then you're going to get a flood of confusing borrow checking errors.

Hi Patrick, I appreciate you taking your time to object to blurbs that aren't thought through.

I suppose what I'm trying to say is that I'd really like simple code to look simple, and that it's an explcit design goal that code look as simple as possible. Perhaps I'm spoiled by languages that hide memory complexity with a pervasive GC (I am) but I still think there has to be room for improvement (and to be honest there probably are tons of already created issues with possible lifetime elision or coercions that reduce the need for Boxes inside Rc's inside boxes...).

Keep up the good work.

I find the argument that of not being productive in a language in a matter of a few weeks to be quite weak. Programming languages are tools. Tools take time to learn.

Nobody would consider a flute to be an instrument superior to a violin because it can be learned faster. Rust is a tool that takes time to learn. Is it worth it? How could ESR decide if not in hindsight?

My personal experience is that understanding and applying Rusts borrowing and ownership made me a much better systems programmer in C and C++. Would I write a production NTP server in Rust or Go? Definitely Go, but that's no reason to dismiss the concepts and the remarkable engineering of Rust.

ESR seems to care really strongly about concurrency things being "primitives" in the language. Why? There's nothing wrong with them being part of the crates ecosystem. Maybe in 10 years the crate you chose won't be under active development, but it's not like crates will just mysteriously break once they reach a certain age. As for the language itself being stable, sure, a program you write today might not compile using the latest compiler in 10 years, but it should still compile using the last 1.x release, so it's not like you won't be able to compile your project in 10 years.

Something I'm surprised ESR didn't consider is the fact that Rust lets you do a piecemeal translation. You can rewrite individual functions in Rust and call them from C very easily. So you don't need to rewrite all 62KLOC at once.

Go more or less allows you to do the same, but I've heard there are some pain points.

In any case, Rust would probably require some rearchitecturing anyway.

I disagree with many points in this article, but being writing Rust in my company since summer I can definitely say it is much harder than any other language I've used. Now when I learned doing a synchronous service with it Tokio was released and I've been banging my head against the wall to get the concepts.

But then again, it just takes time. And I have some crazy two month uptimes with my rust services eating that constant 8 megabytes of ram...

Adding to this. It's not at all waste of my time to do hard things with Rust. Learning is important and when my employer pushes me to that direction, I'm quite happy writing Rust.

I'm surprised this article is from 2017. It seems that esr doesn't account for the latest (huge) improvements of Rust during the last year.

Given that Rust is younger than Go, ignoring a year's worth of development makes for an especially unfair comparison.

The issues he cited were from 2014 and 2015, regarding Rust for networking code. Moreover, on his blog post (http://esr.ibiblio.org/?p=7294) he received a clear answer that he seems to have ignored:

    Stefano:
    
    [...]
    For epoll: There is a crate. You could also use
    future-rs or tokio. So you have three possibilities.

Finally, the author of another networking project, TRust-DNS, used these Rust features and was quite satisfied with the elegance of the resulting code:

https://bluejekyll.github.io/blog/rust/2016/12/03/trust-dns-...

> So you have three possibilities.

More possibilities isn't necessarily better. ESR makes precisely this point: "While implementations exist in the crate system, there is not yet any guarantee that any of the alternatives will be maintained over 10-year timescales."

Having three possibilities just makes it more likely that you pick the wrong one, the one that will be dropped by its maintainers because the rest of the community chooses another one.

When I first read about Rust and Go they were both advertised as C/C++ killers.

But I have the feeling Go became more of a Python/Node.js alternative.

A lot of this is because Google used C++ where other people were using Python or Node. It was made to "kill" C++ at Google more than outside of it.

Rust is hard to write but I'll grant that once written it is relatively easy to understand. That's kinda the opposite of C++ where it's easy to write and hard to understand (although it's easy to think you understand).

I appreciate the safety+performance value proposition in Rust. More cathedral, less bazaar.

Not THAT easy

    fn apply<A, B, C, F, G>(mut f: F, a: A) 
    -> impl FnMut(&B) -> C // must still be `for<'r> impl FnMut(&'r B) -> C`, because that’s what filter requires
             where F: FnMut(B) -> G, // must not be `for<'r> FnMut(&'r B) -> G`, because regular functions do not implement it
                   G: FnMut(A) -> C,
                   B: Copy, // for dereferencing
                   A: Clone {
    
        move |b| f(*b)(a.clone()) // this must do any bridging necessary to satisfy the requirements
    }

this function signature must be EXACTLY like what I wrote or it won't work

No, not that easy especially when you get to the functional programming stuff. But I find FP hard to understand since I don't use it much.

> this function signature must be EXACTLY like what I wrote or it won't work

This can be seen as a feature in the sense that you can't program by luck: well, this incantation seems about right and the compiler nods its head that it understands and that means something, so it must be right.

Joke's on you: it took me a month of asking around why my program won't compile to figure out I really CAN'T do it without dereferencing inside the function. This is because of higher ranked lifetime bounds... there's no way to express the correct lifetime bound in this case (in Rust, maybe in Haskell it's possible), so you just have to deref first.

You probably have a simpler, clearer way of solving that problem than by torturing the language.

I do, but the problem is FizzBuzz. What's the point of solving FizzBuzz in a SIMPLE way? The whole point of FizzBuzz is to torture the language.

    fn main() {
      for i in 1..101 {
        if i % 15 == 0 {
            println!("FizzBuzz");
        } else if i % 3 == 0 {
            println!("Fizz");
        } else if i % 5 == 0 {
            println!("Buzz");
        } else {
            println!("{}", i);
        }
      }
    }

I don't know why people over complicate things. I was searching for other solutions and found this abomination:

https://bitbucket.org/iopq/fizzbuzz-in-rust/src/bf4968973d73...

I hope their production code isn't like this.

Wut? It's about as representative of Rust as writing FizzBuzz using Monads. In Java.

If you want production code look at Rust and Servo.

I wrote this as an exercise. This is specifically written to be point-free code without any if or match expressions.

    .unwrap_or_else(|| i.to_string().into())

this is the only one that was too ugly to make point-free

If the problem is FizzBuzz then it's you that's made it too complicated. Here is a simple version:

https://github.com/the-guitarman/rust_fizzbuzz/blob/master/s...

It doesn't do the same exact thing as mine does. For one thing, mine does FizzBuzzBazz (factors of 3, 5, 7) or even FizzBuzzBazzQuux if you want (actually arbitrary strings and arbitrary conditions)

> This is because of higher ranked lifetime bounds...

No, it's because the function you're returning is of type FnMut(&B) -> C, but your F function is of type FnMut(B) -> G. It expects an owned value of B, but you only have a borrowed reference to a B. Just make F of type FnMut(&B) -> G and you no longer have to dereference and no longer need the restriction that B: Copy. Higher-ranked lifetime values don't have anything to do with it.

Here's the new version:

  fn apply<A, B, C, F, G>(mut f: F, a: A) 
    -> impl FnMut(&B) -> C
             where F: FnMut(&B) -> G,
                   G: FnMut(A) -> C,
                   A: Clone {
    
        move |b| f(b)(a.clone())
    }

You think I didn't try that one before? It doesn't work in MY case:

    error[E0281]: type mismatch: the type `fn(_) -> _ {tool::second::<_>}` implements the trait `std::ops::FnMut<(_,)>`, but the trait `for<'r> std::ops::FnMut<(&'r _,)>` is required (expected concrete lifetime, found bound lifetime parameter

      --> src\lib.rs:50:17
       |
    50 |         .filter(apply(second, i))
       |                 ^^^^^
       |
        = note: required by `apply`

    error[E0271]: type mismatch resolving `for<'r> <fn(_) -> _ {tool::second::<_>} as std::ops::FnOnce<(&'r _,)>>::Output == _`
      --> src\lib.rs:50:17
       |
    50 |         .filter(apply(second, i))
       |                 ^^^^^ expected bound lifetime parameter , found concrete lifetime
       |
       = note: concrete lifetime that was found is lifetime '_#11r
       = note: required by `apply`

    error: aborting due to 2 previous errors

    error: Could not compile `fizzbuzz`.

I don't know Rust, but code looks readable. Function apply receives two arguments and returns function of one argument (address of b) which returns value of type C. I assume function apply() creates closure, so a.clone() is necessary to create fresh copy of a every time when closure is called. b is passed by reference, so code is generic. Not bad.

Equivalent [1] C++14 for comparison:

   template<class F, class A>
   auto apply(F f, A a) {
      return [f=std::move(f), a=std::move(a)](auto&& b) {
        return f(std::forward<dectlype(b)>(b))(a);
      }
   }

The forward<decltype> is an abomination and is really in need of a language based solution, but otherwise is fairly straightforward.

[1] No type checking of the definition of course, only of instantiations. On the plus side, the returned function is polymorphic and can be called for all Bs that f can be called.

Not sure what you're talking about:

https://is.gd/Xnu0YJ

it doesn't work in my program:

https://bitbucket.org/iopq/fizzbuzz-in-rust/src/bf4968973d73...

it gives an error when I use a generic `second` method from tool.rs

Why ask that B: Copy instead of B: Clone?

To deref it

b.clone(), of course, derefs b as well.

Is Rust harder to write than safe, readable C++ code?

EDIT: Reworded it to be more specific

I don't know that good C++ has been standardized or is enforceable by the compiler. But Rust is hard to write and that's doubly especially the case coming from an anything goes language.

Heavily disagree. Usually, compiler tells you how to fix your errors. You still need solid grasp of language.

The borrow checker can be hard to follow occasionally.

Your solid grasp of the language may be different or the same as my hard to write. But neither would be confused with utterly ambiguous C. The counterpart to borrowing in C would be it's antithesis in Rust, aliasing.

That said I'm on my learning curve and my opinion could change.

When was the last time you used Rust?

I ask this, because newer versions of Rust have suggestions how to fix your code, which may get you out of borrow checker fight.

I wonder why it was only Rust or Go he considered.

He could also use Java. It has a 'pauseless' GC in Fedora Core's OpenJDK (Shenandoah). It has an epoll abstraction in the core library. It has libraries for doing things like async DNS requests already.

It would be nice sometimes if these A vs B comparisons were a bit wider.

Java would be disqualified due to GC:

> It is worth noting that Go came nearest disqualifying itself entirely here. If it were not possible to lock out Go’s GC in critical regions Rust would win by default.

What technique is used to lock the GC out?

dunno- just copying what was in the original article :)

i'd guess a negative arg passed to https://golang.org/pkg/runtime/debug/#SetGCPercent

I hope not, because this way a critical section requires two non-concurrent GCs (SetGCPercent calls runtime.GC() [1] and runtime.GC() triggers a non-concurrent GC [2]).

If this is the option, I hope the critical sections in ntpsec are few and far apart...

[1] https://golang.org/src/runtime/debug/garbage.go?s=3706:3740#...

[2] https://golang.org/src/runtime/mgc.go?s=33685:33694#L844

I think the assumption is that, as ntpsec is "soft real time" i.e. not hard real time, sufficiently low pauses mean you wouldn't need to lock out the GC at all.

I mean, technically anything the system or runtime does on your behalf can be thought of as a 'pause'. What if you lose your timeslice half way through a function?

It's not pauseless.

> Shenandoah is an ultra-low pause time garbage collector that reduces GC pause times by performing more garbage collection work concurrently with the running Java program

Funny enough, the term "pauseless" was in fact invented precisely because of people like you, who abused the original terms ("concurrent" or "asynchronous" [0]) used for garbage collectors that never "stop the world", and used it for algorithms that merely run in parallel with the mutator threads, pausing them every so often. The next term used was "fully-concurrent" and now "pauseless". But if you keep abusing these terms to mean not fully pauseless/concurrent GCs, then it will become just as useless as all the terms before it.

[0] http://gallium.inria.fr/~xleroy/publi/concurrent-gc.pdf

Calling a GC that does much of its work while not-blocking-your-code seems like an appropriate use of the word "concurrent". Concurrent almost never implies "will never block", as far as I've seen people use it. If anything, that would be a "lock-free concurrent GC" or something.

> the term "pauseless" was in fact invented precisely because of people like you, who abused the original terms

This language seems unnecessarily personal and accusatory.

The question is what sort of pauses do you care about. I don't know about Shenandoah but the original Pauseless GC that Azul developed (and the current C4 on x86) have smaller GC pause times then thread switches.

So, if you are operating in a environment where you don't care about thread switching, you might also not care about GC anymore.

You are correct however, its not pauseless, that just a marketing term.

AFAIK Azul is pauseless - it never "stops the world". Sure, it stops each thread (that's pretty much required for any synchronization mechanism, especially if you also need to determine the thread's roots), but it never stops all threads at once ("the world").

That's not correct. Unless it changed recently, Zing still has safe points as it's basically a fork of HotSpot and HotSpot pauses programs for all kinds of reasons beyond GC.

There's a talk on YouTube where they discuss their work to drive down safe point pause times. They eventually made the pauses so fast it hardly matters, but it wasn't technically completely pauseless.

Yes, Azul's C4 paper states that they do use some "synchronisation" stop-the-world phases (although their previous GCs that had hardware/kernel read barriers might not have), but IIRC Doligez-Leroy GC doesn't (although I'm not sure it was ever properly implemented).

On the other hand, Shenandoah has an explicit synchronisation phase in its algorithm (not sure if that's a fundamental property of the algorithm or just a JVM limitation though). From [0] (that was 2 years ago, things might have improved since, but I can't find a more recent version).

> Pauses only long enough to scan root set

[0]: https://rkennke.files.wordpress.com/2014/02/shenandoahtake4....

I think Zing has always had safe points.

They had synchronization points on the hardware platform as well. The difference is that they had some amount of hardware support that made the thread check-in extremely fast.

It never stops the world for full heap collection, but there is a synchronization point where all threads have to check in. This is the only thing required, so you have GC pauses, just really, really small ones. That's why I said, that practically, GC pauses are no longer relevant.

GC must also reallocate used memory to avoid fragmentation of free memory. Do you know a true fully pauseless algorithm for that?

Downvoters - WTF? Memory fragmentation is the problem for long standing processes with frequent allocations/deallocations of various sizes.

http://stackoverflow.com/questions/3770457/what-is-memory-fr...

IIRC Azul's pauseless GC uses kernel-level memory barriers to catch accesses to recently moved objects.

Azul still have pauses (10-100ms).

> Azul Systems has built a custom system (CPU, chip, board, and OS) specifically to run garbage collected virtual machines. The custom CPU includes a read barrier instruction. The read barrier enables a highly concurrent, parallel and compacting GC algorithm. The Pauseless GC algorithm is simple, efficient (low mutator overhead), and has no Stop-The-World pauses.

Azul is very similar to Shenandoah we are talking about. Updating of a wrong pointer still needs time, which can be unlucky when write trap is triggered in the middle of moving of large object.

It's the "stop-the-world" pauses that are problematic and that we've been talking about. Single-thread pauses are a fact of life, completely unavoidable with any dynamic memory allocation system even without GC (e.g. when malloc searches the free-lists).

I put "pauseless" in quotes because I know it's not entirely pauseless. It's described as "ultra low pause time" by the original project.

However, whether we like it or not, Azul has established the term "pauseless" as the way to describe their own collector which before Shenandoah was the only GC that can realistically be described that way, and which Shenandoah is very similar to. This is despite the fact that Zing still pauses. Specifically, the GC moves objects whilst the program runs.

I am unaware of any GC algorithms that are truly, completely pauseless in every situation. So I don't know what you want the term to be reserved for.

Has he GP edited his comment? "Pauseless" in quotes seems to suggest recognition that the GC is not truely pauseless. I interpretted the comment as being in contrast to Go's GC, which also purports to be very low pause.

No, it had quotes from the start.

Does that run on all the BSDs and nicely on low-performance embedded ARM boards, which are explicitly targeted by NTPsec? Does it talk to low-level OS APIs for time management without complicated wrappers?

It's a replacement for one of the many background UNIX services, not a "primary" service that can own a machine.

You know SIM cards run Java, right?

They run something called Java Card, which is a very limited subset of Java (missing things like threads, enums or floating point numbers). And they are highly standardized, so you can be sure it is not just available and supported, but optimized for running these applets.

That doesn't really say anything about viability for an open-source project that's supposed to run on all kinds of embedded and general-purpose hardware.

Shenandoah has pause times ~10ms and is recommended for heaps 20GB+ for vs sub millisec in Go. NTPSec does not seem to have such high end memory requirements. Also now Java based app will need JVM availability on all platforms where NTPSec runs.

I think sometimes it makes sense not to shove Java where it is not applicable.

http://www.slideshare.net/RedHatDevelopers/shenandoah-gc-jav...

can go (or rust) compile for targets that don't have a jvm?

As far as Go goes, I believe neither the Plan 9 OS nor the MIPS CPU architecture have a production-ready JVM. Go supports both.

Yes, but that's because it's only really large heaps where pause times become problematic. On small heaps even dumb algorithms can give tiny pauses (a few msec or less) on modern hardware.

It's true you'd need a JVM on the platforms where ntpsec runs but that's also true of having a port of the Go runtime.

well actually he says that DNS lookups etc needs to be asynchronous, but aren't go's channels blocking?

I mean he also says that rust has no good epoll/select abstraction, which is wrong. And also "a welter of half-solutions in third-party crates but describe no consensus about which to adopt" I think he didn't researched well enough.

I mean it would be the same as saying that there is no good way to create a custom non blocking dns server with pure java/scala (no external library used). Rust has https://tokio.rs/ and everbody who even looked into network services with rust, stumbled across it.

Well maybe for his goals and contributor base go is prefered and that is ok, but well this article is more or less written as a rant against rust, that he/she/it does not agree with the generel design/documentation/whatever of rust.

In fact I also think that the tooling of rust sucks. rust is a language which shines with extremly good tooling. I mean rust has a godlike package manager and every tooling gets better and better.

Compared to go where the package management just sucks but the tooling even IDE completion is extremly great.

P.S.: I would not want to have a garbage collected ntp server. But for a lot of things I thing Go would be a good fit, even when it would not be my tool of choice.

Go has both async buffered channels and blocking sync channels. Just slightly different syntax to pick between the two.

Well, I think he has a point about the epoll/select - while I'm not sure about how good that is, the tokio library is relatively new - barely reached stable.

I do think that the majority of the resistance though is that the author could not get productive with Rust in 4 days. For that reason, even though the epoll and documentation issues might clear up, I don't think the author would ever select Rust, not matter how much time has passed.

Which as I write, I realize that I think that Rust would be better, lack of easy on-boarding aside.

tokio 0.1 was released concurrently with (or slightly after) the initial investigations behind this post, so missing it/passing over seems reasonable.

That said, as pointed out in the previous discussion about this, C also doesn't have epoll in the core language (it also isn't in the standard library there, either), and Rust can call the C epoll functions directly on the platforms that have it.

It takes a fair bit of effort to call into the epoll system in a sane and safe manner from Rust. It's more than just slapping a thin "unsafe-Rust" wrapper on the C epoll API. Or at least it is in anything but, say, a toy rust-equivalent of the man-page entry examples for epoll.

That's fair, but the complaint seems to be epoll not being possible at all, rather than it being annoying to call. (Obviously the latter is important, but the former shows a possible deeper misunderstanding of the language.)

It also takes a fair bit of effort to call into epoll from C in a safe manner, though.

Much less than from any FFI.

From https://tokio.rs/blog/tokio-0-1/:

"Announcing Tokio 0.1 ... The 0.1 release is a beta quality release. ... This release also represents a point of relative stability for the library, which has been undergoing frequent breaking changes up until now. While we do intend to eventually publish a 0.2 release with breaking changes ..."

I'm not trying to take a dump on the project (breaking changes are expected and welcome for new projects), but it is obvious a lot of the Rust ecosystem is in a very immature state. Probably much to immature to base an ntp server on.

Rust has had https://github.com/carllerche/mio for two years now, longer than Rust itself has been stable. tokio is just a higher-level, nicer, API.

ESR knows this. It was there in the comments of his previous issue. Yet he chooses to link to a two-year old issue with one comment that says that Rust doesn't have epoll as a source of truth.

Mio can't compare to the baked-in goroutine goodies (neither can epoll in C!), but this blog post is outright dishonest.

mio is currently at version 0.6.2. A version number with a leading zero usually indicates that the authors of the software deem it to be of alpha or beta quality. It's api has also significantly evolved in a backwards incompatible manner recently: https://www.reddit.com/r/rust/comments/50srx0/mio_api_has_ch...

Again, not taking a dump on mio because its authors are doing the right thing. 0.x means bugs and api breaks are to be expected. Use the software at your own risk. Basing an ntp server on it might not be appropriate (atm).

Right, mio isn't marked stable yet, and is changing the API (mostly for tokio), but the project is mature in the sense that you wouldn't expect many bugs in it, and you can pin to a version and just use that for a while if you are worried about API stability.

But yes, the async I/O space in Rust isn't amazing. But it's not as bad a picture as he paints.

Yes, you could, but then you run into the potential problem where dependency A uses version 0.6.x, but dependency B starts using 0.7.x, because there's no stability. It becomes an increasing maintenance nightmare, where every dependency adds new potential headaches because no one's willing to create a version that's supported for more than a few months. Async I/O is as bad as he paints it because every component that you can use isn't stable and has no plans toward stability.

Yeah, I'm aware that's a problem, but it's not a dealbreaking one usually IMO. Especially for libraries like mio and tokio with buy-in from the whole I/O side of the ecosystem.

Why wouldn't I expect many bugs in it? The 0.x version number implies exactly that! In this matter, I'd rather trust the mio developers themselves than you. By holding the version number at 0.x they are saying "stay away unless you like to tinker". I.e "Don't base your ntpd software on this library"

Pinning a version number is a hack. Not something you should rely on for long-term stability.

So the Rust community in general is pretty reluctant to move crates to 1.0, even when stable/bugfree. This is a problem, and is slowly improving, but that's currently the case.

0.x can mean "Not stable" and it can also mean "buggy", it need not mean both. Regardless of how bug-free the authors consider it to be, they won't mark it 1.0 until they think that they're happy with the API. IIRC they're waiting for tokio to be finished and for it to sit for a while to ensure the API is the right one, so it should be relatively free from bugs.

> Pinning a version number is a hack. Not something you should rely on for long-term stability.

Agreed. I'm saying that this shouldn't be a dealbreaker. It's usually very little work to upgrade to the latest version of a library.

Basically, mio's stability is a problem. Totally agree with that. But it's not as bad a picture as the article paints.

> So the Rust community in general is pretty reluctant to move crates to 1.0, even when stable/bugfree. This is a problem, and is slowly improving, but that's currently the case.

Keeping a package at 0.x means (to paraphrase) "I don't take responsibility. The code may or may not work and if it doesn't, then don't complain." (a) Putting it at 1.x means (to paraphrase) "I (the author) will at least respond to bug reports. I might even try to fix them if I have the time." (b)

Free software authors have this choice.

> so it should be relatively free from bugs.

And if it isn't? For example, I looked at the tracker and found a number of open bugs which looked troublesome for the Windows backend. I think you are doing the mio project a disservice by promising more than the developers themselves have said that they are willing to deliver.

Yes, and while that's what 0.x usually means, in the Rust community (and in other communities) it's usually more complicated than that. For mio in particular it's been a crate that a lot of folks have been using and it's been working fine. I'm not saying that that's the message that the version number broadcasts. You're totally right that it broadcasts a message that the crate is immature. I'm saying that the actual situation is not as bad as it sounds.

Fair point about the bugs :) I wasn't aware of them, and I've only heard really good things about mio.

Being 0.x could also just mean "we're not 100% certain we don't want to change any API" yet. Semver is about stability guarantees (promises), bugs is somewhat independent for a widely used and well-maintained library.

I can't find support for that interpretation in the Semantic Versioning spec: "Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable."

That means 0.x software is in "initial development" implying no guarantee on how many bugs it can contain and no guarantees regarding maintainership. Other parts of the spec deals with backwards-incompatible api changes.

I know where your interpretation comes from. It comes from users of software who believe that a 0.x version can be relied upon. Because it works for them and they haven't found any bugs. Software publishers on the other hand, never makes that claim and users to whom stability is important should stay away from 0.x software.

Agreed that the publishers don't make that claim. However, I know that many publishers are hesitant to go 1.0. Not because they think there are too many bugs, but because they are afraid of committing to not changing the API.

Note that there is nothing at all in the semver spec about bugs.

> has no good epoll/select abstraction, which is wrong

I can't reiterate this enough. Rust has one of the best abstractions I've ever used over epoll/kqueue and MS' variant, MIO. MIO has picked not the crappy POSIX select, which every major OS has a better alternative to now, but instead the OS' preferred event system. The 10 year stability requirement is awkward, as I don't think anyone can predict the future, and in 10 years, who knows what will change.

As you mention, tokio is an awesome futures based abstraction on top of that, making it a breeze to write complex, fast, event driven logic.

I'm sad that after four days he didn't like Rust, I had a 100% different experience. After one day I fell in love with nearly every aspect of the language, and it was specifically because of state machines (which they mention as one of their core desires). My biggest complaint against the language hasn't changed, which is dealing with different Error types, but even that after a lot more experience with Rust has become easier.

Anyway, for NTPSec it's sad that this didn't suit their desires, but that doesn't mean that we can't write our own.

Go's epoll abstraction is baked into the runtime. They are called goroutines. Goroutines blocked of FD's automatically use epoll and schedule based on its results: https://github.com/golang/go/blob/master/src/runtime/netpoll...

I wasn't commenting on go, just pointing out the library that most people in Rust are using for async-io.

> My biggest complaint against the language hasn't changed, which is dealing with different Error types

Do you mean syntactic sugar? Because there's try! and ?

Or do you mean dealing with Option and Result in a more uniform way?

So error_chain! is actually the answer to most of my issues with it, but it was the largest hurdle for me (coming mainly from Java) where you need to convert from one type to the next up the return stack. It took me a while to get used to this, but I'd say it's a large hurdle when learning the language. And, while error-chain is great, it means introducing you to macros and such if you try to adopt it early on.

Mind you, this is my biggest complaint, and it's trivial for me now, but after you grok the other major features of the language, properly dealing with errors/results is a hurdle for people new to the language.

link: https://docs.rs/error-chain/0.7.2/error_chain/

Best abstraction over epoll/kqueue ? As compared to what ? From all the things that rust does right, MIO event loop seems lacking as compared to boost::asio for example.

It strikes a good balance of portability and features, and where MIO leaves off, tokio picks up.

When comparing to other libraries in other languages, MIO probably looks like it's devoid of features, but that's because it's trying to be an abstraction layer only, and tokio is probably where most people should turn for higher level semantics...

It might be that MIO is a good epoll abstraction, but in Go you don't have to care wether your code blocks on IO or if it's computationally intensive and requires a separate, costlier thread. You just spawn a goroutine. Go's runtime does the rest.

And that for me that is the way I want to do concurrency and parallelism for pretty much everything I'll ever write.

> And that for me that is the way I want to do concurrency and parallelism for pretty much everything I'll ever write.

1. You can get exactly this with concurrency by spawning one thread per request. The only difference between Go and the pthread model is that Go has a userland scheduler.

2. If I tried to do my parallelism work using this model, the amount of multicore speedup I would get would be zero (actually, it would be negative). Sometimes you're compiling multiple .o files--you get lucky and the overhead of spawning a thread per work item is not restrictive. Sometimes you're shading individual pixels--spawn a goroutine per pixel and you're going to be laughably slow.

  The only difference between Go and the pthread model is that Go has a userland scheduler.

That's a _huge_ difference in the context of a network service, and also obscures some other details.

If I have several thousand long-polling clients, one kernel thread per client is simply not realistic. It uses up alot of memory, and the context switching can be costly. Throwing more hardware at the problem is just throwing money down the drain. And if throwing money down the drain is fine, one might as well use one process per connection with blocking I/O.

In order to avoid that in Rust, Node, or most other languages one needs to use a callback or future. But both a callback and future require a dynamic allocation and deallocation per invocation of each function that might block. Especially under heavy load (lots of broadcasts), that's alot when you consider chaining invocations, as you must when composing non-blocking I/O interfaces. Chaining futures hinders compiler optimizations. And in general it hinders function composition. (I commonly see claims that the react pattern is better for composition, yet I never see such people writing _all_ their code that way, e.g. for things like string manipulation. In reality most concurrency, even in network services, is effectively sequential within a wider context beyond the immediate operation. Have you ever tried to implement, e.g., a non-blocking MySQL protocol parser with callbacks/futures? It's ugly.)

People underestimate how efficient and useful storing function invocation state on a stack is. Goroutines (or contiguous, dynamically-sizeable stacks like in Lua) give you the best of all worlds--efficiency of a contiguous stack without the high fixed costs. That means performance _and_ scalability for massively concurrent network services, but also for other patterns--like being able to convert a callback-based push interface into a pull interface, without having to refactor the intermediate code, which can be amazingly powerful for things like parsers.

But for a language like Rust it's understandably difficult to implement stackful coroutines, let alone goroutines. I just wish people wouldn't whitewash the issue.

This is a big advantage to Go, you're totally correct, but it does come at a cost with the GC and a runtime. For some this is acceptable, for others it is not. But this is not the reason that I personally decided to bet on Rust and not Go, though they were part of it.

The three main reasons that Go doesn't fit with the work I want to do on the network is all around compile time guarantees:

1) Strong type checking on Null 2) Required handling of Errors 3) Generics

These all help me write stable software that I have higher confidence in than what I've written in Go.

In terms of the debate on Futures, etc. you are right that it's simpler to write pure stack based functions, but the overhead of tokio and futures in Rust is not as high as that of a goroutine, but it does take more thought. It's a trade off on productivity vs. stability. In your opinion it's ugly and hurts productivity, but to me it is pure elegance with zero overhead cost at runtime (and if you preallocate an arena/slab it can even have known memory costs). After working with tokio over the last half year or so, I find that I'm as productive as I am when writing single threaded blocking IO code (granted there was an initial ramp up time before I became as comfortable as I am now).

> If I have several thousand long-polling clients, one kernel thread per client is simply not realistic. It uses up alot of memory, and the context switching can be costly.

The memory cost of pthreads that people generally refer to is the stack. Userland scheduling doesn't have anything to do with the stack size. You can get the stack size down very low in a 1:1 thread model: 10kB (or, in future Linux kernels, 6kB). That's comparable to the stack size of a goroutine.

Context switching cost depends on your use case. For I/O, keep in mind that you have a round trip through the kernel either way.

> being able to convert a callback-based push interface into a pull interface, without having to refactor the intermediate code, which can be amazingly powerful for things like parsers.

You can efficiently do that with threads too. In fact, that is exactly how HTML parsing works in every modern browser: the parser runs off a separate thread and forwards DOM create events to the main thread. HTML parsing is about the most performance-critical parsing setting you can think of.

> Rust has https://tokio.rs/ and everbody who even looked into network services with rust, stumbled across it.

didn't it launch a week ago?

They are two entirely different use cases. Rust is for replacing C/C++ with a safer alternative. Go is basically for developers that never fell in love with Java or C# but need the same kind of language.

Do those usage distinctions really hold? We all know the mythology that Go was created as a replacement for C++ (the Go FAQ still lists it as being created because of the poor system language tools). Rust targets largely the same problem space. They're both compiled languages that in an idealized world could offer C levels of speed.

Go also offers a lot of high level constructs that allow you to create a web server and other solutions traditionally built in higher level platforms, but that doesn't reduce its low level functionality.

The languages can be used for the same things in some cases, but Rust not having a GC enables it to be much more of a C/C++ replacement than Go can.

Go has a non-compacting GC (hugely important for integration with other native code, where I should also mention it has C-style struct layouts), and in recent iterations has pauses in the microseconds range. And that's if you're actually creating garbage, as the escape analysis (which happens at compile time, given that Go is not a VM-targeting platform) makes it extremely easy to avoid garbage at all.

Rust has escape analysis and reference counting. It really isn't so different.

Rust doesn't have escape analysis like Go (or Java, etc.), it is all done at compile time and any failures are flagged, meaning one has a stronger idea of the actual runtime behaviour of the code. Additionally, reference counting is used far less than GC pointers in languages like Go, even accounting for their escape analysis.

In terms of integration with native code, the concurrency model of Go means calling native functions has high overhead because it has to switch to a native stack (thi iss one possible motivation for why Go does syscalls directly on Linux: avoid the stack switching overhead).

Rust doesn't have escape analysis like Go (or Java, etc.), it is all done at compile time

Go makes the stack/heap decision at compile time as well. It is far closer to C++ than Java. To your other point, cgo calls indeed have a high overhead in an absolute sense, and ideally you do fatter, more meaningful calls.

I am not advocating for Go, it just seems that these discussions often pigeonhole technologies, and a common one is the strange belief that Go is just another Java/C#, and Rust is the next low level language.

I was unclear: the key bit from that first sentence is "any failures are flagged". Go does give more static control over stack vs. heap than Java, but it's still perfectly happy to implicitly promote things to the heap to make code work. This means that Go offers less control over memory (one of the things needed in a low-level language) than Rust. When, for instance, variables are being passed between threads/goroutine-equivalents, Rust will notice that things are trying to escape and tell the programmer that they need to decide how they want to handle it, rather than make the decision implicitly. (The Go approach isn't like C++ either, which also doesn't implicitly allocate, like Rust.)

There are many other aspects in which Go does not offer as much control as Rust, e.g. the former incorporates a runtime and garbage collector. This isn't disagreeing that Go offers more control than Java, but Rust (and C++) offers even more than Go.

> Go makes the stack/heap decision at compile time as well.

No, it doesn't! This is even in the FAQ: https://golang.org/doc/faq#stack_or_heap

How do you think that refutes what I said? Go absolutely makes that decision at compile time (of course it does -- Go does not have a VM). Is your point that they say that you shouldn't sweat it? Because of course you shouldn't, and ideally it is making the right choice, which most of the time is the stack.

Rust can call and be called by C code without a translation layer. To me, this is a requirement for any language that is truly going to replace them. Also, Go went down the GC path which limits its applications to those where you can have unpredictable pauses and for me firmly places it in the Java/C# part of the spectrum.

I'm not attempting to advocate Go here (they're both fantastic options), but any application running on a non real-time OS can have unpredictable pauses. That's the world of preemptive multitasking. Of course this is a scale thing (Go doesn't escape those OS pauses), but Go 1.8's own pauses are in the sub-millisecond range.

C# and Java have pauses in the hundreds of millisecond range (though there are "real-time" JVMs that greatly improve this). And it's notable that Go goes to lengths to avoid generating garbage.

I am learning rust. To me, the amazing thing is the lack of runtime.

If you are writing a library to render the latest web image format, or implement the latest secure network protocol, then your choices are limited and Go is not an option.

Sure, you could write it in Go and then Go programmers could use it.

But if you write it in C or rust, it could be the de facto library for nearly all languages.

The article is a good one, but doesn't really influence my personal opinion much.

> things that should be dirt-simple in Rust, like string concatenation, are unreasonably difficult

This is how hard adding String objects is in Rust:

  a + b

A more full example shows only small complexity, really, and I include it only for completeness and fairness:

  fn main() {
      let a = String::from("Hello,");
      let b = " world.";

      let c = a + b;  // this is the only part that concats, really.

      println!("{}", c);
  }

The String::from call converts from a str& — which is effectively a pointer and length to UTF-8 data, to a managed string, more akin to std::string in C++; str& doesn't implement +, I presume b/c it doesn't know what the resulting type should be (and doesn't presume).

A C programmer should easily comprehend why you can't simply add two char * s together; compare:

  char *new_string = malloc(strlen(a) + strlen(b) + 1);
  if(!new_string) { abort(); }
  stpcpy(stpcpy(new_string, a), b);
  return new_string;

(that's just the `a + b` line from Rust, in C, essentially)

(hopefully I got that right. stpcpy avoids an extra iteration through a that strcat cannot; I do know about strcat.)

Essentially, in all of Python/Go/Rust, if you has the right type, string concatenation is `a + b`.

> Contemplate this bug report: Is there some API like "select/poll/epoll_wait"? and get a load of this answer:

> > We do not currently have an epoll/select abstraction. The current answer is "spawn a task per socket".

It would need to be cross-platform; so I can understand why Rust isn't there yet in the standard library. There are third-party libraries out there that do this. (And C has nothing here, either…)

You can always call epoll directly, and write the required abstraction yourself. (There are even third-party wrappers for calling epoll, so you don't even have you write that yourself either; see the excellent "nix" library.) If you want a 10 year solution…

> Relatedly, the friction cost of important features like the borrow checker is pretty high.

At first, this is true. Then I felt like I started realizing that what all the "friction" of the borrow checker was it pointing out serious bugs in my code.

Regardless, NTP would be better off in either Rust or Go instead of C, IMO.

    fn main() {
      let a = "Hello,";
      let b = " world.";

      let c = a + b; 

      println!("{}", c);
    }

And the result is:

  rustc 1.15.0-beta.3 (a035041ba 2017-01-07)

What?

PS. looks like hacker news can't handle rustc error format, a pity...

As the post you are responding to pointed out, String::from converts from a string slice to a String. You didn't do this.

Your code fails to compile because it attempts to apply + to two string slices, and that is not implemented. @deathanatos also mentioned that.

You might find the Rust book page on Strings helpful: https://doc.rust-lang.org/book/strings.html

I'm curious if some of this is the fact that a lot of senior folks are learning new languages for the first time in a long time. I think we unnecessarily constrain language design if they have to look like everything that came before.

I remember learning Java was a piece of cake. Go was too. Both were remarkably similar to previous languages I knew. Rust was/is a lot more difficult, but nowhere close to the mindfuck that is Haskell or ML.

I mean, is it that bad that it takes a month to really learn a new language if it can provide worthwhile benefits?

This.

Its true, coding in Rust makes you feel like a total moron at first. The experience actually reminded me of the time when I first picked up programming.

It only takes around a week or so though, after that you can be surprisingly productive. I never would allow myself to write the code in C that I wrote in Rust. I'm just not clever enough.

> The amount of complexity and ritual required by Rust’s ownership system is high and there is no other language I know of that is really good preparation for it.

C++ helps, if you are familiar with RAII usage in it.

The main problem i have with rust is that there is no real book for beginners. Sure thing there is the RustBook and RustByExample. But i need something to guide me. I dont want to slap things together. I want to learn how to do it right. All Rust recourses i found only told me how to do XXX in Rust. Nothing along the lines of: This is could be a real world example for YYY. In examples, you will always only find excessive .unwrap() use and functions which dont borrow anything.

Had the same feeling with go. Looking into big projects like syncthing helped a bit. But first i have to get a better hang of the language. Books like "Atomic in Scala" or "Clojure for the Brave" are taking your hand and guiding you through the Language. Even when taking a peak into books like "21st century C" i learned more, then when i simply force myself through go's "Gopl" or Rust's Book. I know i am probably not the right target group. But i really want to learn one of those languages in my free time, and i had a really hard time to do so.

After understanding go better, i still want to switch to rust. The build system with cargo pleases me and looks somehow cleaner as in go. I just create a project with 'cargo new XXX --bin' and start coding and building some kind of lib in my project. No problem. I go there are 100 different ways to start a project, and most time you will only find people complaining about vendoring etc.

Its a work in progress, but available bits were helpful.

http://aturon.github.io/

Thanks a lot! Dindn found this one till now!

This isn't anything different from the other two articles he wrote. What's the point of writing a third one saying the same things?

The title should have been "Rust vs. Go, by a Go developer who doesn't know Rust". Would have saved me 5 minutes.

Stronger typesystems are better for production system. They give more guarantees and mean you need to write less unit tests. Rust's sum/algebraic types are a move in the right direction and so is pushing resource usage invariants into the typesystem.

I hope that the measure of whether something is good enough for the embedded space is not android.

I have quite a few openwrt routers running with substantially less resources available to it than the worst android phones.

I don't know if go would be able to meet the cpu/memory constraints in that environment... from the blog post it seems like that wasn't even measured?

One of the interesting things about Rust is that it can compile C libraries, so you can move a code base from C to Rust one module at a time.

I think Go and Rust are interesting languages because both tackle the "C successor" problem and both feel like good solutions, yet so different from each other that it almost feels like they aren't meant to be used for the same problems. How could that happen?

I think it's largely because C and C++ has been used in such a wide variety of applications as "good enough" languages but where there were so much room for improvement, for modernization. We're talking about an old assembly language layer and an object orientation cludge on top of that layer. As soon as you do improve on these, you observe that the application space to cover for successors is huge, so huge that there is plenty of room for two different languages.

Developing in Go doesn't feel like Java or C# to me. It feels more like C (and definitely not C++) and I love that. It's so simple, yet producing native code. It's like what you'd get if you took C and from the very start decided the productivity vs performance problem favored a garbage collector, prefering productivity. Then looked at how common and underutilized multicore CPU's are, while at the same time how synchronization is hard to get right. If you then move from these problems to solve and realize the GC is your Achille's heel and simply try to optimize the heck out of that, I guess you get something like Go.

Meanwhile, Rust during the design phase must have been in such a similar place as Google engineers were when designing Go? Once again, C / C++ were flawed and unsafe, cumbersome to work with. They took the very same productivity vs performance problem and this time saw that, no, we don't want garbage collectors, we prefer performance supporting time critical systems above all in the spirit of C, yet safety. Then looked at common crash issues and went by that, and then they got Rust.

Personally I prefer Go. It's the most fun for me to work with and feels like a very pragmatic language. Rust feels more like an academic language to me: ideas and exciting concepts allowed to materialize. It also has its place, but seems like more in niched scenarios like real time systems and device drivers, low level, critical stuff like that.

Semi-related, side-by-side comparison of how common things are done in rust and go:

http://rosetta.alhur.es/compare/Rust/Go/#

The problem with Rust is that Rust cannot be understood by someone who never had to do manual memory management. So people coming from Java, Ruby, Python, Javascript, PHP who have never used C or C++ will never understand why Rust handles variables the way it does. Rust cannot be popular among these people because Rust doesn't solve their immediate problems in terms of performances.

the Rust team often pretends they are open to suggestions as to how to make Rust easy or easier to learn, that's impossible given how memory management is done in Rust, especially in regard of the people i talked about in the former paragraph.

Only a developer familiar with C or C++ can appreciate Rust semantics. The others cannot.

I feel that that's not really true. I'm from a dynamic language background and I didn't have many problems. Quite the opposite actually, as to me the Rust compiler was more of a teacher at first. I've tried getting into C and C++ a couple of times in the past, but since I started using Rust I finally started understanding some of the concepts and issues from those languages that I had a hard time grasping earlier.

> I've tried getting into C and C++ a couple of times in the past

You just proved my point. You did get into C and C++ before trying Rust.

No, I _tried_ and failed. I've never made it anywhere close to writing my own C or C++ code, and failed at the tutorial stage or earlier.

But you wrote a malloc, free, new or delete before. it's not like you were oblivious to these concepts, that's exactly my point.

Yes, but I didn't understand the implications or background. If the prerequisite for having enough basic knowledge is "making it halfway through a C tutorial" it doesn't seem as much of a hindrance as your top comment suggested.

Funny article. This is something like emacs vs vim by someone that knows only one editor

I'm curious about whether and how Rust "dealbreaking" situation compares to C/C++. Seeing as how Rust is designed to be a replacement for those two (so is Go, but it seems to be at a much higher level), I reckon that'd be the more fair comparison.

In particular, it's my understanding that epoll and select are system calls. In that case, just call them. Or is there really no means to do so from Rust (doubtful)? Sure, you'd have to wrap stuff in "unsafe" calls, but that's par for the course when interfacing with non-Rust software.

So the author doesn't care about memory usage or throughput, except for a few "soft realtime" sections? Why would either Rust or Go be better for this task than something like Java or Python?

Java is not really a great choice because you need a JVM for the task at hand. Python is not a good choice because of concurrency constructs, and it's clear that the goal of this was to self-contain the whole thing and not have fringe packages in a semi-direct port from C to a different language. For a raw systems daemon that needs to run on mostly everything being coupled to only one runtime is a huge boon for portability.

That disqualifies Go even more so. You could easily embed a competent JVM in the space a typical Go binary requires to embed all its libraries (the "docker" binary I'm looking at is 13 MB). Go's "Hello, world" is well over a megabyte.

The critical feature here is that the resulting Go binary is whole and complete and tightly coupled to the system at hand, which fits more the output from Rust or C. Inherently Java software is dependent on two runtimes, the JVM and the core libraries the JVM is compiled against. Space isn't the most critical concern here, it is portability and bringing a JVM everywhere is really painful and really a project well outside the goals of the software described. If a JVM was going to be considered a solution this project would have to package the JVM and the daemon which would be silly.

My favorite feature of Go is the immediate productivity that almost any developer can achieve within days af seeing the language for the first time. That adds tremendous business value to any project.

In the last post didn't he say that he spend 15 years writing in 'C' and learning the ins and out?

I don't think 4 days is enough to really evaluate a language. I'm not going to dismiss Rust based on this analysis.

Rust fans are trying to avoid "vs" articles, would be great to see such endeavor from Go fans too.

Why wouldn't you want that? I genuinely don't understand why you think it's bad. It seems pretty worthwhile to try and understand the design choices and tradeoffs of different platforms.

I am a go fan, and when I saw this article on the fp, I said to myself "here we go again"

It's the 4th law of HN: Wherever Rust is, Go goes, and vice versa.

I am considering just accepting this reality that people will always pit these two against each other, and maybe just accept it for it's positive merits: that the extra competitiveness will help create a better ecosystem for the two of them.

Constructive comparisons with deep knowledge of both languages are priceless, when articles "I tried Go/Rust 1 week and didn't get it" are useless. Title "vs" often is a marker of articles of the second type - just to share emotions, not knowledge.

"Constructive comparisons with deep knowledge of both languages are priceless, when "I tried Go/Rust 1 week and didn't get it" are useless."

Well, unless you want people to actually use your shiny new language. If that's the case, perhaps criticisms of this type should not be dismissed out of hand. :-)

Most programmers are going to abandon something if they study it for a week without significant results. Maybe they'll keep plugging at it if their boss orders them, but they won't do it on their own. Oh, sure, there's a small subset of programmers who enjoy tinkering with weird languages for fun, but that subset is dwarfed by the number of programmers who view languages as a tool for getting things done.

If there's anything that we should learn from the history of programming languages, it's that usability trumps theory every time. The languages that people actually use are almost never the ones that theoreticians admire.

Note that most code today is written in C, JavaScript, PHP, Java (none of which would win any prizes for theoretical elegance)... rather than ALGOL, ML, Haskell, the various Wirth languages...

There's really no comparison. Lisp probably comes closest, in that it is both theoretically elegant and has been used, by the programmer's choice, to build large real-world systems, but even Lisp is basically a rounding error.

> Note that most code today is written in C, JavaScript, PHP, Java (none of which would win any prizes for theoretical elegance)... rather than ALGOL, ML, Haskell, the various Wirth languages...

ALGOL wasn't actually that bad.

That was long before my time, but from what I've read ALGOL's problems were that it was too complex to be easily implemented on the (very limited) hardware of the time, and a focus on theory to the extent that basic functionality was ignored (even I/O!). That made it great for writing down algorithms on paper, but troublesome if you actually wanted to use it.

Algol 68 was too complex, but Algol 60 was quite good and successful.

The Wirth languages saw fairly widespread use once.

Modula-2 had some uptake, but never to the extent of C or Fortran.

Pascal was popular for teaching at one time, but pure Pascal was never very popular for writing shipping code. If I'm not mistaken, Borland's Turbo Pascal, which was pretty popular, became so by adding non-standard features that probably gave Professor Wirth a heart attack when he heard about them.

Delphi is Pascal and was used for tons of things.

- Dreamweaver

- Skype

- TOAD for Oracle

- TeamSpeak

Etc.

C and C++ are also popular by adding non-standard features. Such as, oh, your entire Win32 API, POSIX, and so on: every system's low-level API's, middleware and other stuff.

Libraries and the base language syntax (and semantics) are two different things.

I'm not trying to say that programmer can't take own decision after a week (or day, or hour) of learning new language. I'm trying to say that "teaching" others with such small experience as 1 week of knowledge is useless. It's not about this article, but in general.

I sort of agree, but this approach has a real problem: you're strongly selecting for people who are at least okay with the language. If you expect all criticism of Go to come from people who have years of Go experience, all you'll ever get are people who broadly approve of the Go design philosophy, along with the occasional soul that got trapped in a Go job by accident.

The sort of people who find major problems in Go simply won't put time and energy into the language beyond a point—why should they? There's a limit to how far I'm going to explore a tool that seems obviously inferior, even if the tool is popular. (And popularity is an absolutely terrible measure of quality!)

If you applied this standard to PHP, you'd get an implausibly rosy view of the language, because the people who aren't invested in it simply don't use it.

Actually I saw already article about switching from Go to Rust after few years of Go and long testing of Rust, so it's not a miracle :)

The fact that it's by ESR softens the blow. If he comes down on the side if your preferred language, you can be like "ESR's not as bad as i thought!", and if he come down on the other side, you can be like "oh well, it's only ESR!".

As one disgusted by Go's anti-intellectualism, Amen to this.

Anti-intellectualism + racist quackery! ESR really couldn't get worse.

(Not implying Go devs are racist, I hope that's just ESR.)

who is "esr" and why do you accuse them of such things?

edit: oh, the The Cathedral and the Bazaar dude. i saw a video about him that seemed to portray him well. but having found his blog... well... i can understand your sentiment.

I'm not sure I'd call ESR a fan of either. The title clearly states it's a comparison for the needs of one particular project. Reading further makes it clear he nearly called Go disqualified from consideration. I think it's fair enough to make a comparison of any two languages in the context of a particular project. Horses for courses and all that, you know? Comparing them in a vacuum and trying to pick an overall winner is what should be avoided.

> The title clearly states it's a comparison for the needs of one particular project

Hm.. Title is "Rust vs. Go" - looks like title of another one holywar flame article.

Actually, you're right. For some reason I was remembering the first line of the synopsis paragraph as a subtitle. It doesn't take very long reading the top of the linked page to see the intent, though. ESR's very political on some issues, but about languages I've found him pretty pragmatic (maintaining C-Intercal as a side hobby notwithstanding).

It feels like this guy will end up converting the codebase to both languages.

Which would ultimately be fun to follow

Hey wow this new technology will solve all our problems with that old technology!

I don't understand why esr thinks his opinion after 4 (four!!) days of Rust is interesting. Am I the only one here who spends a lot longer with a language than that before passing judgement on it?

At the minimum, it is something to point at when he gets asked why his project doesn't use Rust, which probably comes up quite a lot.

I wrote less than 2 KLOC of Go in my life (at Google, because I needed a web server for an internal dashboard, and Java was too much pain), and one thing is for sure: while I did not like the language per se, I did not hate it either, and I was able to get used to it in about 3 days, which is how long it took me to write the code. I literally knew nothing about it at the outset, and I felt comfortable in it after writing less than 2KLOC. I can't think of another high performance language with such a short learning curve.

I've tried Rust and concluded that it solves problems I don't have. I work mostly in C++ (more like C+, I tend to keep my code pretty simple), and with unique_ptr<>s, shared_ptr<>s and judicious use of concurrency primitives I can avoid pitfalls well enough that I maybe encounter a self inflicted concurrency or memory management issue once every six months, if that. And it pays amazingly well, and there's an enormous number of libraries available. That said, when I need a high performance web server, I'll use Go without hesitation. When performance doesn't matter, Python and Flask are pretty indispensable.

As an (ex-)C++ developer, this is mainly my feeling too. Rust solves many problems in a very elegant way, but those problems are things that most experienced/skilled C++ developers solved by sticking to a fixed set of best practices, mostly avoiding these problems.

Most C++ developers I talk to about Rust express the same sentiment, they usually like the idea, but aren't personally interested in learning it because it solves problems they're rarely confronted with.

I tried picking up Rust a few times since it does interest me, and I like trying and learning new things, but I currently don't have the time to really dive into it. Go on the other hand took no time at all to get into, and was promoted pretty quickly into one of the more frequently used tools in my toolbox, just like Python.

As C++ developers, though, we are a biased bunch. C++ takes years to properly learn and gain confidence with, something we're completely oblivious to since that learning curve is in the past. I concede that for people who don't already know C++, Rust may be a good choice.

I cannot agree more with his conclusions about Rust, you can overlook a lot of problems. But the language itself is just such an arcane pain to deal with, the author really brought this out: Even just writing and printing few lines of strings out has possibly hours of gotchas in it. Add a little IO and you're looking at days. It's not a question of a lack of documentation, I just think the language is weird. I truly wanted Rust to be great and I keep looking at it wanting it to be better but it just isn't. Isn't it funny how in the real world, suddenly the so lauded 'type safety' really just doesn't matter that much in practice. A simpler language overall would have made a much bigger impact than any generics.

??? Literally the first example in the Rust Book teaches you how to do this; you can do IO within the hour, easily.

>Isn't it funny how in the real world, suddenly the so lauded 'type safety' really just doesn't matter that much in practice.

I've been writing Javascript for years and if there's one thing I've learned it's that type safety matters on the large scale. Don't get me wrong: I actually love Javascript. It's my go-to tool when I want to just get things done. But when you start scaling things out and get a lot of moving parts going, type safety really helps lift the mental burden of tracking everything yourself. That's why TypeScript is so popular.

I've been a huge fan of dynamically/weakly typed languages for a while but I've fallen in love with Rust. Yes, it can be a bit painful at the start but it doesn't take hours to get basic IO working and it's quite beautiful once you get into it. The mind-bending part is the ownership model because nothing else has ever had something like that. But, you know, that's just my opinion.

I think it gets many things right - it makes the hard things possible (such as safe concurrency).

What it fails at is making the simple things simple. Making a program that concatenates some strings shouldn't be hard, and the result should be clean and readable. That obviously hasn't been a design goal yet, but I hope the focus will turn to making tresholds lower and syntax less painful soon.

  #include <stdio.h>
  int main(void) {
    printf("hello world\n");
    return 0;
  }

Rust:

  fn main() {
    println!("hello world");
  }

I can google-SO program in PHP or Python, I did it recently with very little knowledge of those languages (I know other languages and have some common sense, so I know what to look for). Other languages like Haskell, C++ or Rust do not fall in that category, you have to really understand, what you're doing, before you could do something useful. That's fine, IMO. Not every language should be easy, if that complexity brings some advantage. And for Rust that complexity does bring the advantage: 0-cost memory safety. It's an unique advantage, so it's worth a little time investment.

it's unfortunate that rust seems barely more than a compiler. it's... empty. the "ecosystem" feels like a namespace-free dogpile of college spring break experiments. a wasteland of pre-pre-pre-pre-alpha 0.0.0.0.0.1 stuff. it'll be 10 years before it improves to even being underwhelming.

in go, you can download it and have the pieces to actually do useful stuff right away. legit productivity. not to mention putting together graphs or graph-like structures and other similar things aren't the obtuse sphinx riddles they are in rust.

There are real world jobs requiring Go (and it's growing slowly). There are no jobs requiring Rust.

End of the comparison. That's all one needs to know if he's interesting in a career in distributed systems.

That's a terribly unfair comparison. Go 1.0 came out just about 5 years ago and Rust 1.0 only came out a year and a half ago. Not to mention, there are people employed to write Rust. Most notably, the Servo team.

Also MaidSafe is an all-Rust team.

If anybody is looking for a Rust job, they in fact do exist, and are growing. This Week in Rust lists 5 this week [1], and 5 is more than zero!

[1]: https://this-week-in-rust.org/blog/2017/01/17/this-week-in-r...

Rust 1.0 is just over a year old, give it time.

Reply on news.ycombinator.com