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

Go generics are not bad

lemire.me

Post reply on HN
Print view View original

161–170 of 305 posts

Re: Go generics are not bad

#161

Post by potamic »

yawaramin wrote: post #116
sangnoir wrote: post #107

Earlier quoted context omitted.

> Academia on the other hand will make great languages that never reaches critical mass Interesting choice of words: my guess is that the great languages Academia cook-up scale poorly on code bases which receive tens of updates per day (let alone hundreds or thousands). There's usually a huge difference between industrial tools and artisanal ones.

Well, let's look at the case of Facebook Messenger's webapp, which is written in BuckleScript (now ReScript), a language based on OCaml. That's about as solid as you can get academically. Here's what they said:[1] > Full rebuild of the Reason part of the codebase is ~2s (a few hundreds of files), incremental build (the norm) is > Messenger used to receive bugs reports on a daily basis; since the introduction of Reaso…

Aren't Reason and ReScript different languages? It's confusing which one they're talking about here.

Re: Go generics are not bad

#162

Post by iasay »

philosopher1234 wrote: post #141
cookiengineer wrote: post #101

What I still don't understand is why golang has exceptions for "language constructs" like make() and append()... while those are unimplementable in golang. It's pretty annoying that golang embraces static and functional patterns in its core, but it doesn't even have map/filter/reduce/forEach as generic implementations for all data types. The lack of a "new" keyword and default values for struct's property syntax is a…

Can’t hate on generics, so we need to find something else. Go takes away type system fidget spinners and leave devs with nothing to do but the actual job, which they hate, and thus they hate Go.

That’s actually a brilliant assertion (sorry for the crap pun).

The majority of developers I work with are only aware of the success paths of their code. That means we’re knee deep in exception corpses because they avoided doing part of their job.

Go makes them deal with it.

Re: Go generics are not bad

#163

Post by petmon »

kevin_thibedeau wrote: post #149
tbarbugli wrote: post #122

Earlier quoted context omitted.

in Go ‘new’ is a function, not a keyword I think that parent probably refers to the lack of something like this: x := new MyType

This requires an exception mechanism to handle allocation failure. This issue pervades C++ when exceptions are disabled. Important error handling goes unhandled.

How does Go handle allocation failure? In my understanding objects may be allocated on the stack or heap per the compiler's whims. If a heap allocation fails, you just get "fatal error: runtime: out of memory" and an abort.

Re: Go generics are not bad

#164

Post by [deleted] »

iasay wrote: post #162
philosopher1234 wrote: post #141

Earlier quoted context omitted.

Can’t hate on generics, so we need to find something else. Go takes away type system fidget spinners and leave devs with nothing to do but the actual job, which they hate, and thus they hate Go.

That’s actually a brilliant assertion (sorry for the crap pun). The majority of developers I work with are only aware of the success paths of their code. That means we’re knee deep in exception corpses because they avoided doing part of their job. Go makes them deal with it.

[deleted]

Re: Go generics are not bad

#165

Post by silisili »

tapirl wrote: post #61

This article is too simple to get a full picture of Go custom generics. There are actually both good points and bad points. To get a comprehensive understanding of the current Go custom generics, please read: https://go101.org/generics/101.html

Your statement may be correct, and your book may be excellent.

But insulting a free knowledge sharing article while posting your own site which is laden with 'buy buy buy' is rather poor taste, IMO.

Re: Go generics are not bad

#166

Post by kgeist »

cookiengineer wrote: post #143
philosopher1234 wrote: post #141

Earlier quoted context omitted.

Can’t hate on generics, so we need to find something else. Go takes away type system fidget spinners and leave devs with nothing to do but the actual job, which they hate, and thus they hate Go.

Generics are useless when there is no way to integrate them with your rest of the code. As golang has no instanceof or typeof keyword, you practically you cannot use a method that uses multiple types as arguments without having to use the reflect API, just to have an if/else branch on what to do with that argument. The things that I mentioned are from another point of view where language designers and implementers de…

>As golang has no instanceof or typeof keyword, you practically you cannot use a method that uses multiple types as arguments without having to use the reflect API

You don't have to use reflection, there are typecasts:

"value, ok := arg.(MyType)"

You can also switch on a type. How is it different from instanceof in practice?

Re: Go generics are not bad

#167

Post by silisili »

danielscrubs wrote: post #87

Either you start making a language from a sound theoretical foundation and then implement it (Koka springs to mind) or you implement a language from some syntactic gripes and then try to find the theoretical foundation later… Go was impressive in the practical sense (compiler speed, channels in std and good tooling) but a shit show otherwise. I’ve completely lost any confidence that FANG will be able to make some gre…

Go is odd in that people constantly complain about what it cannot do or does incorrectly, while having become one of the most prolific languages at the same time.

Re: Go generics are not bad

#168

Post by germandiago »

pkolaczk wrote: post #129
germandiago wrote: post #67

Earlier quoted context omitted.

really? Is Go that bad? Write a server that does communication or emulate select in Go in other languages. Go is really effective at writing things fast at the same time that it has value types and can scale not only in I/O but also in multi-core in a way that is easier than anything I saw before. I am a mainly C++ person but I must admit that the cost/investment ratio in Go is really good for writing server-side stu…

> Write a server that does communication or emulate select in Go in other languages. I just did that - I've been working on a very similar thing to goduplicator (a mirroring proxy), however with an additional requirement that it must not add latency to the primary communication path, e.g must connect mirrors asynchronously and buffer data instead of waiting for a slow mirror. I chose Rust and the resulting code has b…

Well, for latency you do have to deal with the GC very carefully, but the investment/ratio in Go is very good. It is just not for absolutely every use case, like everything else in your toolbox.

Re: Go generics are not bad

#169

Post by kgeist »

moelf wrote: post #30

"not bad" is a weird bar to cross for a language that: 1. decided generics is not needed 2. went on for a decade 3. implemented a version of it that is not performance-sensitive 3.5. $$ by google

>decided generics is not needed >went on for a decade

The FAQ on the official site already back in 2013 (I couldn't find an earlier snapshot on webarchive) stated they were open to adding generics but weren't sure how to properly design/implement them without overcomplicating the language, citing also other priorities.

>implemented a version of it that is not performance-sensitive

It's less performant than the ideal but it's a tradeoff to avoid exponential code bloat found in C++. In our large C++ project which extensively used templated boost.signals the code bloat from using templates alone added a whopping 200 MB of machine code which we were able to shed off by switching to our in-house library. IIRC C# uses an approach similar to Go to share generated code with some type-specific conditions at runtime (at least Mono I remember shared generic code for all reference types)

Re: Go generics are not bad

#170

Post by red_admiral »

throwaway234232 wrote: post #49

I think in Java, you would need to do a type-class approach. interface Numeric { T zero(); T add(T a, T b); } static T sum(Numeric n, T[] v) { T summer = n.zero(); for (int k = 0; k

Isn't the java problem that (a) the + operator is only defined for some built-in types, and (b) the int/Integer boxing distinction?
Post reply on HN