17 ms·
Go 1.18 Beta 1 is available, with generics
- quantum_state 5y agoNice!
- akmittal 5y agoMore than being able to use it I am happy others will stop making jokes about Go
- dgellow 5y agoNo more complaining about lack of generics, yeah! But you will still have people complaining about error handling in every single discussion about Go
- rob74 5y agoPeople who are looking for reasons to complain will always find more than enough - in Go and any other language too...
- throwaway894345 5y agoI guarantee we will still hear about how long it took them to add generics to the language and how the language is only popular because of “massive Google marketing campaigns” and how the language is “stuck in 1970” and so on for years to come. People who make silly criticisms aren’t likely to be pacified, and I don’t think generics will make people less upset that Go is eating into their language’s marketshare.
- lowmagnet 5y agoI've been using Go since maybe 1.4 and that's only 7 years ago. I started using it as my main language around 2016 or so. I knew people complained about generics and wanted them myself, but the ease of using this language have far outweighed any complaints I've ever had about generics or comma-error or comma-ok patterns that have evolved out of the core design. I would love some of the proposals surrounding errors to move forward, of course. But I'm OK with the current state, and will be happier with 1.18.
- latchkey 5y agoOk then... how about something easier... for bar := range list { }
- Joker_vD 5y agoAnd of course "list" is defined as []int, so you get really peculiar results.
- latchkey 5y agoMy all time favorite. https://golang.org/doc/faq#closures_and_goroutines https://golang.org/doc/faq#closures_and_goroutines
- amelius 5y agoThis caveat exists in every language that supports closures, afaict.
- 5e92cb50239222b 5y agoSome… cough… oxidized languages prevent you from doing stupid shit like that. But apparently those languages are too complicated, I'd rather not rely on compiler helping me and keep yet another rule in my head as I'm writing code.
- heheheheheeh 5y agoEven if it didnt, I'm sure you'd be able to realize your mistake while you wait 6-8 weeks for you code to compile.
- roblabla 5y agoErr, no? Most languages will make a copy for scalar values (e.g. ints), e.g. Javascript and python do that. C++ and Rust go further and provide the user the ability to take the arguments by value or reference, even for classes/structs, which gives you control over what you want. And in this specific case, `v` should be a new instance for each iteration really, it makes very little sense to say that a reference to v of a previous iteration of the loop stays alive for the next iteration. Which is why the program as it exists would be a compile time error in rust, for instance (Maybe in C++ as well, I'm not well-versed enough in the lambda rules of C++).
- jhgb 5y agoWhat does this have to do with values or references? They are orthogonal to scopes, and this example is an issue of scoping. A closure finds free variables in one of its enclosing scopes. If the for loop creates one mutable binding for its control variable, even multiple closures created within the loop's body can all see this single mutable binding because they all share the single environment with this mutable binding in which all of them were created, so they can all observe this binding mutating over time. There are no "arguments by value or reference" because the closure in the example is nullary -- it has no arguments at all.
- SPBS 5y agoWait til they find out that methods cannot introduce generic parameters. I predict that complaints will shift from ‘no generics’ to ‘no generic methods’.
- Debug_Overload 5y ago>will stop making jokes about Go If you seriously think that's gonna happen, you haven't been to Go mockery stations on the interweb.
- rad_gruchalski 5y agoWhy does one get bothered with that argument anyway? If it works, it works. People who complain are the people who have a problem. But it’s a different problem and they don’t realise that.
- usrbinbash 5y agoAgreed. There are only 2 kinds of languages: Those people complain about, and those nobody cares about.
- friedman23 5y agoWe wont
- tomjen3 5y agoThere are languages people don't complain about and languages that people use. For me, Go is essentially pointless without generics and better error handling (I love that there are no exceptions, but since 99% of the code just return the error anyway, that needs to be the default path), but even with it, it is not much more than C with garbage collection, a few nice features and better syntax in some cases. So even if it got these problems solved well, I still don't really think I would be using it.
- yannoninator 5y agoA better xmas present than anything I've ever received. bravo!
- dragandj 5y agoSo now it turns out that generics are good?
- rob74 5y agoThe Go team's stance on generics has never been "generics = bad", but "generics have advantages and disadvantages, and if we find an implementation which finds a good compromise between the advantages and disadvantages, we will do it". Which they now did. Let's hope it really turns out to be a good compromise...
- zerr 5y agoIt was due to the arrogance and incompetence of a couple of ex-AT&T authorities in the team.
- hu3 5y agoIs there a source for that? I ask because instances I read from the team were in the direction of: "We will gather enough use cases to decide on the matter".
- gadflyinyoureye 5y agoWhile the GP was a bit...harsh, the main reason people have that view is generics, as a problem space, were solved. Java's way was published years ago. As was .NET's. Other languages exist which have some form generics. The argument of "gather enough use cases to decide on the matter" feels like a punt given the use cases already exist and were known in the industry for the past 30 years.
- hu3 5y agoPerhaps. But in hindsight, Go's generics implementation turned different enough to warrant benefit of the doubt in my opinion. A notable difference is that Go interfaces are implicit while C# and Java are explicit and that affects Go generics.
- mfrw 5y agoA quick[0] 13min video on generics by Ian Lance Taylor. [0]: https://www.youtube.com/watch?v=nr8EpUO9jhw https://www.youtube.com/watch?v=nr8EpUO9jhw
- e12e 5y agoThank you. I'm not a gopher - but shouldn't code-gen be mentioned as an alternative too? Or is that used for something else?
- zerr 5y agoI hope the next big thing is a proper error handling instead of if-hell.
- lowmagnet 5y agoThis is the biggest complaint after generics, and there are a few proposals to dynamically resolve it in either libraries or language features. These proposals are in the go2drafts section, but keep in mind that this is where generics were originally placed on the timeline. Yet here we are with a backward-compatible change to the language in the sub-2.0 version of the language.
- 5e92cb50239222b 5y agoGive it 20 more years of evolution (considering we're talking about Go, probably 70 years), and we get another C++. A Google of the future (let's call it Scroogle) starts another language that can be used by recent graduates that have no idea about what they're doing to write mountains of JSON fiddling boilerplate. Rinse and repeat.
- nauticacom 5y agoHey, don't be so pessimistic. We'll probably have another serialization protocol by then.
- Cthulhu_ 5y agoThere was a spurt of this before they seriously went to work on generics, and the conclusion was "actually, it's fine the way it is". There's huge discussions on the matter as well as various proposals, but they all came with caveats that, in the end, weren't considered a significant improvement. That said, with generics, it should be possible to change to the 'Either' style [0] of error handling. And with another compiler feature to be added, er, 'exhaustive switch/case' or whatever you want to call it, they can make it a compiler error to not handle the error case. That said, I don't see the language developers or community making it a standard anytime soon. The current style of error handling doesn't hurt enough. It's verbose and repetitive, sure, but if the alternative is something clever or magic, it's not the way to go. [0] https://www.scala-lang.org/api/2.13.6/scala/util/Either.html https://www.scala-lang.org/api/2.13.6/scala/util/Either.html
- ianpurton 5y agoIt's not enough. As a rust guy I get way more features in the language that help me write error free software.
- Cthulhu_ 5y agoNobody is pushing you to use Go. Nobody is telling you Rust is bad. There is no language war. It's not an either/or. Stick with Rust if you're happy with it, nobody is attacking you over it.
- afr0ck 5y agoSo, for you, it won't be enough until Go (and possibly every other language that is different from Rust) is "rustified" and turned into a rust-like clone? ... just why? And BTW, Go is very safe! it has automatic memory management, and managed concurrency for writing bug-free concurrent code.
- mfrw 5y agoAs person who uses both Rust & Go at my $DAYJOB, I would say, both have their merits and demerits, I think, we should view them as tools instead of attaching ourselves to any particular language emotionally. I like to think them as different tools for different use-cases. Use the right tool for the right job. In my opinion, go does an excellent job at networking (TLS/HTTP) & quick cli apps while rust shreds text & does an amazing job at memory management (this is a figurative example; don't drone me if I missed your favorite feature).
- dmart 5y agoI often see people recommend Go for CLI apps but I'm not sure why. The built-in `flag` package is really limiting. These days I mostly use Rust with `clap` which is the nicest flag-parsing experience I've found so far in any language.
- alain_gilbert 5y agoAre you using "clap" because the "built-in" one in rust is not good? :P
- FlyingSnake 5y agoThere are 2 kinds of languages, one that people love to talk about and philosophize about and others that are used in real projects. Golang firmly fits into the 2nd category of languages that are highly opinionated and full of pragmatic choices. It is rare for a language to capture so much mindshare within a decade of it's launch and I'm glad that Go had managed to reach this stage. I am really looking forward to what this new era of Golang brings with it.
- Cthulhu_ 5y agoI'd add to your first category that there's a lot of languages that adopt features that other languages have, making a ton of languages converge into basically the same language with some caveats. I don't remember the post now but I believe it was posted on HN some time ago, it was pretty insightful. Anyway yeah, I'm glad Go is resistant to change.
- jerf 5y agohttp://www.jerf.org/iri/post/2908 http://www.jerf.org/iri/post/2908 ? (BTW, 2011 on that. I would not today agree with the statement "the Haskell community is the only community I know that is doing new things in the field of language and API design". I think Rust is doing interesting new things now. In 2011 they were still working on basic functionality. There's a couple of other interesting little up-and-coming languages.)
- rob74 5y agoNo idea why you are getting downvoted, but I fully agree with that sentiment. There are already enough open source languages who seemingly want to be "everybody's darling" and implement any reasonably sensible feature request. One example: PHP's new "match" expression (https://www.php.net/manual/en/control-structures.match.php https://www.php.net/manual/en/control-structures.match.php). Of course, I can understand that people like Go's more flexible "switch" better than the "traditional" C-style one, but if a language already has the traditional version, does it really have to add a new one which does mostly the same thing and in doing so cause headaches for thousands of developers who use classes or constants named "match"?
- 1_player 5y agoGo with generics has definitely surpassed Python for me. Python is good for prototyping but the package management story and the "feel" of the language has ruined it for me. I used to love Python, until I used Django professionally, and the façade crumbled. I'm done with OOP and dynamic typing. Go felt good, a bit verbose, but my issue was that map/reduce/filter are a much better abstraction over imperative loops, and with generics, the dream of Go with more functional and high-level concepts is closer. This comment is going to be very controversial, so let me remind you this is my very own opinion.
- Cthulhu_ 5y agoNote that you still shouldn't use Go as a functional language (using map/reduce/filter); it's not optimized for functional programming, and the syntax would be pretty gnarly. A for-loop has what's called "mechanical sympathy", and will go through things in the order that it is in memory. It'll allow the compiler and runtime to manage things quickly through memory, CPU registers, and CPU pipelines. A great post on the subject is "Why Go Getting Generics Will Not Change Idiomatic Go": http://www.jerf.org/iri/post/2955 http://www.jerf.org/iri/post/2955
- lucian1900 5y agoThe bit about "mechanical sympathy" is wrong, though. Plenty of languages inline map/reduce or iterator type code down to very efficient cache-friendly traversal of memory, most notably Rust. Go's compiler is just particularly naive.
- mananaysiempre 5y ago(The key phrase is “stream fusion”.)
- kortex 5y agoActually I think while the compiler is a bit naive, the compiler writers are not. They are striving for simplicity, maintainability, speed, etc., vs trying to optimize high-level FP-esque idioms into fast machine code. The compiler has definitely gotten more optimal over the years, but it's a different beastie than the rust one. Because go is not rust.
- neillyons 5y agoCool. Does anyone know of libraries that are using Go generics yet?
- flippinburgers 5y agoNever needed in my opinion but here we go...
- _j_jonas_2231 5y agoNot needed, but good to have. I've immediatly installed Go 1.18 yesterday and created a generic stack, tree and set with corresponding methods for traversal or union, intersect, ... it makes live easier.
- honkycat 5y agoI'm going to start writing functional Golang and none of you can stop me
- laerus 5y ago> The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.