6 ms·

Great to see this! Generics will drastically improve datastructure libraries. That said, for people worrying about overcomplication, fortunately methods can't

Great to see this! Generics will drastically improve datastructure libraries. That said, for people worrying about overcomplication, fortunately methods can't have type parameters. That means ergonomic monads are not possible to implement, and we'll most probably not see the whole functional story play out in Go.

ed25519FUUU 5y ago
Plenty of great functional alternatives to Go.
- cube2222 5y ago
  Definitely! I'd be worried though that functional developers coming to Go (for whatever reason) would try to write Go functionally. That will fortunately be very hard thanks to this limitation. Nothing specific against functional programming per-se, but as you said, Go's not the language for it.
- zinclozenge 5y ago
  None with the same performance characteristics, ease of use, and ecosystem size. I'm reasonably competent with Rust, but sometimes I don't want to bash my head against the borrow checker or litter my code with copy/clone. Go hits a nice sweet spot, my main quibbles are that there's no native iterators/comprehensions or sum types with compiler checked exhaustive matching. With generics we can get libraries that allow for more functional style programming, and golangci-lint has a linter for exhaustiveness.
  - kaba0 5y ago
    Scala is pretty close to Go in terms of popularity and I would argue that it has a much bigger ecosystem due to the JVM. It is also pretty much a typed python in terms of ease of use, and the JVM has stellar performance — other than small running scripts, for many kind of workloads Java’s state of the art GC will have better throughput than Go’s.
    - Thaxll 5y ago
      Scala is on its way to die actually, I worked couple of years with lot of services in Scala, they were all replaced by regular Java or C# over the years, Scala missed the train and it's more and more difficult to find people that want to work with that language. It's a stagnant language that will not get more popular, it peaked.
      - kaba0 5y ago
        It just got a huge revamp with Scala 3, please do check it out if you hadn’t yet - it fixes some pain points while has many many exciting features, eg. can be null-safe with a single compiler flag (basically type T will not be able to represent a null, a java method that does return T will have a signature of T | Null). In great hands it can be insanely productive and well-maintainable, but of course I know that giving it to developers that look at the project more as a learning/experimenting thing can cause quite some damage due to the language’s strength.
      - yawaramin 5y ago
        I understand not keeping up with it but 'it's on its way to die' is just spreading FUD. It's more popular than ever. Disney+, Lego, Canada Post, basically every large bank–plenty of people are using it and adoption is increasing.
      - eweise 5y ago
        They just released Scala 3 this this year so hardly stagnant. The community seems to promoting more pragmatic functional approaches recently which I think is going to make Scala much more popular in the future.
      - bjt 5y ago
        > It's a stagnant language that will not get more popular, it peaked. I can't speak to whether it's "stagnant", but at least as a percentage of questions on Stack Overflow, the claim that "it peaked" checks out. The peak for Scala was late 2016. Go surpassed it in 2020. https://insights.stackoverflow.com/trends?tags=scala%2Cgo https://insights.stackoverflow.com/trends?tags=scala%2Cgo
  - cardanome 5y ago
    Ocaml. Insanely fast compiler. Great type system. Functional programming at its best but still relatively pragmatic and easy to mix in some imperative code if need be. It is a bit more complicated than Go and the ecosystem is maybe a bit more patchy but other than you will have a good time.
    - int_19h 5y ago
      Ocaml is not particularly fast, for a compiled language. Is Go really slower?
      - chakkepolja 5y ago
        (not GP) >> fast compiler But yeah everything is fast at runtime as well when you coming from JS and python.
      - feffe 5y ago
        The compiler is fast in that is compiles code quickly, just as Go and the execution speed of produced programs are similar to Go (depending on what abstractions you use). It seems there are a bunch of languages in the fast but not quite as fast as C/C++ category: Java, C#, Go, OCaml, SBCL (Lisp), Haskell
    - geodel 5y ago
      > and the ecosystem is maybe a bit more patchy.. Well that makes all the difference, if one is writing programs in professional capacity.
    - zinclozenge 5y ago
      Believe me, i'd love to use ocaml but the ecosystem isn't just "a bit more patchy" compared to go, unfortunately.
  - SureshG 5y ago
    > None with the same performance characteristics, Most JVM languages (Kotlin/Scala/Clojure) including Java :) In fact kotlin/java has better peak performance than Go. Main advantage for go is the reduced memory footprint.
    - Thaxll 5y ago
      > In fact kotlin/java has better peak performance than Go. Not really no.
      - dgb23 5y ago
        Sophisticated garbage collection and JIT have a very high ceiling. The CLR and the JVM are incredible technologies.
        ed25519FUUU 5y ago
        The thing I hate about the JVM is that I'm always trying to tune it. So many options and nobs to turn. With Go I just run execute the program, no tuning necessary.
    - jjtheblunt 5y ago
      > In fact kotlin/java has better peak performance than Go. Says what benchmark?
      - kitd 5y ago
        There are many benchmarks showing Java faster than Go. The trick is picking one that people agree is representative. It shouldn't be surprising though. "Peak performance" doesn't include start-up time, and ignores memory. If you discount both those, there's no reason that JITted native code wouldn't be faster than a runtime that includes goroutine scheduling.
        jjtheblunt 5y ago
        unless goroutines aren't in use, which means the generated code probably matches what llvm and C would generate.
  - yawaramin 5y ago
    Rust isn't a functional programming language. You could try OCaml, it's kind of a halfway point between Go and Haskell.
    - int_19h 5y ago
      Rust has first-class functions. Not only that, but it also has immutability by default, and ADTs with pattern matching. If OCaml is functional, why wouldn't Rust be?
      - chombier 5y ago
        Because of lifetime of captured variables in closures, mostly. You can't really pass around functions freely like you would in Haskell/ML unless you start Box-ing/Rc-ing everything. But then it's not really idiomatic Rust anymore, IIUC.
      - lmm 5y ago
        Rust doesn't really have first-class functions - you can't take an arbitrary snippet of code and turn it into a function value, because sometimes it will no longer pass the borrow checker.
      - yawaramin 5y ago
        Well, one big one is lack of tail call elimination. If you can't write even a simple tail-recursive algorithm in the language, it's not a functional programming language.
  - zozbot234 5y ago
    A bit offtopic here, but it's a bit weird to see this argument that using .clone() in Rust is "littering" the code. The feature is there for a reason, and using it will still give you vastly more efficient code than in most other languages; quite possibly including Go.
    - zinclozenge 5y ago
      Sure it very possibly might outperform Go, and almost undoubtedly outperform python and ruby, but it might also make refactoring for further performance down the road very difficult. When I reach for Rust, it's because I want maximum performance right off the bat. Otherwise I'd just use go, or even java/c#.
