Hacker News Reader

Comment by smokey_circles | Hacker News Reader

Language flamewars on internet forums are... strange.

Why have we all so strongly coupled our identities as programmers to the language we use? Sense of community and a perceived need to defend it?

I don't think Go needs generics, but I'm not about to invent obscure edge cases to justify for/against the idea. That's a recurring theme in all defenses of any language. It's not helpful.

Use Go if you like the "clarity", stay away from it if you don't like the "verbosity".

These are both valid points, but they're subjective. Pushing it as fact is dishonest and self-serving, as well as eventually detrimental.

View on HN

> Why have we all so strongly coupled our identities as programmers to the language we use?

Because the viability of a language is linked directly to its ecosystem and big names using it, so people that want to use one language have to promote its use if it's not in the top 5. You don't see many people advocating for Java, but some people are advocating for C#, Kotlin, Scala. You don't see many people advoating for JS, but many people are advocating for Elm, TypeScript, ReasonML.

On the other hand, people that are "forced" to use a language want to bring features from other languages they'd rather use. You can see in this graph https://go.dev/blog/survey2020/missing_features.svg (from https://go.dev/blog/survey2020-results) that people that want Go to change want to bring features from ML, Java, Rust, etc. Other languages. Because they have to work with Go or want to work with it but want to bring what they already know with them.

Lots of people spend 8 hours a day using the programming language that their company chose. Adding a few things that they like to it seem like a good way to make their life better.

How is it strange? It seems completely natural to me. A programming language is a tool that software devs have to use for 8 hours a day. And even more annoyingly the individual software dev generally doesn't get to decide what tool he gets to use. That means the top programming languages are always under a strong pressure to adopt feature X from Y devs favourite language. Now Go is quite an interesting case I think. It's essentially an ancient language with good tooling support backed by one of the largest companies in the world. Go has now yielded to generics. I don't think Go is capable of becoming modern because the initial design decision have essentially made that almost impossible. I wonder though, what the next feature for Go demanded by the community will be.

There is no doubt that Go needs generics. Pretty much every Go container and data structure library on github will benefit from generics. The empty interface is used everywhere, leading to all kinds of panicking typecasts, hard to debug errors, and inefficient conversions. The vast majority of these uses can be made type-safe, more efficient, and clearer with generics. There is nothing subjective about the benefits of generics. Together with type-safe enumerations I miss generics the most from Ada.

To be honest, I'd use Ada if it had a significant infrastructure, but it feels pretty much dead. With Go I can at least get 3rd party libraries, as long as I check the source code to see if it's good enough.

There's some pain in writing generic data structure algorithms for sure. It would have been an interesting experiment though if the Go authors would have tried to improve the tooling around code generation and making it easier to use, as an alternative avenue to generics as code generation might satisfy some of the cases likely to trigger those complains.

Anyway, interesting to see how far they will take the generics in the path to Go 2.

It isn't as if previous languages did not used code generators before generics were a thing on them.

Yea but, it has never been a particularly popular approach.

It surely was in C, C++ and Java.

Borland BIDS 1.0 used such approach with pre-processor tricks, similar to many C projects do as well.

Java, well EMF was a common tool to generate such boilerplate, Velocity was another one.

Might be dead for FOSS, but still has 5 compiler vendors around and a new standard revision being done.

For me it's about paradigms the language represents. I try to extend the simplicity of golang all the way to the network architecture. I've learned that it's better to build many very very simple things and connect them. Not for any technical reasons, but because it allows other developers to quickly begin adding to and fixing your systems. You get to leverage the large amount of mediocre programmers when your systems are simple instead of looking for heros. It's definitely easier said than done though to make systems naturally intuitive and simple.

I've also learned that in most cases you don't need to invent some giant application. It's far easier to create extensions or wrappers to existing operations or service tools, with a bonus (again) being easier hiring and delegation. You can hire someone who knows a standard piece of tech and quickly ramp them up on a small extension or wrapper that you wrote. Golang is the language that made me always take this simple approach first and look for something that does 80% of what I need and think about problems very generically.

> I've learned that it's better to build many very very simple things and connect them. Not for any technical reasons, but because it allows other developers to quickly begin adding to and fixing your systems. You get to leverage the large amount of mediocre programmers when your systems are simple instead of looking for heros. It's definitely easier said than done though to make systems naturally intuitive and simple.

