151–160 of 176 posts
Nobody will have anything to complain about once go has generics, we'll never hear about Golang on Hacker News again! It'll just be the Rust people complaining. ;)
Earlier quoted context omitted.
> C doesn't have them and is arguably the most successful language in history. I'm not sure "C didn't have it" is a good litmus test for determining the value of features... C is called a portable assembler for a reason. > Yes, they are convenient, but they also add a lot of complexity to the language and toolchain. Conversely, proponents of generics would argue that not having them creates complexity for software de…
> I'm not sure "C didn't have it" is a good litmus test for determining the value of features It can be a good test. One reason why C is so ubiquitous is the simple binary interface. This makes it easy to reuse code since the libraries can be imported by every other language out there. C code is relatively simple and the compiled objects follow simple binary interfaces. Adding features to languages almost always incr…
I really wish they went with angle brackets like everyone else does. I get the argument about not wanting to break existing parsers but this is a significant enough language change to warrant that.
D, Modula-3 and Ada use parenthesis.
ML based languages use quoted letters.
There is no everyone else.
Earlier quoted context omitted.
> I wish that Go would adopt Sum Types And then make a Maybe sum type? But then it is too late as the std lib communicates with nils instead of Maybes > The best way to know something won't be null is to use value types where possible. Don't return nilable values unless you have a good reason. I'm not doing this, I'm using an API that does! I cannot choose what some code returns, all I can do is --sigh-- add another…
> If it is my discipline to add null guards or have runtime explosions I consider the nulls to be implicit. But they're still explicit nulls. You seem to be saying that only implicit nulls require null guards, but that's just not what that means (as far as I have learned). You seem to hate nullability as a concept, which is fine, but that's different from hating implicit nullability. > That you find as much runtime p…
But I might well be mistaken.
IMO the biggest factors for the success of Go are 1) super-fast compile times, 2) easy to interpret compiler errors, and 3) dead simple shipment of high performance, native static binaries. I think Go has succeeded, despite, not because of the language itself. One very big limitation being the lack of generics or any sort of ability to leverage higher-order types. Sometimes making a small modification to a large code…
Indeed, this is part of the reason the generics have been so long in coming to Go; you can find discussions about how to implement them as far back as 2009. One of the reasons they aren't using `` to indicate them is specifically because it drastically changes the speed of parsing (since you would need to figure out whether that `I can't find the reference right now, but there was a quote in one of the early discussions that was something like:
The Generic Paradox is this: You can have slow programmers (no generics; programmers have to do their own code duplication), slow executables (where you do loads of unboxing), or slow compile times.
EDIT: Found the reference; the exact quote is: "The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times?" [1]
The Golang generics proposal was specifically designed to try to reduce the "slow programmers" effect while avoiding either of the other two effects as much as possible.
IMO the biggest factors for the success of Go are 1) super-fast compile times, 2) easy to interpret compiler errors, and 3) dead simple shipment of high performance, native static binaries. I think Go has succeeded, despite, not because of the language itself. One very big limitation being the lack of generics or any sort of ability to leverage higher-order types. Sometimes making a small modification to a large code…
> Scala, Haskell, even Typescript have painful compile times. Can’t speak to the first two, but in some places TS has pathological compile times when you’re trying to give more information to the compiler . A recent example is trying to appease type inference on a set of generics where a wrapped function couldn’t narrow types from its wrapper even though they were totally valid but mostly inferred. I wrote a type gua…
This will probably be downvoted, but I personally never felt a huge need for generics. C doesn't have them and is arguably the most successful language in history. Yes, they are convenient, but they also add a lot of complexity to the language and toolchain. I suspect that this proposal being accepted is largely due to the huge growth of the Go community - I bet the original team (in particular, I'm thinking of Rob P…
> C doesn't have them and is arguably the most successful language in history. And many C programs just emulate them using crazy macros, that are harder to write and are less typesafe than proper generics.
I really wish they went with angle brackets like everyone else does. I get the argument about not wanting to break existing parsers but this is a significant enough language change to warrant that.
Nim, CLU, Eiffel and Scala use square brackets. D, Modula-3 and Ada use parenthesis. ML based languages use quoted letters. There is no everyone else.
I have gone into more detail about why I don't like the square brackets notation for generics to one of the other replies so I wont reiterate myself here and simply suggest you read the replies before commenting.
"We don't need generics" "We don't need exceptions" "We don't need ORMs"
2 out of 3 right ain't bad. We really don't need ORMs
That's great, until you realize you have an actual product to build.