chabad360 5y ago
I'm curious why you say fortunately? I find it to be quite a down side that type parameters are missing. In fact it's quite confusing, because there is nothing that indicates a constrained interface can't be used in place of a regular one (until you try it). Personally, I think they should be included simply because they are a side effect of the generics syntax and it's much more confusing without. Also, they increase clarity and type safety, which are two of Go's main advantages. Also, type parameters were supposed to be included, but were dropped because it made the implementation more complex.
titzer 5y ago
> fortunately methods can't have type parameters. This is quite tricky to implement properly if the compiler doesn't do some form of specialization. (Basically, you need a different vtable entry for each instantiation of a generic method, or you need a runtime lookup to find it). But given that the Go compiler is doing complete specialization, I'm surprised they left this out. Generic methods (on classes) are the way to emulate first-class polymorphism (roughly, passing around type constructors) without explicit support in the language. It's a limitation that will eventually catch up with you.
- svnpenn 5y ago
  > It's a limitation that will eventually catch up with you. Go worked fine without it for 10 years...
acchow 5y ago
> That means ergonomic monads are not possible to implement This is a good thing?
- cube2222 5y ago
  Yes. I'm keeping up with the developments in functional languages, and many of them have lots of ways to do the same thing, with the "recommended" way changing once every 2 years. I intentionally choose Go where idiomatic code 5 years ago is mostly the same as idiomatic code now. Where no matter who writes the code, it ends up being fairly similar. Where I can easily dive into any open source library, understand the code base in 10 minutes, and make the fix I need. Where there's little-to-no bike shedding. I understand others might have different preferences, but as another comment mentioned, there are a bunch of languages satisfying those preferences very well (which I like very much as well overall, but I don't like using them for serious day-to-day coding). No reason to try to make everybody happy with a single language. Besides, I also think monads aren't a very good abstraction to use in most of your day-to-day code, so I'm happy I can avoid code using them.
  - bashery 5y ago
    +1
  - acchow 5y ago
    > Besides, I also think monads aren't a very good abstraction to use in most of your day-to-day code, so I'm happy I can avoid code using them. On the other hand, I think people are stuck in Monads all over the place without even realizing it's a Monad or having the language capabilities to work with them ergonomically.

ed25519FUUU 5y ago

Plenty of great functional alternatives to Go.

cube2222 5y ago
Definitely! I'd be worried though that functional developers coming to Go (for whatever reason) would try to write Go functionally. That will fortunately be very hard thanks to this limitation. Nothing specific against functional programming per-se, but as you said, Go's not the language for it.
zinclozenge 5y ago
None with the same performance characteristics, ease of use, and ecosystem size. I'm reasonably competent with Rust, but sometimes I don't want to bash my head against the borrow checker or litter my code with copy/clone. Go hits a nice sweet spot, my main quibbles are that there's no native iterators/comprehensions or sum types with compiler checked exhaustive matching. With generics we can get libraries that allow for more functional style programming, and golangci-lint has a linter for exhaustiveness.
- kaba0 5y ago
  Scala is pretty close to Go in terms of popularity and I would argue that it has a much bigger ecosystem due to the JVM. It is also pretty much a typed python in terms of ease of use, and the JVM has stellar performance — other than small running scripts, for many kind of workloads Java’s state of the art GC will have better throughput than Go’s.
  - Thaxll 5y ago
    Scala is on its way to die actually, I worked couple of years with lot of services in Scala, they were all replaced by regular Java or C# over the years, Scala missed the train and it's more and more difficult to find people that want to work with that language. It's a stagnant language that will not get more popular, it peaked.
    - kaba0 5y ago
      It just got a huge revamp with Scala 3, please do check it out if you hadn’t yet - it fixes some pain points while has many many exciting features, eg. can be null-safe with a single compiler flag (basically type T will not be able to represent a null, a java method that does return T will have a signature of T | Null). In great hands it can be insanely productive and well-maintainable, but of course I know that giving it to developers that look at the project more as a learning/experimenting thing can cause quite some damage due to the language’s strength.
    - yawaramin 5y ago
      I understand not keeping up with it but 'it's on its way to die' is just spreading FUD. It's more popular than ever. Disney+, Lego, Canada Post, basically every large bank–plenty of people are using it and adoption is increasing.
    - eweise 5y ago
      They just released Scala 3 this this year so hardly stagnant. The community seems to promoting more pragmatic functional approaches recently which I think is going to make Scala much more popular in the future.
    - bjt 5y ago
      > It's a stagnant language that will not get more popular, it peaked. I can't speak to whether it's "stagnant", but at least as a percentage of questions on Stack Overflow, the claim that "it peaked" checks out. The peak for Scala was late 2016. Go surpassed it in 2020. https://insights.stackoverflow.com/trends?tags=scala%2Cgo https://insights.stackoverflow.com/trends?tags=scala%2Cgo
- cardanome 5y ago
  Ocaml. Insanely fast compiler. Great type system. Functional programming at its best but still relatively pragmatic and easy to mix in some imperative code if need be. It is a bit more complicated than Go and the ecosystem is maybe a bit more patchy but other than you will have a good time.
  - int_19h 5y ago
    Ocaml is not particularly fast, for a compiled language. Is Go really slower?
    - chakkepolja 5y ago
      (not GP) >> fast compiler But yeah everything is fast at runtime as well when you coming from JS and python.
    - feffe 5y ago
      The compiler is fast in that is compiles code quickly, just as Go and the execution speed of produced programs are similar to Go (depending on what abstractions you use). It seems there are a bunch of languages in the fast but not quite as fast as C/C++ category: Java, C#, Go, OCaml, SBCL (Lisp), Haskell
  - geodel 5y ago
    > and the ecosystem is maybe a bit more patchy.. Well that makes all the difference, if one is writing programs in professional capacity.
  - zinclozenge 5y ago
    Believe me, i'd love to use ocaml but the ecosystem isn't just "a bit more patchy" compared to go, unfortunately.
- SureshG 5y ago
  > None with the same performance characteristics, Most JVM languages (Kotlin/Scala/Clojure) including Java :) In fact kotlin/java has better peak performance than Go. Main advantage for go is the reduced memory footprint.
  - Thaxll 5y ago
    > In fact kotlin/java has better peak performance than Go. Not really no.
    - dgb23 5y ago
      Sophisticated garbage collection and JIT have a very high ceiling. The CLR and the JVM are incredible technologies.
      - ed25519FUUU 5y ago
        The thing I hate about the JVM is that I'm always trying to tune it. So many options and nobs to turn. With Go I just run execute the program, no tuning necessary.
  - jjtheblunt 5y ago
    > In fact kotlin/java has better peak performance than Go. Says what benchmark?
    - kitd 5y ago
      There are many benchmarks showing Java faster than Go. The trick is picking one that people agree is representative. It shouldn't be surprising though. "Peak performance" doesn't include start-up time, and ignores memory. If you discount both those, there's no reason that JITted native code wouldn't be faster than a runtime that includes goroutine scheduling.
      - jjtheblunt 5y ago
        unless goroutines aren't in use, which means the generated code probably matches what llvm and C would generate.
