> Overall though, Go is probably still the more practical choice between the two languages (due to Rust's incredibly high barrier to entry).
Does Rust really have an "incredibly high barrier to entry?"
I've been using Rust for a few months, and just deployed my first high-throughput application a month ago, and my experience has been the opposite. Yes, the first couple of weeks were a bit rough while I was getting used to the ownership system, but since then I have been progressing at a relatively quick pace. The package and dependency management facilities are incredibly good, and I've found high-quality libraries for nearly all my initial needs.
Compilation times could be faster, but the error messages provided by the compiler are so useful that I have come to depend on compilation errors for refactoring. The gains in predictable performance and resource utilization have far outweighed any initial cognitive overhead in the learning process. The community and the resources they provide are fantastic.
Coming from a mixed dynamic language and functional programming background, I could see room for improving certain FP aspects of the language, but am impressed with the pervasive pattern matching and collection handling.
Not a knock on Go, but rather an endorsement of Rust and its future.
> Yes, the first couple of weeks were a bit rough while I was getting used to the ownership system, but since then I have been progressing at a relatively quick pace.
This is the very definition of "high barrier to entry". Clearly it wasn't too much of a barrier for you but I can see how it'd be an issue for people. I'm expecting editor support and wider adoption (differently constructed tutorials, SO answers) to lower this barrier. I think Rust has the potential to be very popular, particularly if the reputation shifts from "high barrier to entry" to "slightly harder to get started but fewer problems in production".
It took me about a week of fairly vigorous effort to start writing it fluently, but I also have the advantage of having seen and written many other programming languages. I have a few anecdotal examples of friends who are great developers, but still have trouble with Rust's ownership system.
When I say something like "incredibly", it's after thinking about trying to teach it someone more junior (like you'd see in a corporate environment with a mix of skill levels). I think that this would be a very difficult task.
Does Rust really have an "incredibly high barrier to entry?"
I've been using Rust for a few months, and just deployed my first high-throughput application a month ago, and my experience has been the opposite. Yes, the first couple of weeks were a bit rough while I was getting used to the ownership system, but since then I have been progressing at a relatively quick pace. The package and dependency management facilities are incredibly good, and I've found high-quality libraries for nearly all my initial needs.
Compilation times could be faster, but the error messages provided by the compiler are so useful that I have come to depend on compilation errors for refactoring. The gains in predictable performance and resource utilization have far outweighed any initial cognitive overhead in the learning process. The community and the resources they provide are fantastic.
Coming from a mixed dynamic language and functional programming background, I could see room for improving certain FP aspects of the language, but am impressed with the pervasive pattern matching and collection handling.
Not a knock on Go, but rather an endorsement of Rust and its future.