Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Generics enabled by default in Go tip

go-review.googlesource.com

Post reply on HN
Print view View original

291–300 of 378 posts

Re: Generics enabled by default in Go tip

#291

Post by valenterry »

toolslive wrote: post #209
smokey_circles wrote: post #187

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",…

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

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

Re: Generics enabled by default in Go tip

#292

Post by valenterry »

sascha_sl wrote: post #143

If you're really concerned about "clever developers", maybe you ought to ask for the removal of reflect and ast, because they've both been used to be way too clever about solving the same issue.

Correct. People will find a way to get rid of the verbosity and you either give them good tools to do it or you end up with a mess.

Re: Generics enabled by default in Go tip

#293

Post by papito »

Someone wrote: post #288
papito wrote: post #267

Earlier quoted context omitted.

I roll my eyes when someone claims "I learned Go over the weekend". It's one thing to learn basic syntax, and completely another to learn the customs of your new environment so most can understand what you are doing. Go is one of the hardest languages to learn. First of all, some concepts in it are very different from "mainstream" languages, and it takes a while to get used to them. Simple things that exist in almost…

IMO, “learning the language” and “getting used to it” are different things. The first is a purely theoretical exercise, the second a applied one that involves not only the language but also its ecosystem (implementation(s), library of functions and tooling)

I am not sure if we are agreeing or not, but I feel like we are. I think when people refer to "learning" a language, they mean they actually know how to use it properly. Learning the syntax does not count - that is just trivia any one of us can do.

Re: Generics enabled by default in Go tip

#294

Post by iso8859-1 »

4ad wrote: post #252
pkulak wrote: post #150

Earlier quoted context omitted.

Does Go generics have type erasure? If not, OP can expect and even better journey.

There are two meanings of "type erasure". One concerns the user, the other the compiler writer. When most users people ask about type erasure, they ask whether types are erased when compiling the reflection information for polymorphic values (like Java does). Go doesn't have polymorphic values, so the question doesn't apply. Type erasure means something more general than that to compiler people. Type erasure refers t…

So Haskell has type erasure only for data types that do not derive Typeable?

Re: Generics enabled by default in Go tip

#295

Post by josefx »

iainmerrick wrote: post #237
SideburnsOfDoom wrote: post #219

Earlier quoted context omitted.

> Go adds generics. HN thread: I don't want this If generics are a good idea for a language, then it's better to add them in version 0.01 of the language and build up from there with generics as an intrinsic part of the language and standard libraries. No, I don't want _tacked on_ generics. Generics are not in 2021 a "bleeding edge" feature, that _might_ be useful later. They are established and proven in ways that t…

No, I don't want _tacked on_ generics. What languages in your opinion have good, non-tacked-on generics? Are they generally better than other languages? Here are some pretty successful languages that gained generics after maturity: C++, Java, C#, TypeScript (based on JavaScript), Objective-C, even Python.

> C++

The parsing rules for templates alone probably make a decent door stopper. They can also trivially kill compile times. The bloat from page long symbol names also isn't something to ignore, just std::map::find() results in a decent chunk once the compiler is done expanding it.

> Java

That is a can of worms, haven't professionally worked with Java in some time, but from memory:

* Compile time only, reflection or serialization heavy code will get raw Object types, yay type safety.

* They do not support primitive types, resulting in object boxing and null-ability issues by default as well as third party copy paste libraries that provide collections specialized for primitives.

* You cannot create an object or array using a generic type as that is unknown at runtime, as result some methods require a concrete array as argument just so they can create their own array with the correct runtime type.

* It is fully backwards compatible, so nothing will tell you if you have a compiled library that uses raw types somewhere in your application dumping Integers into a List that should only contain Strings.

* Calling code has to verify object types using runtime casts, you may not want to pay the cost of that.

I could probably go on ...

> Python

Aren't those just hints that the interpreter completely ignores? I have a python 3 toy project that could have benefited from better type checking - the contents of its sqlite database are a mess.

Re: Generics enabled by default in Go tip

#296

Post by dgellow »

tedunangst wrote: post #34

Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.

That’s because “HN threads” represents a lot of different people with different needs and opinions. It’s not a monolithic block at all, and people are more likely to react to complain.

Re: Generics enabled by default in Go tip

#297

Post by 13415 »

smokey_circles wrote: post #187

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",…

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.

Re: Generics enabled by default in Go tip

#298

Post by mseepgood »

masto wrote: post #264
tedunangst wrote: post #34

Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.

I don’t know, at this point my guess is that most people just don’t care, so those that can be bothered to comment are a bit fringe. When Go first came out, it seemed interesting, but when I checked it out it felt more like throwing out the baby with the bathwater than introducing anything of value. Not every idea since 1972 is bad. So I tried to force myself to use it for a project or two, got frustrated by exactly…

> I haven’t seen any meaningful adoption

You must live in a different world. Go has been an immense success since its inception. Cloud, DevOps and SRE are nowadays unthinkable without it.

Re: Generics enabled by default in Go tip

#299

Post by fiddlerwoaroof »

Taek wrote: post #253
fiddlerwoaroof wrote: post #63

Earlier quoted context omitted.

Optimizing for people that are new to a codebase seems like a mistake to me: onboarding costs are relatively minimal and finite (per developer) whereas maintenance costs have no fixed bound: if generics let you exclude invalid states by design (and they do: this is one of the biggest advantages of parametric polymorphism vs. interfaces), they will be useful for keeping maintenance costs under control.

You definitely want to optimize for people who are new to a codebase. Over enough time, the codebase grows to a point where essentially _everyone_ is new to each area of the code, because nobody has touched that code in 2-3 years and the person who wrote it may not even be with the project anymore. Even for your own single-person projects - if you get fancy with the code, 6 months later you find it's a lot harder to…

You want patterns that are well-known to the maintainers, but this is different from “optimizing for the new”: consistent idiomatic use of a library like XState or Ramda in a JavaScript project can cause a high onboarding cost (because the new developers don’t know the library well) without any corresponding ongoing cost.

Re: Generics enabled by default in Go tip

#300

Post by djur »

silisili wrote: post #145
AnimalMuppet wrote: post #79

Earlier quoted context omitted.

You sound like, for you personally, generics are like a poison atmosphere. You simply can't live in that environment. Why? Why so negative? I work in C++. Generics exist there. I don't use them except for some STL containers. I just... don't use them. I don't have problems where I need them. How does it hurt me if they exist? You may say that someone else will use them, and make your code more unreadable. They may, b…

I don't mean to be negative only, and appreciate your reply. But I know what happens in real codebases. Before long, scammy tutorials pop up showing Go as an essentially dynamic language, and that's what bootcampers write. As of today, they are forced to write simple, boring code. I never mind a carefully added thing, for carefully thought of situations, as this probably was. The problem is that I see the abuse from…

It sounds to me like the simplicity of the language in this case didn't prevent a bad programmer from writing bad code, and that it was a problem that should have been addressed with code review and training, not by expecting the language to keep things in check.
Post reply on HN