4 ms·

Go needs more syntactic sugar.

barnabee 3y ago
I honestly think the only remaining thing I'd need from Go to almost never pick up Rust for a new project is sum types. If there was a NewGo with no concept of a raw 'nil' value (replaced by Maybe<T>) and err, res in the standard library replaced with Result<T, E>, I'd have vanishingly few reasons to use Rust. If we got TinyNewGo too for embedded/WASM… uh oh
- efnx 3y ago
  If Go had sum types it would be a completely different language - compile times would skyrocket and it would likely look like Rust without the borrow checker. Personally I think it would be better than Go, but I think most Go folks would dislike it. For me the big draw of Go (which are few) is the compile time.
  - SkiFire13 3y ago
    What makes you think that sum types make compile time skyrocket?
    - efnx 3y ago
      Because it introduces a different type system like Hendly-Milner. One of the reasons Go has incredible compile times is because it doesn’t have to calculate types the way Haskell, Rust and other ML-like languages do.
      - fl0ki 3y ago
        Go already faces a subset of this type system challenge in an arguably much worse way: interfaces are implicitly implemented by any type with the corresponding set of method signatures, unlike Rust where traits are implemented explicitly. In that sense, Go already has sum types with how it handles interfaces, but having to check every single method instead of a single trait. In Rust trait solving can only affect compile time, in Go it affects runtime [1]. Anyone who has looked into optimizing Go performance enough has seen what a horror this can be, and it's hard to watch people say that Go's type system is one of its strengths. Really, most of the people speculating on why Rust compiles are slow simply haven't read how much analysis has already gone into it [2]. We already know the majority of why they're slow: Rust generates a lot of LLVM IR and LLVM has to process that as-is before it can eliminate the redundant parts and optimize the rest. A complementary issue is that if you use a lot of proc macros, their code has to run before the rest of the compile can even begin, and they often emit a lot of code that becomes a lot of LLVM IR. There are workarounds for both parts -- you can optimize the proc macro compilation itself, and you can keep proc macro code (serde schemas, etc) to a separate crate in the same workspace so they are cached for more of the time. These remain real issues with real tradeoffs, but either way, this has absolutely nothing to do with how long type checking itself takes. If anything, it seems pretty quick given how much macro-generated code it has to check. The easiest way to see that is to run cargo clippy instead of cargo build. Even despite the enormous breadth & depth of analysis that clippy does -- far beyond simply checking if types are satisfied, and worlds beyond what golangci-lint can analyze -- it doesn't take that much longer than golangci-lint alone. That's bearing in mind it still has to expand the proc macros too. Finally, Go does a good job at transparently caching a lot of its build artifacts, much more than Cargo/Rust. If you completely clear your compile cache, you'll notice it can take a lot longer in Go as well. I'm not saying that's not an advantage to Go in practice, just that -- again -- it has nothing to do with the type system. I urge people to speculate less about what makes Rust compiles take longer and catch up on the analysis already done. Even if you don't care about Rust, at least you'll have a better idea of what tradeoffs Go can explore in future, instead of simply assuming that any deviation from what Go does today would make compile times "skyrocket". That's not a useful way to reason about language and toolchain tradeoffs, especially not when real data are never more than a web search away. [1] https://planetscale.com/blog/generics-can-make-your-go-code-slower https://planetscale.com/blog/generics-can-make-your-go-code-... [2] https://www.pingcap.com/blog/reasons-rust-compiles-slowly/ https://www.pingcap.com/blog/reasons-rust-compiles-slowly/
      - School-Cotton 3y ago
        The fact that cargo check (which does full type checking) is so much faster than cargo build proves that type checking doesn’t account for the bulk of compile time.
      - nequo 3y ago
        OCaml itself is known for exceptionally quick compilation though. Despite Hindley–Milner with type inference. GHC for Haskell and rustc for Rust are slower because of the optimization passes that they do. GHC needs to be more aggressive about optimization in order to make lazy code perform well. And rustc in order to deliver on Rust’s promise of zero-cost abstractions.

