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

341–350 of 378 posts

Re: Generics enabled by default in Go tip

#341

Post by pjmlp »

int_19h wrote: post #197
tptacek wrote: post #23

Earlier quoted context omitted.

You wouldn't. Everybody goes into Go thinking that's absurdly confining. Some significant subset of Go programmers learn that they instead find it liberating. Programming is programming; you have an overwhelming number of degrees of freedom no matter what language you work in. It sometimes turns out that taking some of those degrees out of the language makes it easier to focus them on your problem domain.

It's not like this is some kind of new or unfamiliar experience. Many programmers had to deal with something like that in Java or C#, back when they didn't have generics. There's a reason why both got them eventually.

The anti-generic folks usually ignore that the industry was built with non generic languages, and largely decided to adopt generics.

It isn't as if we never coded without generics before.

Re: Generics enabled by default in Go tip

#342

Post by pjmlp »

h4x0r12345 wrote: post #113
theshrike79 wrote: post #68

Earlier quoted context omitted.

If people would stick to common generic data structures (like a map/list that can handle any datatype), i'd be fine with abstractions. But some people have a tendency to play code golf with their codebases. I have, for example, encountered a "generic data structure" that looked like a normal linked list on the surface. BUT, it actually sorted the largest three items in the first 3 cells and the average in the 4th. Th…

Generics (and other abstractions) are not the root cause. Go was a pragmatic defence against mediocre developers. The majority of developers are mediocre by definition, and will abuse _any_ abstractions to create Rube Goldberg contraptions and monstrosities.

20 years ago those mediocre programmers were using Visual Basic and Java, so look for the past to see where future goes.

Re: Generics enabled by default in Go tip

#343

Post by pjmlp »

citrin_ru wrote: post #199
h4x0r12345 wrote: post #119

Earlier quoted context omitted.

No, it's relative. For the top 5% - 10% of developers, generics are a useful tool for doing their job efficiently. For the bottom 50% of developers, generics are complex and confusing, and only provides more footguns.

For 0.5%-1% C++ is a powerful tool which allows to quickly (thanks to rich abstractions) to write high-performance code. For merge mortals it is a tool hard not to misuse full of hidden traps and debugging of code written even by the very best developers (surprise - it has bugs too) is a challenge. Go just did a step towards C++, even if a tiny one.

Not everyone is entitled to be a sushi master.

Re: Generics enabled by default in Go tip

#344

Post by pjmlp »

dilyevsky wrote: post #60
bouncycastle wrote: post #36

Earlier quoted context omitted.

Singly linked lists are something from CS1 where you learn about data structures. You rarely use them in practice. In most cases slices and maps do the job fine.

They also have absolutely terrible performance due to poor cache locality and putting pressure on GC

There are many ways to implement a list, including backed by arrays.

That is what those CS algorithm and data structures lectures are for.

Re: Generics enabled by default in Go tip

#345

Post by pjmlp »

c-cube wrote: post #286
tephra wrote: post #166

Earlier quoted context omitted.

C11 introduced type generic expressions.

Not in the commonly understood sense of "generics", no. You get to switch on a type, but you don't have generic functions or types. A reusable, type-safe Vec or HashMap are still not possible in C...

Kind of, now that typeof is going to be part of the language, that coupled with the preprocessor, does allow exactly that.

Although in typical C fashion is a bit of kludge.

Re: Generics enabled by default in Go tip

#346

Post by pjmlp »

jshen wrote: post #95
rustc wrote: post #86

Earlier quoted context omitted.

Are generics really considered as "esoteric comp sci topics"?

If you want coding to be accessible to people without comp sci degrees, and those who are NOT employed as full time developers.

I learned C++ templates during high school, back when C++ARM book was the official standard.

Re: Generics enabled by default in Go tip

#347

Post by scns »

dolni wrote: post #314
chrismarlow9 wrote: post #307

Earlier quoted context omitted.

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 system…

> 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 simpl…

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

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

Re: Generics enabled by default in Go tip

#348

Post by rustc »

silisili wrote: post #290
rustc wrote: post #179

Earlier quoted context omitted.

> Before long, scammy tutorials pop up showing Go as an essentially dynamic language Sorry are you saying adding generics to Go makes Go closer to dynamic languages? Shouldn't that be the opposite? > I knew a person who insisted on a lot of things when working in a Go code base...one of which was mixed typed tuples. It was ugly, awful code of interfaces all the way down. It's ugly and Go let you know that. A voice of…

So, mixed typed tuples was the idea, but Go doesn't support either of those things, so it ended up as a [][10]interface{} or some such. So for each item in the slice, type assert all 10 things inside the subarray. Luckily the comments had a key of expected types of each.

That would be exactly the thing generics are supposed to fix (except that Go doesn't have tuples yet, but at least you can define your own now and return a generic `Tuple[A, B]`).

Regardless of that, returning a tuple of size 10, especially with different types, would almost always be a bad idea.

Re: Generics enabled by default in Go tip

#349

Post by SergeAx »

pjmlp wrote: post #338
SergeAx wrote: post #240

Earlier quoted context omitted.

I am okay with generics as long as they are not affecting compile time. I love Go for blazing fast builds and testing and afraid generics will degrade it. Otherwise, generics are adding some cognitive complexity to code, but I don't have to use them and will just occasionaly have to figure them out in libraries.

Check ML languages with its multiple backends, Eiffel or Delphi/FreePascal. Go compile times, while great, weren't any novelty to old timers before the .com wave that brought scripting languages into the spotlight and Sun's gigantic Java push. Thankfully the 20 years detour seems to be getting over.

Yeah, too bad I can't build a decent team to develop a distributed scalable application in FreePascal.

Re: Generics enabled by default in Go tip

#350

Post by pjmlp »

SergeAx wrote: post #349
pjmlp wrote: post #338

Earlier quoted context omitted.

Check ML languages with its multiple backends, Eiffel or Delphi/FreePascal. Go compile times, while great, weren't any novelty to old timers before the .com wave that brought scripting languages into the spotlight and Sun's gigantic Java push. Thankfully the 20 years detour seems to be getting over.

Yeah, too bad I can't build a decent team to develop a distributed scalable application in FreePascal.

That is a failing on your part given that the tools are available.
Post reply on HN