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.

> 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.

> It's a limitation that will eventually catch up with you.

Go worked fine without it for 10 years...

> That means ergonomic monads are not possible to implement

This is a good thing?

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.

> 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.

+1

Plenty of great functional alternatives to Go.

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.

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.

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.

Ocaml is not particularly fast, for a compiled language. Is Go really slower?

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

(not GP)

>> fast compiler

But yeah everything is fast at runtime as well when you coming from JS and python.

Believe me, i'd love to use ocaml but the ecosystem isn't just "a bit more patchy" compared to go, unfortunately.

> and the ecosystem is maybe a bit more patchy..

Well that makes all the difference, if one is writing programs in professional capacity.

> 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.

> In fact kotlin/java has better peak performance than Go.

Not really no.

Sophisticated garbage collection and JIT have a very high ceiling. The CLR and the JVM are incredible technologies.

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.

> In fact kotlin/java has better peak performance than Go.

Says what benchmark?

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.

unless goroutines aren't in use, which means the generated code probably matches what llvm and C would generate.

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.

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.

> 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

You are right. Going by Google trends Scala is not only less popular then Go it is further going down when compared to Go [1]

1. https://trends.google.com/trends/explore?date=today%205-y&ge...

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.

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.

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.

What metric do you use for popularity? I'm more involved in the systems side so I'm definitely over exposed to Go projects. I would have considered Scala to be at least an order of magnitude less "popular" than Go. Kafka is the only open source project in Scala I can recall running into but there's probably a whole enterprise world I don't see.

For open source projects, it’s very popular in the “big data” world. Kafka, as you mentioned, but also Spark, Flink, Summingbird, Scalding, etc.

And yeah, it’s a pretty popular backend language at some large companies. Twitter, LinkedIn, Netflix, the Guardian, Starbucks, AirBnB, Coursera, AT&T, etc. all make significant use of Scala.

Go is certainly bigger, but Scala has plenty of adoption too.

Kafka is currently undergoing a rewrite into java.

Indeed. To add further it is also facing competition from Apache Pulsar and NATS. Not to forget Redpanda a Kafka rewrite in C++.

a small note on redpanda. Is not a `rewrite`. It is an entire new storage engine, different consensus protocol, different on-disk format, different internal RPC, no external dependencies, ...., in fact when i started it it was using flatbuffers as the API. What we did later to make money is add a kafka-API translation layer, but in terms of code size, is a very small part. The way i'd recommend thinking about it is a new storage engine that is compatible w/ kafka clients. https://github.com/redpanda-data/redpanda/tree/dev/src/v/kaf... - this is basically all the kafka-related code, the rest is net-new design.

Source?

But the guy answering there is talking about the Java clients.

Rust isn't a functional programming language. You could try OCaml, it's kind of a halfway point between Go and Haskell.

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?

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.

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.

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.

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.

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#.