5 ms·

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 commun

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.

toolslive 5y ago
Go has generics. They're just not (yet) available for you. So to some it feels like a Tantalus punishment.
- ibraheemdev 5y ago
  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-implements-maps-efficiently-without-generics https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...
  - masklinn 5y ago
    > 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.
    - sagichmal 5y ago
      > the builtins are ad-hoc and half-assed In what way are slices and maps half-assed?
      - amw-zero 5y ago
        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.
        sagichmal 5y ago
        > it’s just silly to confine quasi-generics to those 2 places Why is it silly?
- valenterry 5y ago
  That's not what anyone means when they say that a programming language has generics.
Zababa 5y ago
> 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 https://go.dev/blog/survey2020/missing_features.svg (from https://go.dev/blog/survey2020-results 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.
Abishek_Muthian 5y 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/ https://abishekmuthian.com/i-had-to-let-go-of-java/
kodah 5y ago
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.
chrismarlow9 5y ago
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.
- dolni 5y ago
  > 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.
13415 5y ago
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.
- wvh 5y ago
  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.
  - pjmlp 5y ago
    It isn't as if previous languages did not used code generators before generics were a thing on them.
    - amw-zero 5y ago
      Yea but, it has never been a particularly popular approach.
      - pjmlp 5y ago
        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.
- 5y ago
rowanG077 5y ago
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.
amw-zero 5y ago
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.

toolslive 5y ago

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

ibraheemdev 5y ago
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-implements-maps-efficiently-without-generics https://dave.cheney.net/2018/05/29/how-the-go-runtime-implem...
- masklinn 5y ago
  > 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.
  - sagichmal 5y ago
    > the builtins are ad-hoc and half-assed In what way are slices and maps half-assed?
    - amw-zero 5y ago
      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.
      - sagichmal 5y ago
        > it’s just silly to confine quasi-generics to those 2 places Why is it silly?
valenterry 5y ago
That's not what anyone means when they say that a programming language has generics.

Zababa 5y ago

> 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 https://go.dev/blog/survey2020/missing_features.svg (from https://go.dev/blog/survey2020-results 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.

Abishek_Muthian 5y 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/ https://abishekmuthian.com/i-had-to-let-go-of-java/

kodah 5y ago

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.

chrismarlow9 5y ago

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.

dolni 5y ago
> 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.

13415 5y ago

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.

wvh 5y ago
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.
- pjmlp 5y ago
  It isn't as if previous languages did not used code generators before generics were a thing on them.
  - amw-zero 5y ago
    Yea but, it has never been a particularly popular approach.
    - pjmlp 5y ago
      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.
5y ago

rowanG077 5y ago

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.

amw-zero 5y ago

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.