But as C++ programmers obviously never care about readability and simplicity, I am pretty sure they will take Rust. After all, Rust is a decent language and as users, we will all benefit from the migration.
The concept of not having features because someone on your team might use them? You subtly say that Rust is a worse language because it doesn't seem like it was designed in the 80's, when clearly as a language (together with the compiler), it's objectively better than Go.
So this is my personal preference and should not offend any Rust fans. Besides the syntax, which reminds me too much of C++, I think Rust is a very good language. I do not know if it is 'objectively better than Go.'.
Btw. restrictions are not always bad.
Whereas with Go code, I have to filter out all the error handling (which often takes up 2/3rds of lines of code, even when it's just "if there's an error, return the error" which it almost always is), wade through the mass of functions that take interface{} and cast it to something internally, etc etc.
I've tried programming in Go and I find it horrifying - I either get to ignore errors or spend ~80% of my code doing this, repeatedly, a few times per function:
foo, err := bar()
if err {
return nil, err
}I know that error handling in Go can be tedious, but to some extent, it is also the programmer's job to utilize the features of the language to write clean code: https://blog.golang.org/errors-are-values
Regarding your type problem I find very few cases where I need an empty interface (mainly container types). Most of the time I use real interfaces and the most code I have seen used non-empty Interfaces too.
> Regarding your type problem I find very few cases where I need an empty interface (mainly container types).
I've run into the issue with quite a few "generic" libraries, since Go doesn't have a generics system. For example, https://github.com/manyminds/api2go requires a few of them in common cases.
My alternative is writing the same code over and over, and hoping that I've not missed something in one instance of it.
foo, err := bar()
if err { return nil, err }
But then the Go community yells at you for daring to not using `go fmt` style.More correctly, you would decorate the error:
foo, err := bar()
if err != nil {
return nil, fmt.Errorf("failed to do bar: %s", err)
} let foo = bar()?;
If you need to do something custom in converting bar()'s error into your error type - which is rare - you can use .map_err() like this: let foo = bar().map_err(|e| MyError::BarError(e, extraContext))?;As a result, the "maturity" required for adoption differs in different parts of the C and C++ community. If Rust becomes more popular than either of those languages it is unlikely to be on a time scale shorter than a decade or two. That's not to say it can't happen quicker, especially given that communication and adoption can be much quicker today than it was even 15-20 years ago, but it's unlikely.