- yawaramin 5y ago
  Rust isn't a functional programming language. You could try OCaml, it's kind of a halfway point between Go and Haskell.
  - int_19h 5y ago
    Rust has first-class functions. Not only that, but it also has immutability by default, and ADTs with pattern matching. If OCaml is functional, why wouldn't Rust be?
    - chombier 5y ago
      Because of lifetime of captured variables in closures, mostly. You can't really pass around functions freely like you would in Haskell/ML unless you start Box-ing/Rc-ing everything. But then it's not really idiomatic Rust anymore, IIUC.
    - lmm 5y ago
      Rust doesn't really have first-class functions - you can't take an arbitrary snippet of code and turn it into a function value, because sometimes it will no longer pass the borrow checker.
    - yawaramin 5y ago
      Well, one big one is lack of tail call elimination. If you can't write even a simple tail-recursive algorithm in the language, it's not a functional programming language.
- zozbot234 5y ago
  A bit offtopic here, but it's a bit weird to see this argument that using .clone() in Rust is "littering" the code. The feature is there for a reason, and using it will still give you vastly more efficient code than in most other languages; quite possibly including Go.
  - zinclozenge 5y ago
    Sure it very possibly might outperform Go, and almost undoubtedly outperform python and ruby, but it might also make refactoring for further performance down the road very difficult. When I reach for Rust, it's because I want maximum performance right off the bat. Otherwise I'd just use go, or even java/c#.

