5 ms·

This was an extremely interesting read. I'm quiet disappointed though they did not update their Go Version to 1.13[0][1] which would normally have remove the s

This was an extremely interesting read. I'm quiet disappointed though they did not update their Go Version to 1.13[0][1] which would normally have remove the spike issue and thus he latency before they move to Rust... Rust seems more performant with proper usage ( tokio + async ) but I'm more worried about the ecosystem that doesn't seem has mature has Go. We could quote the recent[2] Drama with Actix... [0]https://golang.org/doc/go1.13#runtime https://golang.org/doc/go1.13#runtime [1]https://golang.org/doc/go1.12#runtime https://golang.org/doc/go1.12#runtime [2]https://github.com/fafhrd91/actix-web-postmortem https://github.com/fafhrd91/actix-web-postmortem

chc 7y ago
Why would you want to bring up the Actix author's drama? That doesn't seem like something that should reflect on a language one way or the other.
- deweller 7y ago
  As an outsider to both the Go and Rust cultures, I read the Actix news and walked away with the impression that the Rust ecosystem is less mature.
  - faitswulff 7y ago
    Every community has it. The dep vs. vgo drama gave me the same impression of Go at the time: https://news.ycombinator.com/item?id=17063724 https://news.ycombinator.com/item?id=17063724
  - cies 7y ago
    Go's is more pragmatic. Rust's is more purist, and that reflects on the language features (more functional, more free in allowing you to use it for any purpose where Go is network-app specific, more strict in typing), the licensing and the attitude towards collaboration. That collaboration thing is why Actix exploded I think. While mostly an isolated incident it does show some clash between the author's values (and possibly the author's employer's (MSFT) values) and the values of the general Rust community. I would not say that reflects on the maturity of the langues or ecosystem. In Go a lot of stuff is Google dictated. In Rust it's a true open governance innovation project (looking to become a non-profit). Since the Go is a very specific language --made for networked apps and only has one way to do concurrency-- and Rust very broad --a true general purpose prog lang-- it is easy to see how Go mature so quickly (not much to mature) and also why it got a bit old so quickly as well (ignores most innovations in computer science of the last decades).
    - nemothekid 7y ago
      The Go community has a very similar story, where someone released a web framework, with an unorthodox set of features, and was flamed to the point where he abandoned the project and quit OSS. https://github.com/go-martini/martini https://github.com/go-martini/martini
      - fjp 7y ago
        What was so unorthodox/upsetting to people there?
        nemothekid 7y ago
        Martini used the service injection pattern and made use of reflection to do so. It was a very popular framework and one of the first in Go (it currently has ~10k stars), and the use of reflection became a very contentious viewpoint in the community.
    - rob74 7y ago
      > Go is network-app specific Just because it is used most for "network apps" doesn't mean it's limited to that. On the other hand, you could argue that Rust is a wrong fit for anything _except_ performance-critical applications, because for anything else it's not worth to saddle yourself with the added complexity. > and Rust very broad --a true general purpose prog lang-- it is easy to see how Go mature so quickly (not much to mature) and also why it got a bit old so quickly as well This simplicity is the thing Go opponents like to point out (or mock) most, and what Go fans actually would tell you is one of the best features of the language. It's actually refreshing to have one language that doesn't try to be everyone's darling by implementing every conceivable feature - we already have enough of those, Rust, C++, Java etc. etc. But you don't have to take my word for it, you can also read the first sentences from this blog post: https://bradfitz.com/2020/01/30/joining-tailscale https://bradfitz.com/2020/01/30/joining-tailscale - he puts it better than I could...
      - cies 7y ago
        As the grant parent commentor i cannot down vote, so that wasn't me. Google explicitly shown no intent to make Go a fit beyond network apps. You can hack something into doing more than originally intended, but then you are usually operating "outside of warranty". > On the other hand, you could argue that Rust is a wrong fit for anything _except_ performance-critical applications Well, Rust does more than C-level high perf. It also allows for very safe/maintainable code that's high perf. Both of these are not something like a special feature, nope, ANY software needs to be high perf, bug free and maintainable to some degree. And as the size of the codebase grows, lack of these properties in a languages rears is ugly head. The added complexity cost, as you mentioned, is IMHO not a real cost. It's more like an investment. You go with Rust, you have to pay up front: learning new concepts, slower dev't, more verbosity/syntax/gibberish-y code. But once the codebase grows, you(r team) have grown accustomed to this and you start to reap the benefits of Rust's safety, freedom to choose your concurrency patterns, maintainability and verbosity. Now I do want to point out a REAL cost that was not mentioned yet, that Rust brings with it much more than Go: compile time. This sucks for Rust. Given the complexity of Rust, I dont expect it to ever come close to Go's lightning compiles. It will improve/ it constantly improving. And IDE features that prevent compiles (e.g.: error highlights) are maturing and will help too. But this is a big reason for picking Go. Your Jedi mind trick about Go's "simplicity" does not work on me :) ... It's fast compiles (a result of simplicity) are the bonus. Not being able to use the language beyond network apps or go-routine-concurrency are simply a minus for every learner (not for Google as a creator), as you limit the use of your new skill. The reason they kept the 1B$ mistake (null) in there is simply unforgivable. And if Go will never add features we have to see. Java also intended to stay lean, well...
  - chc 7y ago
    I actually agree that there are many parts of Rust's ecosystem that are relatively immature — I just don't see how the Actix situation reflects on that. It's not like Actix was a core part of the Rust ecosystem. It was a framework that was most notable for doing very well on the Techempower benchmarks. People get hurt feelings and have flameouts in the C, Java, JavaScript, etc. ecosystems too.
  - andoriyu 7y ago
    I wouldn't call rust ecosystem less mature than go, but it wouldn't call either of them mature. Both have ups and downs. Rust definitely has immature web service ecosystem and it's a result of immature async i/o ecosystem. At the same time go has those things otb.
