5 ms·

When I read safer language, 'Rust' came into mind automatically.. Not sure if 'Rust' will ever be as popular as golang but certainly see a future with it poppi

When I read safer language, 'Rust' came into mind automatically.. Not sure if 'Rust' will ever be as popular as golang but certainly see a future with it popping up everywhere mission critical / super safe software is required.

JepZ 10y ago
I am afraid Rust will become much more popular than Go is atm. I think the C++ crowd will embrace it as soon as it will be mature. I am sure it is better than C++, but I still like the concepts and syntax of Go much better. 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.
- 59nadir 10y ago
  > ... but I still like the concepts and syntax of Go much better 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.
  - JepZ 10y ago
    I did not say that Rust is a worse language. I said I like Go better. I do not know exactly what it is, but I find rust code harder to read (e.g. I do not like the :: operator, which other languages have too). 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.
- vertex-four 10y ago
  I've... never had a problem reading Rust code. It's generally well-typed, and makes good use of "automatic" error handling constructs to ensure errors flow upwards without visually polluting the success case. 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 }
  - JepZ 10y ago
    My problems with the readability of Rust is related to the syntax and not so much about the code structure. For example, Smalltalk has the most readable syntax I know, while I find it's code structure average. 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 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.
    - vertex-four 10y ago
      I tend to find that Rust's syntax warts are primarily in function headers (primarily due to lifetimes), and less so in the bodies. > 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 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.
  - __david__ 10y ago
    It's slightly more tolerable if you do this: foo, err := bar() if err { return nil, err } But then the Go community yells at you for daring to not using `go fmt` style.
  - dullgiulio 10y ago
    You are not handling the error, you are just returning it. More correctly, you would decorate the error: foo, err := bar() if err != nil { return nil, fmt.Errorf("failed to do bar: %s", err) }
    - vertex-four 10y ago
      Sure, in some cases you want to wrap the error type - Rust handles this by essentially having you create a custom error type which is an enum (which can be done via macros like quick-error and error-chain), and implementing From<BarError> on it which'd create your custom error type from the BarError. This trait is used by both the try!() macro and the ? operator (which do much the same thing, the latter being the updated syntax): 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))?;
- sidlls 10y ago
  C and C++ are used in generally very conservative systems programming contexts. Safety is always considered with other items for tradeoff. Adoption just for reasons of safety isn't a given. 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.
  - JepZ 10y ago
    I agree that it will take a few years, but from the current point in time I think it will have a large market share in about 10 years.

JepZ 10y ago

I am afraid Rust will become much more popular than Go is atm. I think the C++ crowd will embrace it as soon as it will be mature. I am sure it is better than C++, but I still like the concepts and syntax of Go much better. 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.

59nadir 10y ago
> ... but I still like the concepts and syntax of Go much better 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.
- JepZ 10y ago
  I did not say that Rust is a worse language. I said I like Go better. I do not know exactly what it is, but I find rust code harder to read (e.g. I do not like the :: operator, which other languages have too). 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.
vertex-four 10y ago
I've... never had a problem reading Rust code. It's generally well-typed, and makes good use of "automatic" error handling constructs to ensure errors flow upwards without visually polluting the success case. 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 }
- JepZ 10y ago
  My problems with the readability of Rust is related to the syntax and not so much about the code structure. For example, Smalltalk has the most readable syntax I know, while I find it's code structure average. 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 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.
  - vertex-four 10y ago
    I tend to find that Rust's syntax warts are primarily in function headers (primarily due to lifetimes), and less so in the bodies. > 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 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.
- __david__ 10y ago
  It's slightly more tolerable if you do this: foo, err := bar() if err { return nil, err } But then the Go community yells at you for daring to not using `go fmt` style.
- dullgiulio 10y ago
  You are not handling the error, you are just returning it. More correctly, you would decorate the error: foo, err := bar() if err != nil { return nil, fmt.Errorf("failed to do bar: %s", err) }
  - vertex-four 10y ago
    Sure, in some cases you want to wrap the error type - Rust handles this by essentially having you create a custom error type which is an enum (which can be done via macros like quick-error and error-chain), and implementing From<BarError> on it which'd create your custom error type from the BarError. This trait is used by both the try!() macro and the ? operator (which do much the same thing, the latter being the updated syntax): 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))?;
sidlls 10y ago
C and C++ are used in generally very conservative systems programming contexts. Safety is always considered with other items for tradeoff. Adoption just for reasons of safety isn't a given. 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.
- JepZ 10y ago
  I agree that it will take a few years, but from the current point in time I think it will have a large market share in about 10 years.