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

Maybe adding generics to Go is about syntax after all

dave.cheney.net

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Maybe adding generics to Go is about syntax after all

#81

Post by lumost »

ilovecaching wrote: post #59

It's been three years since I started writing Go professionally and I think adding generics to Go is one of the worst ideas I've ever encountered. I love Haskell, and I much prefer hindley-milner type systems, type classes, and real sum types. I see the value of generics where appropriate. Golang, however, made the tradeoff to sacrifice anything near that level of abstraction, and it's success might largely be attrib…

I loved go from 1.3 onwards, and it still has a special place in my heart. But ultimately a failed attempt at writing a heavy numeric/scientific app in Go soured me on the lack of generics. the overhead of needing to re-implement functions in order to avoid casts was way to much to bear in one app, and projects such as gonum suffer either due to an over-reliance on interface or the requirement to constantly re-implement functions to deal with the change in type signature between int, float, and their associated sizes.

Re: Maybe adding generics to Go is about syntax after all

#82

Post by ilovecaching »

lumost wrote: post #81
ilovecaching wrote: post #59

It's been three years since I started writing Go professionally and I think adding generics to Go is one of the worst ideas I've ever encountered. I love Haskell, and I much prefer hindley-milner type systems, type classes, and real sum types. I see the value of generics where appropriate. Golang, however, made the tradeoff to sacrifice anything near that level of abstraction, and it's success might largely be attrib…

I loved go from 1.3 onwards, and it still has a special place in my heart. But ultimately a failed attempt at writing a heavy numeric/scientific app in Go soured me on the lack of generics. the overhead of needing to re-implement functions in order to avoid casts was way to much to bear in one app, and projects such as gonum suffer either due to an over-reliance on interface or the requirement to constantly re-implem…

This is an example of why I say use the right tool for the right job. Go is not the best language for scientific computing. Depending on the math involved you should likely be looking at Fortran or Python, which will most likely use Fortran or C under the hood. Go is best suited for small application or microservices, or as glue code for services.

Re: Maybe adding generics to Go is about syntax after all

#83

Post by kazinator »

evmar wrote: post #15
gnulinux wrote: post #6

Earlier quoted context omitted.

Why not use lisp syntax, at all? Why do we have to reinvent syntax every single generation? I'm not an old school engineer (I'm in my early 20s and in my first job, freshly outta college) but I can't see why we don't use lisp, prolog or ML syntax for everything . Seems vastly better than C-like synaxes in all ways I can think of, easier to implement, easier to extend, easier to read (imho) etc... When I program even…

