Hacker News Reader

Comment by guessmyname | Hacker News Reader

Without generics (aka. Contracts) I don’t think so.

As much as I love how simple the language is in its current state (except for Go Modules, which still feels half baked), I don’t think the language is strong enough to live in an enterprise environment, yet. The tooling is good, and the community keeps growing and maturing, but the road to full enterprise embracement is quite long. I hope the statement in this article becomes a reality though, because I really enjoy working with it.

View on HN

Java had become the industry's workhorse also without generics, that were included only in Java 5, 8 years after Java 1.0. C++ had it for ages by that time, but it did not help its adoption too much (if not the other way around).

Go's very lack of expressive power is what helps make it an enterprise language. It's simple enough and limiting enough so that a non-brilliant developer has little trouble picking it up, and is unlikely to run into a complicated corner case. As statistics inevitably have it, half the developers are below median level, by definition.

The really smart stuff in Go, like goroutines scheduling or lightning-fast GC, is all under the hood, and you don't get to touch it, and don't have to.

You can see the same pattern in other wildly successful languages of the past, such as Fortran, Cobol, Visual Basic, or PHP.

Having one of the largest IT corporations backing the language and actively using it does help, too. But I would not exaggerate this factor: Python got to the top without a comparable corporate support from its creators.

>> Python got to the top without a comparable corporate support from its creators.<<

Yeah, but Google did a lot for python adoption.

Talking about coroutines, how do you do a synonym of async/await + Promise.all + cancellation token?

In a microservice world, I habe to send a request to 6 microservices and I want to do them concurrently not sequentially

use zeromq

Spin several goroutines, do a `select` on them. It's right in the Tour of Go.

Cancellation tokens are harder, though.

It’s been a while since I’ve been writing Go, but wasn’t that nominally what the Context objects were supposed to be for? I think they were introduced a bit late in the game, but APIs that supported them handled cancellation well (if I’m remembering right)

Context would be passed to each go-routines for cancellation but the pattern would be the same as OP's suggestion. I'd say a set of go-routines and a sync.WaitGroup would probably be a better pattern for this use case. Routines + select is more useful for listening on incoming data than concurrently sending out bytes.

Java had become the industry's workhorse also without generics...

Yeah but now that we have generics the bar has been raised right?

I’m not giving generics up, that’s for sure.

Java had the Object superclass, and that's how generic methods and classes were written before version 5.

Is there a Go equivalent of Object?

Yes. The empty interface.

Well of course you don't need to. Individual/independent developers would use what they deem fit. It is corporate developers who will receive mandate to use a particular language or technology. For example a large company where I work, it is mostly Java shop. However the new telemetry/tooling group has now mandated to use Go. So about 40+ devs are working in Go. Nobody asked their opinion about Go vs Java or Generics , Sum types, exception vs errors and so on. Same devs would have used Weblogic/Websphere or whatever if asked.

Developers in this categories are not going to say "LOL J2EE" or "LOL Go". They will do whatever being asked and collect paycheck in return. If they chose to be independent voice, they are going to be asked to leave and make way for devs who comply.

Totally agree. A lot of people address the lack of generics as merely a lack of a convenience feature. Sure, one aspect of generics are that they allow for more flexible types that help get around rewriting trivial variants, but that is hardly their primary function. Generics allow for the use of generalized functions while preserving arbitrarily complex typings to be preserved.

> generics (aka. Contracts)

What? Generics ≡ parametric polymorphism.

OP referring to Go2's draft proposal for generics where the feature is called Contracts. https://go.googlesource.com/proposal/+/master/design/go2draf...

They've already stated they will add generics

Enterprises don't choose a language for academic reasons ( generics ect ... ). They choose a language for stability, ecosystem, hiring difficulty, support ...

As a Go developer, I rarely ever miss generics. If you design up front with interfaces and the lack of generics in mind, you can almost always avoid needing them.

And when you finally get them, you'll wonder how you ever lived without :-)

Yet having moved from (primarily) Java to (primarily) Go I find I don't miss them.

I had them (Java and C#) and I am happy Go does not have them. I feel like most people just miss them for collections and abuse them in other instances.

And for collections Go has other tools (like generator if you really want to). Overall in the 2ish years of writing Go, I only missed them when I was learning the language coming from years of Java.

When you need to switch from native maps to sync.Map, you not only have to give up type safety but rewrite all your calling code. Codegen doesn't help because you are not one of the people allowed to overload those operators.

A bit like saying if you know you won’t have a hammer, you’ll instead bring a drill, a screwdriver, and screws. But sometimes it’s nice to be able to nail things together.

It is more that you code around the lack of generics.

Interfaces: same API, different source code. Generics: different APIs, same source code.

This is why Go needs to have generics.

Reply on news.ycombinator.com