- Communitivity 7y ago
  Agreed. One could argue that a level of drama in the community is a sign of growing maturity and wider interest in the language, because it is evidence there is no longer a niche monoculture of devs all thinking the same way. In the words of Steve Klabnik "Rust has been an experiment in community building as much as an experiment in language building. Can we reject the idea of a BDFL? Can we include as many people as possible? Can we be welcoming to folks who historically have not had great representation in open source? Can we reject contempt culture? Can we be inclusive of beginners?" https://words.steveklabnik.com/a-sad-day-for-rust https://words.steveklabnik.com/a-sad-day-for-rust The Actix issue was resolved, and Actix will continue under new maintainers (https://github.com/actix/actix-web/issues/1289 https://github.com/actix/actix-web/issues/1289). So I'd argue the answer to those questions is a 'yes'.

chc 7y ago

Why would you want to bring up the Actix author's drama? That doesn't seem like something that should reflect on a language one way or the other.

deweller 7y ago
As an outsider to both the Go and Rust cultures, I read the Actix news and walked away with the impression that the Rust ecosystem is less mature.
- faitswulff 7y ago
  Every community has it. The dep vs. vgo drama gave me the same impression of Go at the time: https://news.ycombinator.com/item?id=17063724 https://news.ycombinator.com/item?id=17063724
