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.<p>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 codebase can require a huge footprint of lines modified, just because so much code winds up duplicated in slightly different contexts.<p>That being said, I really hope that Go's core team understands the drivers of its popularity and doesn't compromise the operational side for the sake of language improvements. Although higher-typed languages have no trouble achieving good runtime performance, it seems like there's a fundamental tradeoff at compile time. Scala, Haskell, even Typescript have painful compile times. I don't know if there's any theoretical reason for it to hold, but more typing complexity inevitably leads to slow compile times.<p>And as for the topic of clear error messages, the higher-typed languages are all atrocious at this. Even templates in C++ are notorious for puking near impossible to decipher errors. This is something I'm sure can be fixed with enough engineering effort, but it would probably take <i>a lot</i> of effort to get there.<p>In general, I bitch about the Go language all the time. But I think we should recognize that the simplicity of the language gives us developers a lot of peripheral really nice usability benefits.
This was to be expected. But I'm glad for Go.<p>In some years a language that interops with Go comes out, where all the Go types have a ?-suffix indicating they are nullable. The language will be mostly null-safe. Also it will sport sumtypes and pattern matching/ destructuring in switch statements.<p>It will be called: Gotlin.
This is a significant milestone for Go, and I'm extremely happy for the community. I didn't imagine getting here when I first started using the language, and yet here we are.<p>Special props to Ian Lance Taylor and Robert Griesemer for their continued revisions of drafts, and exemplary discussion with the community in implementing feedback.
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. ;)
A few days ago: <a href="https://news.ycombinator.com/item?id=26018649" rel="nofollow">https://news.ycombinator.com/item?id=26018649</a><p>A few weeks ago: <a href="https://news.ycombinator.com/item?id=25750582" rel="nofollow">https://news.ycombinator.com/item?id=25750582</a>
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 Pike) are at best ambivalent about this proposal and were outvoted.<p>Personally, the proposal I was most excited about was to make ints be arbitrary precision by default. As someone who does a lot of math, this would have made Go much easier for me to use. Sadly, this proposal was scrapped a while back.
I wonder if over time, Golang will pick up more type features like Java and other languages have.<p>The general consensus seems to be that powerful type systems are very effective.<p>Personally, the low footprint runtime and concurrency primitives are enough for me and I wouldn't mind the language becoming "less simple" if it helps the ecosystem.<p>Once generics are implemented, I can imagine people requesting for the next "missing" thing.
I really really hope that this does not end up in people abusing generics in Golang code and making Golang code harder to read. The biggest argument of Golang in my opinion is that it is extremely easy to audit and read and understand at the moment.
I'm kind of sad that they didn't allow you to use inuktitut characters as a joke about this classic comment.<p><a href="https://www.reddit.com/r/rust/comments/5penft/parallelizing_enjarify_in_go_and_rust/dcsgk7n/" rel="nofollow">https://www.reddit.com/r/rust/comments/5penft/parallelizing_...</a>
Very much excited that this is finally moving forward. Such sweet improvements this will allow for SciPipe and FlowBase when this nears completion [1,2].<p>It will make it so much easier to enable typed port objects, which can still re-use all the handy functionality for connecting inports/outports, traversing the dataflow graph, etc etc.<p>[1] <a href="https://scipipe.org" rel="nofollow">https://scipipe.org</a><p>[2] i<a href="https://flowbase.org" rel="nofollow">https://flowbase.org</a>
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.