I honestly think the only remaining thing I'd need from Go to almost never pick up Rust for a new project is sum types. If there was a NewGo with no concept of a raw 'nil' value (replaced by Maybe<T>) and err, res in the standard library replaced with Result<T, E>, I'd have vanishingly few reasons to use Rust. If we got TinyNewGo too for embedded/WASM… uh oh

efnx 3y ago
If Go had sum types it would be a completely different language - compile times would skyrocket and it would likely look like Rust without the borrow checker. Personally I think it would be better than Go, but I think most Go folks would dislike it. For me the big draw of Go (which are few) is the compile time.
- SkiFire13 3y ago
  What makes you think that sum types make compile time skyrocket?
  - efnx 3y ago
    Because it introduces a different type system like Hendly-Milner. One of the reasons Go has incredible compile times is because it doesn’t have to calculate types the way Haskell, Rust and other ML-like languages do.
    - fl0ki 3y ago
      Go already faces a subset of this type system challenge in an arguably much worse way: interfaces are implicitly implemented by any type with the corresponding set of method signatures, unlike Rust where traits are implemented explicitly. In that sense, Go already has sum types with how it handles interfaces, but having to check every single method instead of a single trait. In Rust trait solving can only affect compile time, in Go it affects runtime [1]. Anyone who has looked into optimizing Go performance enough has seen what a horror this can be, and it's hard to watch people say that Go's type system is one of its strengths. Really, most of the people speculating on why Rust compiles are slow simply haven't read how much analysis has already gone into it [2]. We already know the majority of why they're slow: Rust generates a lot of LLVM IR and LLVM has to process that as-is before it can eliminate the redundant parts and optimize the rest. A complementary issue is that if you use a lot of proc macros, their code has to run before the rest of the compile can even begin, and they often emit a lot of code that becomes a lot of LLVM IR. There are workarounds for both parts -- you can optimize the proc macro compilation itself, and you can keep proc macro code (serde schemas, etc) to a separate crate in the same workspace so they are cached for more of the time. These remain real issues with real tradeoffs, but either way, this has absolutely nothing to do with how long type checking itself takes. If anything, it seems pretty quick given how much macro-generated code it has to check. The easiest way to see that is to run cargo clippy instead of cargo build. Even despite the enormous breadth & depth of analysis that clippy does -- far beyond simply checking if types are satisfied, and worlds beyond what golangci-lint can analyze -- it doesn't take that much longer than golangci-lint alone. That's bearing in mind it still has to expand the proc macros too. Finally, Go does a good job at transparently caching a lot of its build artifacts, much more than Cargo/Rust. If you completely clear your compile cache, you'll notice it can take a lot longer in Go as well. I'm not saying that's not an advantage to Go in practice, just that -- again -- it has nothing to do with the type system. I urge people to speculate less about what makes Rust compiles take longer and catch up on the analysis already done. Even if you don't care about Rust, at least you'll have a better idea of what tradeoffs Go can explore in future, instead of simply assuming that any deviation from what Go does today would make compile times "skyrocket". That's not a useful way to reason about language and toolchain tradeoffs, especially not when real data are never more than a web search away. [1] https://planetscale.com/blog/generics-can-make-your-go-code-slower https://planetscale.com/blog/generics-can-make-your-go-code-... [2] https://www.pingcap.com/blog/reasons-rust-compiles-slowly/ https://www.pingcap.com/blog/reasons-rust-compiles-slowly/
    - School-Cotton 3y ago
      The fact that cargo check (which does full type checking) is so much faster than cargo build proves that type checking doesn’t account for the bulk of compile time.
    - nequo 3y ago
      OCaml itself is known for exceptionally quick compilation though. Despite Hindley–Milner with type inference. GHC for Haskell and rustc for Rust are slower because of the optimization passes that they do. GHC needs to be more aggressive about optimization in order to make lazy code perform well. And rustc in order to deliver on Rust’s promise of zero-cost abstractions.