chabad360 5y ago

I'm curious why you say fortunately? I find it to be quite a down side that type parameters are missing. In fact it's quite confusing, because there is nothing that indicates a constrained interface can't be used in place of a regular one (until you try it). Personally, I think they should be included simply because they are a side effect of the generics syntax and it's much more confusing without. Also, they increase clarity and type safety, which are two of Go's main advantages. Also, type parameters were supposed to be included, but were dropped because it made the implementation more complex.

titzer 5y ago

> fortunately methods can't have type parameters. This is quite tricky to implement properly if the compiler doesn't do some form of specialization. (Basically, you need a different vtable entry for each instantiation of a generic method, or you need a runtime lookup to find it). But given that the Go compiler is doing complete specialization, I'm surprised they left this out. Generic methods (on classes) are the way to emulate first-class polymorphism (roughly, passing around type constructors) without explicit support in the language. It's a limitation that will eventually catch up with you.

svnpenn 5y ago
> It's a limitation that will eventually catch up with you. Go worked fine without it for 10 years...

acchow 5y ago

> That means ergonomic monads are not possible to implement This is a good thing?

cube2222 5y ago
Yes. I'm keeping up with the developments in functional languages, and many of them have lots of ways to do the same thing, with the "recommended" way changing once every 2 years. I intentionally choose Go where idiomatic code 5 years ago is mostly the same as idiomatic code now. Where no matter who writes the code, it ends up being fairly similar. Where I can easily dive into any open source library, understand the code base in 10 minutes, and make the fix I need. Where there's little-to-no bike shedding. I understand others might have different preferences, but as another comment mentioned, there are a bunch of languages satisfying those preferences very well (which I like very much as well overall, but I don't like using them for serious day-to-day coding). No reason to try to make everybody happy with a single language. Besides, I also think monads aren't a very good abstraction to use in most of your day-to-day code, so I'm happy I can avoid code using them.
- bashery 5y ago
  +1
- acchow 5y ago
  > Besides, I also think monads aren't a very good abstraction to use in most of your day-to-day code, so I'm happy I can avoid code using them. On the other hand, I think people are stuck in Monads all over the place without even realizing it's a Monad or having the language capabilities to work with them ergonomically.