5 ms·

Rust is ready, free, and open. Use it and stop complaining about Go.

mattnewton 10y ago
In my case it's python, Rust has a bit more of a learning curve / productivity hit. I'm still complaining though because I like what Go is doing with concurrency and simplicity, but I think it would be almost perfect if it just trusted the user a bit more.
- woah 10y ago
  You say you like the simplicity, yet you are complaining about it.
  - mattnewton 10y ago
    Besides the fact that I think it's less simple to have ad-hoc compiler extensions for the standard library types that can't be replicated in userspace, so the alternatives are code generation and type erasure, it doesn't have to be an absolute principal! We can have generics without sliding towards some slippery slope of abstraction! You don't allow some kind of generics one day and wake up the next day with custom operators and monads. The buck really can stop at this one pain point.
    - karma_vaccum123 10y ago
      Okay, that's nice, but the Go developers already picked their side in the debate many years ago. If you don't like it, use one of the many other tools available.
- stcredzero 10y ago
  I think it would be almost perfect if it just trusted the user a bit more. If it trusted the user just a bit more, it would be making many of the same mistakes other languages make, which Go is trying to avoid. You're free to go and use some of those other languages.
  - mattnewton 10y ago
    I don't understand this attitude. I do use other languages, and I can tell you type polymorphism is not a mistake. Complicated architectures full of abstraction are a mistake, which you can limit without sacrificing the ability for me to make a type-safe generic function.
    - stcredzero 10y ago
      I can tell you type polymorphism is not a mistake. It's a particular trade-off. Some opine that it's not the right trade off. You disagree. Complicated architectures full of abstraction are a mistake, which you can limit without sacrificing the ability for me to make a type-safe generic function. From what I've seen, the other mechanisms for limiting over-exuberant abstraction don't work well enough over the long term, at scale.
      - pcwalton 10y ago
        > From what I've seen, the other mechanisms for limiting over-exuberant abstraction don't work well enough over the long term, at scale. Can you name a specific example of people using ML-style generics (i.e. no typeclasses, no module system) to achieve "over-exuberant abstraction"?
        stcredzero 10y ago
        Nope. You got me there. I'm not so sure that would be cheap to implement in Golang, though. Also, your comment prompted me to find and read this: http://people.cs.uchicago.edu/~jacobm/pubs/templates.html http://people.cs.uchicago.edu/~jacobm/pubs/templates.html
  - pcwalton 10y ago
    > If it trusted the user just a bit more, it would be making many of the same mistakes other languages make, which Go is trying to avoid. Can you explain with an example that would apply to Go how introducing generics to a language was making a mistake? Be specific.
commentzorro 10y ago
Rust has manual memory management. Most applications where you'd use Go don't need nor want the added complexity of managing memory, ownership, learning curve, etc. It's not really a reasonable exchange.

In my case it's python, Rust has a bit more of a learning curve / productivity hit. I'm still complaining though because I like what Go is doing with concurrency and simplicity, but I think it would be almost perfect if it just trusted the user a bit more.

woah 10y ago
You say you like the simplicity, yet you are complaining about it.
- mattnewton 10y ago
  Besides the fact that I think it's less simple to have ad-hoc compiler extensions for the standard library types that can't be replicated in userspace, so the alternatives are code generation and type erasure, it doesn't have to be an absolute principal! We can have generics without sliding towards some slippery slope of abstraction! You don't allow some kind of generics one day and wake up the next day with custom operators and monads. The buck really can stop at this one pain point.
  - karma_vaccum123 10y ago
    Okay, that's nice, but the Go developers already picked their side in the debate many years ago. If you don't like it, use one of the many other tools available.
stcredzero 10y ago
I think it would be almost perfect if it just trusted the user a bit more. If it trusted the user just a bit more, it would be making many of the same mistakes other languages make, which Go is trying to avoid. You're free to go and use some of those other languages.
- mattnewton 10y ago
  I don't understand this attitude. I do use other languages, and I can tell you type polymorphism is not a mistake. Complicated architectures full of abstraction are a mistake, which you can limit without sacrificing the ability for me to make a type-safe generic function.
  - stcredzero 10y ago
    I can tell you type polymorphism is not a mistake. It's a particular trade-off. Some opine that it's not the right trade off. You disagree. Complicated architectures full of abstraction are a mistake, which you can limit without sacrificing the ability for me to make a type-safe generic function. From what I've seen, the other mechanisms for limiting over-exuberant abstraction don't work well enough over the long term, at scale.
    - pcwalton 10y ago
      > From what I've seen, the other mechanisms for limiting over-exuberant abstraction don't work well enough over the long term, at scale. Can you name a specific example of people using ML-style generics (i.e. no typeclasses, no module system) to achieve "over-exuberant abstraction"?
      - stcredzero 10y ago
        Nope. You got me there. I'm not so sure that would be cheap to implement in Golang, though. Also, your comment prompted me to find and read this: http://people.cs.uchicago.edu/~jacobm/pubs/templates.html http://people.cs.uchicago.edu/~jacobm/pubs/templates.html
- pcwalton 10y ago
  > If it trusted the user just a bit more, it would be making many of the same mistakes other languages make, which Go is trying to avoid. Can you explain with an example that would apply to Go how introducing generics to a language was making a mistake? Be specific.

commentzorro 10y ago

Rust has manual memory management. Most applications where you'd use Go don't need nor want the added complexity of managing memory, ownership, learning curve, etc. It's not really a reasonable exchange.