Creating a bunch of microservices and connecting them has just moved your complexity from the "monolithic app" kind to the "integration" kind. It's much harder to understand the potential impact of your changes when "anything" could be using a service via the network.

It's a trade off here. If you have integration complexity, you need integration heroes.

> I've also learned that in most cases you don't need to invent some giant application. It's far easier to create extensions or wrappers to existing operations or service tools, with a bonus (again) being easier hiring and delegation. You can hire someone who knows a standard piece of tech and quickly ramp them up on a small extension or wrapper that you wrote. Golang is the language that made me always take this simple approach first and look for something that does 80% of what I need and think about problems very generically.

This is a great idea. Leverage industry experience when and where you can. Minimize the amount of "tribal knowledge" that your team requires to be effective.

Where did parent mention microservices? NSI (No Snark Intended).

(edit) A parody about those: https://www.youtube.com/watch?v=y8OnoxKotPQ

I gathered the bit about microservices from

> I try to extend the simplicity of golang all the way to the network architecture.

That's a fair take from my words but it wasn't the intent. Really I just meant stick with consistent hashing, queues and the like. I guess really the "leverage existing tools and patterns" would have covered it sufficiently. I'm by no means a micro service fan. It reminds me of people abusing containers the way people abused the nosql movement. It has its place. I think we agree at the end of the day, and it's difficult to put into words.

I think this derives from the fact that a fair amount of programmers are told what language they will write in and are forced to adhere to the languages semantics even if they liked other language semantics.

The force part comes from a desire for business continuity and efficiency. If you're a large scale Go shop there's a fair amount of specialized infrastructure needed including a goproxy to prevent leakage, some apparatus to view documentation, and probably educational resources.

A large scale Java shop needs extensive artifact storage and a place to host generated Java docs.

If you employ both languages your infra cost is now going up for something a business sees as pure overhead rather than the conduit for innovation. In my experience this leads to language supremacy discussions, bickering over scarce funding, etc.

On my team, we're polyglot. Everything, including docs, are generated and self-hosted internally. We make the best of a brisk situation. What lets me sleep okay at night is that developers have a choice to use the best tool (language) for the job, not just the one that a company hired for ten years ago.

When I started programming in Go after a decade of Java[1], I found it painful to not code without generics but then over the past couple of years I've become used to it.

I understood the philosophy of Go and why it didn't have generics or may be I'm just convincing myself of that because I'm invested in it. I think when you accept the philosophy of something you already get coupled into it.

I don't really have an opinion about Go bringing in generics, I would use every time saving feature available in a programming language. On the other hand I really hope additions like these doesn't become a point of friction among those who really have an opinion, Especially those who have been contributing to Go and end up forking Go.

[1] https://abishekmuthian.com/i-had-to-let-go-of-java/

Go has generics. They're just not (yet) available for you. So to some it feels like a Tantalus punishment.

If you're referring to map[K]V, that's not true. Go doesn't have generics, it uses some compiler magic under the hood specifically for the map type [0]. The generics proposal is being implemented from the ground up.

[0]: https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...

> If you're referring to map[K]V, that's not true. Go doesn't have generics, it uses some compiler magic under the hood specifically for the map type [0].

They're not generic (aka userland) generics, but they're still generics: parametric types, and functions able to work on them generically (you don't have a separate `append` function for every type you might put in a slice).

> The generics proposal is being implemented from the ground up.

Of course it is, the builtins are ad-hoc and half-assed. That doesn't mean they ain't a thing.

> the builtins are ad-hoc and half-assed

In what way are slices and maps half-assed?

I’m sure they mean that because they are not applicable to the rest of the language. It’s like, the Go creators recognized the situation where generics were necessary, but only used it for slices and maps.

I really don’t think they were saying that slices and maps themselves are bad. They function perfectly. I’m sure they meant that it’s just silly to confine quasi-generics to those 2 places.

> it’s just silly to confine quasi-generics to those 2 places

Why is it silly?

That's not what anyone means when they say that a programming language has generics.

Human nature though. When a topic is extremely complicated, or there’s some kind of power to be gained, we resort to tribalism. Both are present in software.

We’ve made societal progress on a lot of things, but not so much on this one.

For me, I always try and be conscious of that, and I tell coworkers when something that I’m suggesting is just preference over objective fact. For example, I prefer Ruby as a scripting language. My first job used it for various automations, and I got used to it. It has absolutely no value over Python as a scripting language for example. It’s just my preference.

Reply on news.ycombinator.com