I tinkered a bit (as many others have too!) with a lisp syntax for C, just to see what it'd feel like. That is, exact C semantics (so not inventing anything) but sexpressions. What I remember struggling with is that it was surprisingly kind of hard to remember when parens are necessary where. For example you might define an if statement: (if (> x 3) (printf ...)) Looks nice, but what about if you want multiple things…

  (when (> x )
    (printf a)
    (return b))

  (cond
    ((> x 3) (printf a)
             (return b))
    ((
Nobody who works with Lisps thinks in terms of "do I need double parentheses". You just know that if takes two or three expressions, when takes an expression followed by zero or more forms, cond takes a sequence of zero or more clauses which consist of a test followed by a body of zero or more forms.

If you're designing an S-exp syntax for something else, it's probably best to keep the familiar things the same; don't make some different if and such.

The Lisp if maps naturally to the ?: ternary operator; cond, when and unless can compile to cascaded if/else if/else.

Re: Maybe adding generics to Go is about syntax after all

#84

Post by oppositelock »

ilovecaching wrote: post #66
oppositelock wrote: post #62

Earlier quoted context omitted.

I've also been writing a lot of Go professionally for a long time, and I've used every part of the language extensively, and I disagree. There are many times I remember where I've had to implement some sort of application specific data structure that's not built into the language, and generics would have made it a lot nicer. I made it generic by using interfaces, but then you have the problem of throwing away type sa…

What do you mean by nicer? I would imagine that something that is application specific would not require generics. Interfaces do not throw away type safety if they are used correctly. They are also better suited for the consumer of the type rather than the definer. One of your problems might be that you are prematurely abstracting your interfaces for your callers.

Let's say that I have an interface called Sortable, so I design my data structure to accept and return Sortables. I can insert any Sortable into it. When I get the Sortable in a future lookup, I don't know its type. I have to use reflection to error check.

With generics, I could create a generic data structure which is strongly typed - what goes in is what comes out.

Right now, the way to ensure that is to wrap your data structure in something that converts those Sortables into specific classes, say PatientRecords.

Interfaces are wonderful, I like working in Go more than any other language so far, but they have their limitations.

Re: Maybe adding generics to Go is about syntax after all

#85

Post by cyphar »

slavapestov wrote: post #80
cyphar wrote: post #40

Earlier quoted context omitted.

(I agree that waiting until generics were ironed out would have been a better idea, because we already have pretty large communities around existing error handling libraries. Unfortunately this is a pattern of the Go language designers -- they have often ignored community consensus around an issue, like they did with vendor/ and other similar issues). My main issue with it (aside from making memes about RSI) is that…

The problem you describe is not specific to Go. You should always test all error paths in production code. Using mocks or error injection can help with triggering otherwise “impossible” cases.

That is definitely one argument (and I do see where you're coming from -- especially if your error path has a defer that does cleanup or something complicated like that). However, I don't think spending a significant amount of time mocking out every struct method that has an error return is a worthwhile investment -- the majority of 'if err != nil { return err }' cases are not going to be interesting and the ones that are usually don't even need mocking to test because they are significant enough error cases that they are easy to trigger using the real version of whatever struct. And of course you should test error paths to make sure that your code does validate things.

Re: Maybe adding generics to Go is about syntax after all

#86

Post by vgy7ujm »

goatlover wrote: post #79
oblio wrote: post #22

Earlier quoted context omitted.

The average programmers seem to like different symbols for what they consider different things. I don't know if it is better or not, but it seems to be the status quo...

But if that's really the case, then why hasn't Perl way of denoting the basic kind of variable with a starting symbol been copied in other languages? My guess is because most languages don't do that, so people are used to variables not having a symbol denoting their basic type. It largely comes down to what sort of syntax people are accustomed to.

It was copied. Php, Ruby, Powershell...

Re: Maybe adding generics to Go is about syntax after all

#87

Post by piano »

artursapek wrote: post #53
cmrdporcupine wrote: post #51

Earlier quoted context omitted.

Of course there are, but I wouldn't want to be the one to write them.

OK - well, from my 4+ yrs of experience creating and maintaining a big Go project, take it from me that it's really a very pleasant and productive language. I am branching out and learning Rust as an intellectual exercise, but can't help but think about how obtuse its syntax is compared to Go. I will continue to choose Go in the future just because it's so quick to work with (while also providing solid safety and ref…

It's not just the interface{} thing that's annoying. From my point of view, Go has way to many annoyances to be decent. No constness. No protection against copying. No compiler warnings. Crap error handling. Public/private denoted by uppercase/lowercase letter (WTF?). Implementation details leaking into the language - such as the "typed nil" nonsense. Struct and interface embedding is insane. Multiple returns from functions but no tuples. Needlessly complex `for` syntax, needlessly complex receiver syntax. Needless magic channel operators (they could've easily just been functions).

The tooling is also annoying with the most glaring deficiency being the lack of package versioning, which I believe is going to change (or it has already? I don't remember). And then there are tools like `go vet` which basically just attempt to make up for the compiler deficiencies in sub-par ways...

Go has a very nice runtime, but the language itself and the tooling feels extremely half-baked. I'm curious whether Go 2 will improve upon this.

Re: Maybe adding generics to Go is about syntax after all

#88

Post by pjmlp »

artursapek wrote: post #49
cmrdporcupine wrote: post #43

Earlier quoted context omitted.

It's the number one reason I tried out but wouldn't return and do anything serious in the language. And I'm not the only one.

There are numerous successful "serious" projects written in Go!

Many companies also had successful "serious" projects in Algol, Pascal, Basic, Forth, you name it.

The world of programming languages has improved since then.

Re: Maybe adding generics to Go is about syntax after all

#89

Post by kazinator »

AnimalMuppet wrote: post #71
dragonwriter wrote: post #65

Earlier quoted context omitted.

> My best try at a data point is that Lisp was #4 on the TIOBE index back in the 1980s. Unlikely, given that TIOBE the company wasn't founded until 2000, and the TIOBE index is based on web search engine results, and there weren't any web search engines, or a web for them to search, in the 1980s.

https://www.tiobe.com/tiobe-index/ has historical data going back to 1988. (Presumably they used a different methodology for the older data.) But I remembered wrong. They list Lisp as #2 in 1988.

In the realm of personal computing, Lisp was nothing in 1988. "Nobody" was doing any Lisp programming for affordable consumer hardware. Lisp had almost no mindshare among people who got started in computing with 8 bit microcomputers in the late 1970's and 80's and who moved on to PC's and Macs. (Speaking of Macs, there was maybe the OpenMCL exception there.) Lisp was something that you heard about that ran on "big iron" owned by exclusive institutions. Lisp machines count as that, basically.

Re: Maybe adding generics to Go is about syntax after all

#90

Post by artursapek »

piano wrote: post #87
artursapek wrote: post #53

Earlier quoted context omitted.

OK - well, from my 4+ yrs of experience creating and maintaining a big Go project, take it from me that it's really a very pleasant and productive language. I am branching out and learning Rust as an intellectual exercise, but can't help but think about how obtuse its syntax is compared to Go. I will continue to choose Go in the future just because it's so quick to work with (while also providing solid safety and ref…

It's not just the interface{} thing that's annoying. From my point of view, Go has way to many annoyances to be decent. No constness. No protection against copying. No compiler warnings. Crap error handling. Public/private denoted by uppercase/lowercase letter (WTF?). Implementation details leaking into the language - such as the "typed nil" nonsense. Struct and interface embedding is insane. Multiple returns from fu…

All very valid points. I think most of those features were omitted for the sake of simplicity by the Go team. Many people disagree with that.
Post reply on HN