- cies 7y ago
  Go's is more pragmatic. Rust's is more purist, and that reflects on the language features (more functional, more free in allowing you to use it for any purpose where Go is network-app specific, more strict in typing), the licensing and the attitude towards collaboration. That collaboration thing is why Actix exploded I think. While mostly an isolated incident it does show some clash between the author's values (and possibly the author's employer's (MSFT) values) and the values of the general Rust community. I would not say that reflects on the maturity of the langues or ecosystem. In Go a lot of stuff is Google dictated. In Rust it's a true open governance innovation project (looking to become a non-profit). Since the Go is a very specific language --made for networked apps and only has one way to do concurrency-- and Rust very broad --a true general purpose prog lang-- it is easy to see how Go mature so quickly (not much to mature) and also why it got a bit old so quickly as well (ignores most innovations in computer science of the last decades).
  - nemothekid 7y ago
    The Go community has a very similar story, where someone released a web framework, with an unorthodox set of features, and was flamed to the point where he abandoned the project and quit OSS. https://github.com/go-martini/martini https://github.com/go-martini/martini
    - fjp 7y ago
      What was so unorthodox/upsetting to people there?
      - nemothekid 7y ago
        Martini used the service injection pattern and made use of reflection to do so. It was a very popular framework and one of the first in Go (it currently has ~10k stars), and the use of reflection became a very contentious viewpoint in the community.
  - rob74 7y ago
    > Go is network-app specific Just because it is used most for "network apps" doesn't mean it's limited to that. On the other hand, you could argue that Rust is a wrong fit for anything _except_ performance-critical applications, because for anything else it's not worth to saddle yourself with the added complexity. > and Rust very broad --a true general purpose prog lang-- it is easy to see how Go mature so quickly (not much to mature) and also why it got a bit old so quickly as well This simplicity is the thing Go opponents like to point out (or mock) most, and what Go fans actually would tell you is one of the best features of the language. It's actually refreshing to have one language that doesn't try to be everyone's darling by implementing every conceivable feature - we already have enough of those, Rust, C++, Java etc. etc. But you don't have to take my word for it, you can also read the first sentences from this blog post: https://bradfitz.com/2020/01/30/joining-tailscale https://bradfitz.com/2020/01/30/joining-tailscale - he puts it better than I could...
    - cies 7y ago
      As the grant parent commentor i cannot down vote, so that wasn't me. Google explicitly shown no intent to make Go a fit beyond network apps. You can hack something into doing more than originally intended, but then you are usually operating "outside of warranty". > On the other hand, you could argue that Rust is a wrong fit for anything _except_ performance-critical applications Well, Rust does more than C-level high perf. It also allows for very safe/maintainable code that's high perf. Both of these are not something like a special feature, nope, ANY software needs to be high perf, bug free and maintainable to some degree. And as the size of the codebase grows, lack of these properties in a languages rears is ugly head. The added complexity cost, as you mentioned, is IMHO not a real cost. It's more like an investment. You go with Rust, you have to pay up front: learning new concepts, slower dev't, more verbosity/syntax/gibberish-y code. But once the codebase grows, you(r team) have grown accustomed to this and you start to reap the benefits of Rust's safety, freedom to choose your concurrency patterns, maintainability and verbosity. Now I do want to point out a REAL cost that was not mentioned yet, that Rust brings with it much more than Go: compile time. This sucks for Rust. Given the complexity of Rust, I dont expect it to ever come close to Go's lightning compiles. It will improve/ it constantly improving. And IDE features that prevent compiles (e.g.: error highlights) are maturing and will help too. But this is a big reason for picking Go. Your Jedi mind trick about Go's "simplicity" does not work on me :) ... It's fast compiles (a result of simplicity) are the bonus. Not being able to use the language beyond network apps or go-routine-concurrency are simply a minus for every learner (not for Google as a creator), as you limit the use of your new skill. The reason they kept the 1B$ mistake (null) in there is simply unforgivable. And if Go will never add features we have to see. Java also intended to stay lean, well...
- chc 7y ago
  I actually agree that there are many parts of Rust's ecosystem that are relatively immature — I just don't see how the Actix situation reflects on that. It's not like Actix was a core part of the Rust ecosystem. It was a framework that was most notable for doing very well on the Techempower benchmarks. People get hurt feelings and have flameouts in the C, Java, JavaScript, etc. ecosystems too.
- andoriyu 7y ago
  I wouldn't call rust ecosystem less mature than go, but it wouldn't call either of them mature. Both have ups and downs. Rust definitely has immature web service ecosystem and it's a result of immature async i/o ecosystem. At the same time go has those things otb.
Communitivity 7y ago
Agreed. One could argue that a level of drama in the community is a sign of growing maturity and wider interest in the language, because it is evidence there is no longer a niche monoculture of devs all thinking the same way. In the words of Steve Klabnik "Rust has been an experiment in community building as much as an experiment in language building. Can we reject the idea of a BDFL? Can we include as many people as possible? Can we be welcoming to folks who historically have not had great representation in open source? Can we reject contempt culture? Can we be inclusive of beginners?" https://words.steveklabnik.com/a-sad-day-for-rust https://words.steveklabnik.com/a-sad-day-for-rust The Actix issue was resolved, and Actix will continue under new maintainers (https://github.com/actix/actix-web/issues/1289 https://github.com/actix/actix-web/issues/1289). So I'd argue the answer to those questions is a 'yes'.