97 ms·

Go 1.18

773 points by mjlee 5y ago

mjlee 5y ago
Release notes are here: https://go.dev/doc/go1.18 https://go.dev/doc/go1.18
- Jolter 5y ago
  This should be the posted link instead of the OP, IMO.
philosopher1234 5y ago
This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the language design, but I suspect that doesn't account for all of it. It seems to me that the intensity with which some people fixated on the absence of generics cannot be explained just by frustration with writing non-generic code, which by all accounts was annoying but not overwhelmingly so. So, for those of you who are willing to explore the part of this that goes beyond a simple rational analysis and criticism of language design, whats bugging you? Sometimes I think the core irritation with Go is its simplicity. The suggestion that easy to learn languages can be effective too is somewhat humiliating, as we get attached to the pride of mastering more complex languages, and the suggestion is that some of the struggling we went through was unnecessary, and that folks who wont struggle as much might be able to be effective too, in fact the suggestion is that maybe our pride was misplaced. Theres also a suggestion, in the fact that Go has opinions, that other opinions might be "wrong". I think this may bug people, who would take up those other opinions or see merit in them, a lot. There's also a bit of an anti-expertise "who are you, Go creators, to say you know better than me how to design this program/engage in software development?" In any case, it's something I've been trying to figure out for a while and I don't think I have a complete explanation still. Curious to see what others think.
- deleted 5y ago
  [deleted]
- icholy 5y ago
  People are upset that their favourite language didn't get as popular as Go.
  - echelon 5y ago
    Counter point: Generics make me far more inclined to use Go regularly. If error handling is improved to be safer and more ergonomic, it'll be incredibly compelling for me. Generics were the biggest feature keeping me from using the language, and now that's a done deal. I'm excited.
    - icholy 5y ago
      If you consider the adoption rate, it's pretty clear that the people who avoid Go because of <insert missing feature> are a vocal minority.
      - echelon 5y ago
        Well, I can only speak for myself :)
      - mcronce 5y ago
        While true, that doesn't really change the situation for the individuals who require <missing feature>
        throwaway894345 5y ago
        No one meaningfully "requires generics", people are just reluctant to set their ego aside and learn a different approach. Some use cases may benefit from generics, but even then "require" is too strong.
        5y ago
honkycat 5y ago
WOOO! I have been using the RC at work lately, and I have to say: The generics implementation is quite nice, and RUTHLESSLY slashes boilerplate and copy-pasta. This is going to turn Golang from "that one boilerplate-y language without generics" into my favorite language. I've been using the https://github.com/samber/lo https://github.com/samber/lo library, and it is very nice to be able to do "map/reduce/etc..." on golang structs. I would really enjoy a chaining library, and some tooling to make type coersion a bit cleaner.
- aston 5y ago
  You might like Go-Chainable: https://github.com/neurocollective/go_chainable https://github.com/neurocollective/go_chainable
- earthboundkid 5y ago
  I find that the function boilerplate of Go is too long because there's no equivalent of an arrow func. I can't see those kind of libraries taking off until there's an easier way to write a closure.
- edenlinger 5y ago
  I don't mean to disparage the wonderful work of the lo developers but, this is in many ways what I feared generics would bring. If you aren't going to lean into the simplicity and single way of doing something, you are likely better served in another language. I am probably an old man yelling at clouds and I hope those who like this style get tons of value from it. I just don't see the benefit of trying to retrofit some of the behavior of other perfectly useful languages into Go. JS/Java/C#/Python/Ruby is a fine language. Let each of them have their strengths. I feel like trying to bolt things together this way only serves to take away what is special and valuable in Go. I should probably shut up and just be happy lots of other people are using a language I enjoy :)
  - kortex 5y ago
    > I don't mean to disparage the wonderful work of the lo developers but, > this is in many ways what I feared generics would bring. What is, anything in particular about that "lo" library? Just the way it uses generics, or moreso that it's yet another library to learn to be effective? Can't argue with the latter, but as far as the former goes, I think that looks quite reasonable. It's very explicit, there's no magic going on. I think there's definitely a bar for "so much abstraction that it is discouraging to developers not into that sort of thing", and IMHO that doesn't cross it. Monads, sure, that's a tall order for many folks. But this is pretty tame. But I am a fan of abstraction so I'm not the best judge.
earthboundkid 5y ago
Now Go sucks because there are too many generics.
pjmlp 5y ago
Finally generics support. Now another 10 years for proper enums. Kidding, I always mentioned that CLU like would be good enough.
- bsaul 5y ago
  I’m surprised go didn’t add real enums before generics. This seemed to be much more orthogonal to the type system, and blend well with the language. I guess there was caveat i’m not aware of.
  - pjmlp 5y ago
    It is another thing that original team isn't found of. Rob Pike has some posts on gonuts where he asserts the current approach is good enough.
didip 5y ago
Generics!!! I can't wait for all the different data structure libraries to embrace it. It will make Go adoption in Data Science use-case easier.
- leetrout 5y ago
  Some speculation it will allow for better ORMs as well...
- mrtranscendence 5y ago
  I don’t see Go ever making headway in data science. For one, it’s not fast enough to implement algorithms directly but lacks a decent FFI; it would be burdensome to create the metric ton of new libraries that would have to be put into place. And there are Python libraries for basically everything already, from numeric computing to Bayesian time series to Spark to Torch and TensorFlow. Plus Go’s kind of weird, relative to the languages that many data scientists have experience with. Maybe I’m being unfair, though.
  - IshKebab 5y ago
    Go is definitely fast enough to do data science.
    - mrtranscendence 5y ago
      Sure, it’s much faster than Python, agreed. But is it fast enough to implement highly optimized numerical algorithms in a way that can compete with Fortran or C? That I’m not so sure of, and if not you’re stuck with the crappy FFI.
      - IshKebab 5y ago
        Unless you need the last 10% of performance, yes it is. You can also use assembly directly from Go if you need bleeding edge speed.
        5y ago
sambeau 5y ago
LET THE REWRITING BEGIN!…
johndfsgdgdfg 5y ago
- seanw444 5y ago
  This has to be satire.
- IceWreck 5y ago
  So switch from one corp to the other ? Thats one extremely biased view. Use whatever you like, theyre all open source.
slicedbrandy 5y ago
Now time to update interface{} usage and shift to any. $ gofmt -r 'interface{} -> any' -l **/*.go Replace -l with -w to write.
- rpk788 5y ago
  well there goes my Hacktoberfest idea
- eatonphil 5y ago
  Is there an actual difference between these or is it just aesthetic? (and shorter)
  - xiaq 5y ago
    any is an alias of interface{}, so purely aesthetic.
candiddevmike 5y ago
Personally, I'm waiting until 1.19 to start seriously exploring generics. By then, the dust will have settled a bit, folks will have some good lessons learned to share, and there may be more packages in the stdlib for generics.
- ainar-g 5y ago
  I feel like a lot of people will wait (although perhaps not up until 1.19) for the simple reason that tooling support is still not quite there yet. See [1] and the related issues. Static code analysis is reasonably popular in Go projects, and just disabling all failing tools until the tooling is there is not something most people would agree to, I think. With that said, of the tools that I use about ⅔ are already reasonably compatible. Unfortunately, the other ⅓ are among the most essential ones. [1]: https://github.com/golang/go/issues/48525 https://github.com/golang/go/issues/48525
- bashery 5y ago
  +1
  - thegeekpirate 5y ago
    Please stop posting this on every comment you agree with, as you're not adding anything useful to the discussion, while also sending alerts to people for no good reason. Click on the upvote button instead.
mseepgood 5y ago
Why post this useless Github link instead of the release notes or the blog post?
- anthropodie 5y ago
  yes @dang please re-link this post to https://go.dev/doc/go1.18 https://go.dev/doc/go1.18
  - hi41 5y ago
    That’s a cool feature you used there. I didn’t know you could use the at-the-rate symbol to reference a hn user and call his attention! Very nice!
    - tptacek 5y ago
      It's not a feature, and it's not a good idea to refer to people with @nicks, because Twitter's @name convention is much stronger and the two don't overlap perfectly (I am not, for instance, @tptacek on Twitter). I use 'nick to refer to people here, in keeping with our lispy ethos, but really anything other than @nick is fine.
      - whimsicalism 5y ago
        I would not assume any "@" is referring to a twitter user, it is common across a number of apps (not to mention, IRC)
        opan 5y ago
        It's worth noting that on IRC it refers to someone being an op, and that it's not used for pinging people. (I sometimes see people who are used to other chats put the @ at the start of an IRC message)
        kadoban 5y ago
        On IRC, typical protocol is to just use people's nickname, with a colon after it if you're replying specifically to them. "@" is uncommon for tagging people.
justinsaccount 5y ago
Generics is the big news, but the fuzzing support is amazing too. I added a fuzz test to an app I have in about 5 minutes. It was no harder than adding a normal test. I expect to see a huge boon in users of fuzzing techniques which will benefit projects across the board.
- staticassertion 5y ago
  I'm very happy to see fuzzing added to Go, and I don't write Go at all (or every plan to). Bringing concepts like this to the masses is a win for everybody.
- sneak 5y ago
  Link to the diff? I always learn better by concrete example than by docs.
  - nwsm 5y ago
    The docs have concrete examples if you want- https://go.dev/doc/tutorial/fuzz https://go.dev/doc/tutorial/fuzz
- 2OEH8eoCRo0 5y ago
  Nobody at my work has even heard of fuzzing and thought I was making it up. I'm glad senior SWEs are paid so much to keep up with the industry. /s
  - movedx 5y ago
    I don't consider those kinds of people engineers at all. They're people who have learned a syntax, some patterns and, thanks to their human brain, can adopt it slightly to certain situations. But they're not engineers. Engineers constantly ask why, explore the unknown and are aware of almost all possible solutions available to them. using this knowledge they select the correct tools and build the solution. What you've described are skilled labourers. I'm harsh with my judgement because I believe our industry has a lot of "statically minded" individuals who stay in their lane, never going outside their boxes, to explore what else is out there to help them solves the engineering problems they're faced with... and it's pissing me off :)
AaronFriel 5y ago
My favorite feature is a tiny, couple line bug fix that I pushed hard to get included during the feature freeze. Full details here, but a summary is below: https://github.com/golang/go/issues/51127 https://github.com/golang/go/issues/51127 For the past ~8 years, many hundreds of people reported on GitHub - and likely many multiples more have encountered and not reported - a program that didn't work with the error "cannot unmarshal DNS..." This error seems to be caused by two things: 1. DNS proxies not adhering to the DNS spec. This would be due to VPNs with integrated DNS proxies such as Cisco AnyConnect, internet connection sharing on Windows (which affects DNS resolution in the Windows Subsystem for Linux), or even just incorrectly implemented recursive resolvers. Specifically, if these servers receive a DNS message that utilizes RFC 1035, section 4.1.4 "message compression", which is an extremely simple compression scheme, then they may transmit a DNS message that doesn't utilize message compression, which means the proxy isn't in response size 1:1 but almost always increases the size of DNS responses. 2. Go's net/dns resolver enforcing a strict 512 byte limit on responses. This is the same behavior as musl (and I would implore a musl maintainer to increase this limit) but not in glibc or most OS distributions' default DNS behavior. I read every single GitHub issue related to this and found the frustration of both end-users and OSS software maintainers overwhelming. End users lacked the tools to diagnose why the software didn't work, maintainers couldn't reproduce the issue. This bug affected major projects: Mesos, Docker, Consul, Terraform, and more. For nearly a decade. Sometimes (as in Mesos) these were projects where they controlled the DNS server and client, so they could implement DNS message compression and solve it. In other cases, such as with Docker or Pulumi, where software runs on end-user machines, maintainers may have had to "close, can't repro" issues. The error was inscrutable and otherwise very skilled maintainers wrote this off as a fluke or user error. And these are just the tools that are typically used by skilled technical users - usually engineers. It's hard to estimate but not difficult to imagine underestimating how many bug reports and issues end-users encountered where a cryptic error message, if shown, never made its way to GitHub. Software that works is better than software that - sometimes cryptically - does not. And when things just work, well, very few people using Go will realize that this fix prevented them from experiencing an afternoon or a day or more of frustration; but I will :) and I think that's what makes contributing to OSS awesome.
- tedunangst 5y ago
leetrout 5y ago
Hooray! Couple quality of life improvements to embedded filesystems... you can now use files that start with an underscore :D
henvic 5y ago
Tip: If you've only heard about generics, make sure to check out about fuzzing (*testing.F)!
- meetups323 5y ago
  Any idea why they have such a low byte budget? testing.Fuzz would be so much more readable. I'll accept test.Fuzz if 9 characters is the limit for any compound identifier. Is this sort of single letter class naming common in the standard library?
  - unfunco 5y ago
    Not in the standard library in general, but in the testing package it's the convention. There's testing.B, testing.M, testing.T, and testing.F, and *testing.TB. https://pkg.go.dev/testing#pkg-types https://pkg.go.dev/testing#pkg-types
    - meetups323 5y ago
      Well that's a hard pass from me. I always knew go was quick to compile, I didn't know the lengths they were willing to go to achieve that! Case in point: it's not TB, as you stated, but rather PB.
      - joshuamorton 5y ago
        There's both, TestBase and ParallelBenchmark.
        IshKebab 5y ago
        He's still right about that. Ridiculous naming. Fortunately the rest of Go uses sensible names so I think it would be silly to avoid Go just because of that.
  - gvil 5y ago
    it's super common everywhere, also in third party libraries (`bson.M` is what exactly?). it's one of the reasons that makes go a very displeasing language to work with.
Shadonototra 5y ago
Why not link the announcement? https://tip.golang.org/blog/go1.18 https://tip.golang.org/blog/go1.18 Who cares about the tag What's up mods? @dang yo
_0w8t 5y ago
For me the most puzzling aspect of Go is channels. Ada tried CSP (Concurrent Sequential Processes that Go channels are based on) in eighties and people quickly realized that it lead to bad performance and was unsuitable for a lot of useful cases. So Ada got standard mutexes and signals. So why CSP which does not allow to implement priority delivery or multicasting and makes cancelling much harder compared with normal polymorphic message queue per thread? Moreover, Go crippled CSP even further as one cannot select on channel and file descriptor. Fortunately Go does provide mutexes and signals so one can ignore channels unless required by Go API. Still without proper sum types polymorphic and type-safe message queues are not possible.
- pkulak 5y ago
  I can never seem to understand why a GCed language has pointers, and makes you memorize when to use stack vs heap.
  - mftb 5y ago
    It's pretty straightforward, knowing when to use the stack vs heap can improve your performance. Having both paradigms available in the language means you can start out relying on the GC for everything. Later when you're ready, you can look to make more intelligent use of the stack.
    - bashery 5y ago
      +1
  - hnov 5y ago
    I think it's at least partially about value vs (mutable) reference semantics in Golang's case and the hope is that the compiler will know to whether heap or stack allocate based on escape analysis.
  - Laremere 5y ago
    Go uses escape analysis to ensure memory safety of pointers. Taking a reference of a local variable means it might end up on the heap, and calling new might allocate on the stack. It all depends on if Go can determine that the lifetime of the pointers is less than the stack frame. It's good if you don't want to care about those details, it's bad if you really care about those details for performance reasons.
cube2222 5y ago
Great to see this! Generics will drastically improve datastructure libraries. That said, for people worrying about overcomplication, fortunately methods can't have type parameters. That means ergonomic monads are not possible to implement, and we'll most probably not see the whole functional story play out in Go.
- ed25519FUUU 5y ago
  Plenty of great functional alternatives to Go.
  - cube2222 5y ago
    Definitely! I'd be worried though that functional developers coming to Go (for whatever reason) would try to write Go functionally. That will fortunately be very hard thanks to this limitation. Nothing specific against functional programming per-se, but as you said, Go's not the language for it.
  - zinclozenge 5y ago
    None with the same performance characteristics, ease of use, and ecosystem size. I'm reasonably competent with Rust, but sometimes I don't want to bash my head against the borrow checker or litter my code with copy/clone. Go hits a nice sweet spot, my main quibbles are that there's no native iterators/comprehensions or sum types with compiler checked exhaustive matching. With generics we can get libraries that allow for more functional style programming, and golangci-lint has a linter for exhaustiveness.
    - kaba0 5y ago
      Scala is pretty close to Go in terms of popularity and I would argue that it has a much bigger ecosystem due to the JVM. It is also pretty much a typed python in terms of ease of use, and the JVM has stellar performance — other than small running scripts, for many kind of workloads Java’s state of the art GC will have better throughput than Go’s.
mseepgood 5y ago
Now Go has everything I need in a programming language!
- drdaeman 5y ago
  Not for me. There is no ?: ternary operator. Having to write 6 additional lines of code for each tiny conditional sucks. It's not frequent, I think I've only had a single case in a few years where I had difficulty working around, but when it happens - it's not fun. err := h(cond(x) ? f(x) : g(x)) vs var temp T if cond(x) { temp = f(x) } else { temp = g(x) } err := h(temp) Hopefully, this can be improved with generics, e.g. now it should be possible to create e.g. `func Coalesce (type T) (...args T) T` function to simplify common scenarios.
  - crtc 5y ago
    This is by design: https://go.dev/doc/faq#Does_Go_have_a_ternary_form https://go.dev/doc/faq#Does_Go_have_a_ternary_form Ken Thompson added ?: to B / C and then he took it from us in Go due to the wisdom he gathered in between.
    - RodgerTheGreat 5y ago
      > A language needs only one conditional control flow construct. And yet, Go has a switch statement.
      - MrDOS 5y ago
        Not only that, but despite all of the other syntactic sugar Go is lacking (usually sorely, such as a “try” error handler), the switch statement is really just an “if” statement in disguise. var someVar, anotherVar string // ... switch { case someVar == "whatever": fmt.Println("Tell me how, exactly,") case anotherVar == "nope": fmt.Println("this compiles to a jump table?") default: fmt.Println("Spoiler: it doesn't.") }
        5y ago
crtc 5y ago
Finally! This will be the last day I see the words "Go" "lack of"/"no" and "generics" in one sentence.
- esprehn 5y ago
  That'll have to wait until the next release when the standard library gets updated... But soon!
- uluyol 5y ago
  I'm sure you'll see plenty of comments saying "Go generics lack support for X". Just ignore them — some people seem to have nothing better to do.
- HideousKojima 5y ago
  I mean in Java vs. C# fights people still bring up that C# generics are reified while Java generics rely on casting and erase type information at runtime, so probably not.
  - int_19h 5y ago
    Go dodged that bullet by reifying theirs!
oxplot 5y ago
When you hear most critics of Go (or any language for that matter), they talk as if Go is merely an alternative syntax for their favorite language. Of course they're bothered by lack of a missing features and unfamiliar ways. As tired of an analogy as it may be, programming languages are like natural languages. Trying to learn Japanese by translating sentences, idioms and proverbs from English word for word will only end in frustration and confusion. If you read the history of Go, the whole point behind its creation (as with many others) was to start with a clean slate so new norms and ways of doing things could form, in service of large distributed teams and long term maintainability. Lack of generics, as unrelated as it may seem, is actually the result of the those and other goals. Specifically, Go authors avoided complicating the language, runtime, and compiler early on and thereby avoided negatively affecting long term maintainability of both the language and the code written for it (v1 compatibility promise) before having a good grasp of how generics should be implemented in this new language or if it should be at all. Copying the so called tried and tested implementations from existing languages would make little sense as generics are so intertwined with the rest of a language. TL;DR approach learning programming languages like you would approach learning a new natural language with the purpose of living among its native speakers.
- pie_flavor 5y ago
  Certainly a better take than 'I don't like generics, it's somehow less complicated to downcast interface{} everywhere'. It was very interesting reading the justification for not having generic methods, and how that clashed with my assumption of what generics should be, or for that matter what methods should be. Go is the spiritual successor to C, IMO - for all that people use it nowadays for its low-level capability, people forget that its original purpose was to do what every other language of its day did, but way, way more simply.
- int_19h 5y ago
  Most critics of Go are well aware of its history and purported design goals. The problem is that the set of features that actually are in Go (like channels) versus those that weren't (like generics) or still aren't (like enums) doesn't really make sense when taking those design goals at face value. For example, generics. Like you say, the original claim was that they didn't want to do them because they thought that more time is needed to figure out how to do them "right". And so they waited for a decade, and ended up implementing them in a way that's not fundamentally different from most other languages that had them all along. What, exactly, was gained here to justify the productivity lost while waiting? I will also add that to someone who knows a few PLs, Go is a very boring language in a sense that there's very little new there, neither in terms of individual parts, nor in terms of how they're combined together. So the notion that this combination is somehow so unique that its evolution is like walking on untested ground doesn't pass the smell test.
frenchie4111 5y ago
In celebration of generics release, I was playing around with supporting Optionals via generics. If anyone's interested I am happy to make this a real project https://github.com/frenchie4111/go-generic-optional https://github.com/frenchie4111/go-generic-optional
- Mawr 5y ago
  type Optional[T any] struct { value *T } Don't use a pointer - it's bad for performance. func MakeOptional[T any](value *T) Optional[T] { Use `New` instead - it's the idiomatic name for a constructor in Go. Drop the `Optional` part - the module name suffices - the caller will see: `opt.New`. Personally I just call the module `optional`, I think it's clearer: `optional.New`. func (o* Optional[T]) Unwrap() (T, error) { 1. `Unwrap` reminds me of Rust's .Unwrap, which panics. Seems confusing. 2. There's no error here, the situation is equivalent to a missing key in a map - it's enough to return a bool. Here's my implementation so far: https://gist.github.com/Mawr-BF2/0a60da26f66b82ee87b98b03336e1f84 https://gist.github.com/Mawr-BF2/0a60da26f66b82ee87b98b03336.... Only thing I'm not sure about is whether the JSON serialization methods are necessary.
  - wtfishackernews 5y ago
    For json marshalling, I would defer to the underlying type's marshalling if it's present, and return `null` otherwise.
    - shhsshs 5y ago
      I think this is appropriate in some cases but not others. For example how does the JSON value distinguish between `Some(null)` and `None`?
      - dialogbox 5y ago
        IMO using Optional type means the inner value must be not null. And if it's Some(null), it should mean exactly same as None.
akmittal 5y ago
Hopefully generics will help make better libraries for Graphql. Existing libraries resorted to code generation a lot.
- bogomipz 5y ago
  Interesting. I'm curious how code generation is/was used to work around the language not having having support for generics? Or was this something specific to Graphql?
  - scheme271 5y ago
    The kubernetes api (more specifically the k8s apimachinery) code uses codegen in order to create code so that you can convert custom CRDs to go structures rather than working with json. It's one of the more opaque bits of writing go code that works with k8s.
  - akmittal 5y ago
    gqlgen is most popular for graphql and uses codegen. It seem to be good but It felt not that easy to use coming from node world(apollo-server). There were bunch of libraries which helped with code generation to work around generics. I don't think it was specific to Graphql. https://github.com/cheekybits/genny https://github.com/cheekybits/genny is one I have seen.
- naikrovek 5y ago
  > Existing libraries resorted to code generation a lot. guess what generics is in a lot of languages? code generation! the files just aren't saved to disk. IIRC on a podcast I seem to recall hearing that it was implemented this way for Go, at least for the prototype, and it seems likely to me that it is also done this way in production, but not with textual code.
  - akmittal 5y ago
    Thats like saying lets just write assembly because eventually code will be converted to assembly. As a developer now we dont have to bother about codegen.
haolez 5y ago
I hope open source Go code in the wild remains easy to read and understand. Generics look cool, despite this possible downside.
- rochak 5y ago
  I have already started having trouble understanding open source code using generics. I can see the upsides of having generics, but have lost the enthusiasm with which I used to browse Go code. I am still a junior engineer, so maybe it will get better with time.
  - dgb23 5y ago
    Every abstraction tool will get misused, especially early on. I bet the Go community will figure out how ways to mitigate that in the long run, given it’s culture around readability.
    - int_19h 5y ago
      Also, I think that a lot of supposed "misuse" that people are complaining about is actually using the right tool for the job, and the complaints stem from treating the tool itself as inherently too complicated (and thus any use of it as automatically suspect) because it's new and not conceptually trivial. There was a lot of that back when Java and C# first got their generics.
- chabad360 5y ago
  I've found generic code much easier to read once I started playing with it myself. It might be worth implementing a generic sorter (or some other easily generic construct) just to get more familiar with the new syntax.
deleted 5y ago
[deleted]
exdsq 5y ago
Aaaand now watch every projects abstraction increase tenfold under the weight of generics
- kortex 5y ago
  Or put another way, 1/10th the surface area of code to write, maintain, review, and bug check. And much less interface{} abuse. That's taking "tenfold" at face value. I don't see that happening personally. The go community has enough of a nucleus of devs with a certain mindset that I don't see crazy Haskell levels of abstraction taking over. What I do see is more type safety coming to interface dynamicism.
- avl999 5y ago
  Or an expectation of competence from developers and expecting them to consider tradeoffs of their design- in other words doing their damn jobs as opposed to the language baby sitting them away from tools they might use incorrectly.
  - exdsq 5y ago
    There’s nothing wrong with a language being strict with what you can do to force good programming styles. An expectation of competence is nice if you can afford it, but it’s also nice to have languages that mean you don’t have to take that risk. It’s why I liked Go and why I disliked working in Haskell. Look at Lisp - large teams get tied in knots because of the freedom. Go was nice because it just stopped you doing ‘smart’ things. Now it has generics you may as well use Rust or something else.
    - jatone 5y ago
      having used rust that isn't a sane trade off. rust is a wonderful language but its orders of magnitude slower than go for development.
voakbasda 5y ago
I hope this gets merged into the upcoming Yocto `kirkstone` LTS release branch, since that branch will use the same pinned version for years to come. The previous `dunfell` LTS release branch provided Go 1.14, which can no longer build the latest versions of many projects.
typical182 5y ago
There is also a new set of FAQs on generics: https://go.dev/doc/faq#Type_Parameters https://go.dev/doc/faq#Type_Parameters
- everybodyknows 5y ago
  This is the part anyone writing performance-critical code will find troubling: > The compiler can choose whether to compile each instantiation separately or whether to compile reasonably similar instantiations as a single implementation. ...
gnoack 5y ago
The general excitement about generics on this thread makes me uneasy. Please keep in mind that generics are a pretty big hammer - they can add a lot of complication if not used with caution. Only use a language feature if you absolutely must.
- HideousKojima 5y ago
  I see it the other way around, generics reduce complication and allow for code that's a lot more elegant and simple than without. It definitely adds complexity on the compiler side of things, but using them in C#, TypeScript, and Java has been only a plus. Unless you count that time I tried to do stuff with generic interfaces in Entity Framework Core, but that was EF Core's fault as opposed to generics's.
  - tptacek 5y ago
    As with everything else, sometimes this is true, sometimes it isn't. In languages with pervasive generics, figuring out how things work can mean following several extraneous layers of indirection as any opportunity to parameterize something is always taken. But writing the same stupid loop to delete something from a slice is also unclear and complicated. The point isn't that generics are bad, just that they should be used judiciously.
  - gnoack 5y ago
    ...and that time when people reinvented boolean expressions and their combinatorics under the disguise of Predicate<T> and Matcher<T>, making test errors hard to comprehend for very little additional benefit. etc etc There is also the problem that people don't generally have a good grasp on how to use type bounds[1] correctly... I believe Go avoids the worst of it through its simple type system, but still... this complicates a language significantly. [1] https://docs.oracle.com/javase/tutorial/java/generics/bounded.html https://docs.oracle.com/javase/tutorial/java/generics/bounde...
    - pjmlp 5y ago
      Still better than messing with code generators and template language workarounds.
mikojan 5y ago
I will forever miss old Go :-(
- flippinburgers 5y ago
  Me too.
flippinburgers 5y ago
Honestly I think this will make the overall programming experience worse.
- HideousKojima 5y ago
  In what way? Almost every other major language has them without major issues. Go devs saying generics are a bad thing reminds me of people in Oregon freaking out over being allowed to pump their own gas while the other 49 states have been doing that for decades.
  - jatone 5y ago
    never once was it said by the go devs that generics are bad. it was asserted that generics are complicated to get right and they wanted to take their time.
- pie_flavor 5y ago
  Is it a worse programming experience to understand an esoteric library's use of [T U], or to need to choose between codegen vs interface{} for the most common use cases? The ability to misuse a feature should not be understated, but I think people have been jumping over the missing stair of interface{} for so long that they've forgotten how much of an incredible pain it is.
bborud 5y ago
I really hope people will show restraint.
morelisp 5y ago
strings.Cut / bytes.Cut is really nice.
jadbox 5y ago
Is there a go-to implementation of typed map/reduce/filter with 1.18?
- maxekman 5y ago
  https://pkg.go.dev/golang.org/x/exp/maps https://pkg.go.dev/golang.org/x/exp/maps https://pkg.go.dev/golang.org/x/exp/slices https://pkg.go.dev/golang.org/x/exp/slices https://pkg.go.dev/golang.org/x/exp/constraints https://pkg.go.dev/golang.org/x/exp/constraints
- frenchie4111 5y ago
  Someone started a lodash style stdlib replacement: https://github.com/samber/lo https://github.com/samber/lo
t43562 5y ago
I think about Go with pleasure until I remember importing. The miseries I've experienced with modules - the way imports are satisfied......just so hard to understand. Built-in support for SCM sites like github (yuck!). Just struggling to put code in a place where some other bit of my code can use it. The C/C++ preprocessor is an abortion and go seems to have made something that solves all the problems I had with that but ends up much worse to use.
- ithkuil 5y ago
  My main misery with modules was due to people renaming their GitHub repositories
  - jayd16 5y ago
    Fork them (just make a copy you own) so you have control?
    - ithkuil 5y ago
      Usually my problems are with transitive dependencies. I would have to fork quite a few projects to deal with that. I wish there was a more systematic way to do "replace", possibly in libraries as well
      - thiht 5y ago
        There’s a « replace » directive in go.mod.
        ithkuil 5y ago
        Yeah I know, but it's suboptimal. If you use it your module cannot be "go install" lled, and it doesn't work for libraries
        acchow 5y ago
        Replace in go.mod breaks `go install`?
eatonphil 5y ago
Regarding Windows: while this isn't on scoop yet I was able to get it in Github Actions like so: curl -L -O "https://go.dev/dl/go1.18.windows-amd64.zip" unzip go1.18.windows-amd64.zip Join-Path $pwd "go\bin" >> $Env:GITHUB_PATH A request/suggestion for the Go team: include instructions for how to use the Windows zip! It's not a big deal but I had to figure it out by `ls`-ing around.
dgrr19 5y ago
[dead]
pie_flavor 5y ago
I wish I understood how people can say 'this will result in so much more weird boilerplate garbage code' as it solves a problem that has resulted in an absolutely ludicrous amount of weird boilerplate garbage code. You're not trading off generic code vs non-generic code. Problems are generic. For solving generic problems, you're trading off the generic code that best expresses them, for codegen, dynamic downcasting, or Ctrl-V. The first two are not simpler (in the Go way) than generics, and the third is an antipattern in every programming environment.
- dimgl 5y ago
  Disclaimer: I'm extremely happy that generics are coming to Go. > I wish I understood how people can say 'this will result in so much more weird boilerplate garbage code' It's pretty simple: there's a lot of developers that misuse/shouldn't use generics. Here's an article I found just casually browsing on Google that shows why this can turn out to be such a huge problem. https://itnext.io/golang-1-18-generics-the-good-the-bad-the-ugly-5e9fa2520e76 https://itnext.io/golang-1-18-generics-the-good-the-bad-the-...
  - munificent 5y ago
    There's a lot of developers that misuse/shouldn't use any powerful feature. If the solution is to give them a nerfed language, then you also nerf it for the users that would use the feature well in productive, useful ways.
    - jshen 5y ago
      Yes, it’s a trade-off. In an organization with thousands of developers the right trade-off is likely different than an org with 20. What I don’t understand is why people insist on making Go like every other language that already does what that are looking for. You want a language with generics, purely functional blah blah blah, great there are tons of choices, use one of them. Why insist on reducing the diversity in language choice, and trade-offs?
      - 5y ago
cfors 5y ago
This will no doubt be overshadowed by Generics, but Workspaces[0] are going to be incredibly useful for companies using a monorepo with shared packages. Once again, great job to the Go team! [0] https://go.dev/doc/tutorial/workspaces https://go.dev/doc/tutorial/workspaces
- kubanczyk 5y ago
  Finally! Helps with both monorepos and multirepos, as illustrated in the tutorial you've linked. (After going through a bunch of associated docs, I'm under impression that their quality is going down, slowly. At least when comparing it with the stdlib docs' quality.)
diehunde 5y ago
I highly recommend checking out the Type Parameters Proposal[1]. It's surprisingly easy to digest and has more realistic and complex examples than the quickstart guide or any other blog post out there. [1] https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md https://go.googlesource.com/proposal/+/refs/heads/master/des...
- tapirl 5y ago
  Please note that not all features in the proposal are implemented yet.

Go 1.18

773 points by mjlee 5y ago

mjlee 5y ago

Release notes are here: https://go.dev/doc/go1.18 https://go.dev/doc/go1.18

Jolter 5y ago
This should be the posted link instead of the OP, IMO.

philosopher1234 5y ago

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the language design, but I suspect that doesn't account for all of it. It seems to me that the intensity with which some people fixated on the absence of generics cannot be explained just by frustration with writing non-generic code, which by all accounts was annoying but not overwhelmingly so. So, for those of you who are willing to explore the part of this that goes beyond a simple rational analysis and criticism of language design, whats bugging you? Sometimes I think the core irritation with Go is its simplicity. The suggestion that easy to learn languages can be effective too is somewhat humiliating, as we get attached to the pride of mastering more complex languages, and the suggestion is that some of the struggling we went through was unnecessary, and that folks who wont struggle as much might be able to be effective too, in fact the suggestion is that maybe our pride was misplaced. Theres also a suggestion, in the fact that Go has opinions, that other opinions might be "wrong". I think this may bug people, who would take up those other opinions or see merit in them, a lot. There's also a bit of an anti-expertise "who are you, Go creators, to say you know better than me how to design this program/engage in software development?" In any case, it's something I've been trying to figure out for a while and I don't think I have a complete explanation still. Curious to see what others think.

deleted 5y ago
[deleted]
icholy 5y ago
People are upset that their favourite language didn't get as popular as Go.
- echelon 5y ago
  Counter point: Generics make me far more inclined to use Go regularly. If error handling is improved to be safer and more ergonomic, it'll be incredibly compelling for me. Generics were the biggest feature keeping me from using the language, and now that's a done deal. I'm excited.
  - icholy 5y ago
    If you consider the adoption rate, it's pretty clear that the people who avoid Go because of <insert missing feature> are a vocal minority.
    - echelon 5y ago
      Well, I can only speak for myself :)
    - mcronce 5y ago
      While true, that doesn't really change the situation for the individuals who require <missing feature>
      - throwaway894345 5y ago
        No one meaningfully "requires generics", people are just reluctant to set their ego aside and learn a different approach. Some use cases may benefit from generics, but even then "require" is too strong.
        5y ago

honkycat 5y ago

WOOO! I have been using the RC at work lately, and I have to say: The generics implementation is quite nice, and RUTHLESSLY slashes boilerplate and copy-pasta. This is going to turn Golang from "that one boilerplate-y language without generics" into my favorite language. I've been using the https://github.com/samber/lo https://github.com/samber/lo library, and it is very nice to be able to do "map/reduce/etc..." on golang structs. I would really enjoy a chaining library, and some tooling to make type coersion a bit cleaner.

aston 5y ago
You might like Go-Chainable: https://github.com/neurocollective/go_chainable https://github.com/neurocollective/go_chainable
earthboundkid 5y ago
I find that the function boilerplate of Go is too long because there's no equivalent of an arrow func. I can't see those kind of libraries taking off until there's an easier way to write a closure.
edenlinger 5y ago
I don't mean to disparage the wonderful work of the lo developers but, this is in many ways what I feared generics would bring. If you aren't going to lean into the simplicity and single way of doing something, you are likely better served in another language. I am probably an old man yelling at clouds and I hope those who like this style get tons of value from it. I just don't see the benefit of trying to retrofit some of the behavior of other perfectly useful languages into Go. JS/Java/C#/Python/Ruby is a fine language. Let each of them have their strengths. I feel like trying to bolt things together this way only serves to take away what is special and valuable in Go. I should probably shut up and just be happy lots of other people are using a language I enjoy :)
- kortex 5y ago
  > I don't mean to disparage the wonderful work of the lo developers but, > this is in many ways what I feared generics would bring. What is, anything in particular about that "lo" library? Just the way it uses generics, or moreso that it's yet another library to learn to be effective? Can't argue with the latter, but as far as the former goes, I think that looks quite reasonable. It's very explicit, there's no magic going on. I think there's definitely a bar for "so much abstraction that it is discouraging to developers not into that sort of thing", and IMHO that doesn't cross it. Monads, sure, that's a tall order for many folks. But this is pretty tame. But I am a fan of abstraction so I'm not the best judge.

earthboundkid 5y ago

Now Go sucks because there are too many generics.

pjmlp 5y ago

Finally generics support. Now another 10 years for proper enums. Kidding, I always mentioned that CLU like would be good enough.

bsaul 5y ago
I’m surprised go didn’t add real enums before generics. This seemed to be much more orthogonal to the type system, and blend well with the language. I guess there was caveat i’m not aware of.
- pjmlp 5y ago
  It is another thing that original team isn't found of. Rob Pike has some posts on gonuts where he asserts the current approach is good enough.

didip 5y ago

Generics!!! I can't wait for all the different data structure libraries to embrace it. It will make Go adoption in Data Science use-case easier.

leetrout 5y ago
Some speculation it will allow for better ORMs as well...
mrtranscendence 5y ago
I don’t see Go ever making headway in data science. For one, it’s not fast enough to implement algorithms directly but lacks a decent FFI; it would be burdensome to create the metric ton of new libraries that would have to be put into place. And there are Python libraries for basically everything already, from numeric computing to Bayesian time series to Spark to Torch and TensorFlow. Plus Go’s kind of weird, relative to the languages that many data scientists have experience with. Maybe I’m being unfair, though.
- IshKebab 5y ago
  Go is definitely fast enough to do data science.
  - mrtranscendence 5y ago
    Sure, it’s much faster than Python, agreed. But is it fast enough to implement highly optimized numerical algorithms in a way that can compete with Fortran or C? That I’m not so sure of, and if not you’re stuck with the crappy FFI.
    - IshKebab 5y ago
      Unless you need the last 10% of performance, yes it is. You can also use assembly directly from Go if you need bleeding edge speed.
      - 5y ago

sambeau 5y ago

LET THE REWRITING BEGIN!…

johndfsgdgdfg 5y ago

seanw444 5y ago
This has to be satire.
IceWreck 5y ago
So switch from one corp to the other ? Thats one extremely biased view. Use whatever you like, theyre all open source.

slicedbrandy 5y ago

Now time to update interface{} usage and shift to any. $ gofmt -r 'interface{} -> any' -l **/*.go Replace -l with -w to write.

rpk788 5y ago
well there goes my Hacktoberfest idea
eatonphil 5y ago
Is there an actual difference between these or is it just aesthetic? (and shorter)
- xiaq 5y ago
  any is an alias of interface{}, so purely aesthetic.

candiddevmike 5y ago

Personally, I'm waiting until 1.19 to start seriously exploring generics. By then, the dust will have settled a bit, folks will have some good lessons learned to share, and there may be more packages in the stdlib for generics.

ainar-g 5y ago
I feel like a lot of people will wait (although perhaps not up until 1.19) for the simple reason that tooling support is still not quite there yet. See [1] and the related issues. Static code analysis is reasonably popular in Go projects, and just disabling all failing tools until the tooling is there is not something most people would agree to, I think. With that said, of the tools that I use about ⅔ are already reasonably compatible. Unfortunately, the other ⅓ are among the most essential ones. [1]: https://github.com/golang/go/issues/48525 https://github.com/golang/go/issues/48525
bashery 5y ago
+1
- thegeekpirate 5y ago
  Please stop posting this on every comment you agree with, as you're not adding anything useful to the discussion, while also sending alerts to people for no good reason. Click on the upvote button instead.

mseepgood 5y ago

Why post this useless Github link instead of the release notes or the blog post?

anthropodie 5y ago
yes @dang please re-link this post to https://go.dev/doc/go1.18 https://go.dev/doc/go1.18
- hi41 5y ago
  That’s a cool feature you used there. I didn’t know you could use the at-the-rate symbol to reference a hn user and call his attention! Very nice!
  - tptacek 5y ago
    It's not a feature, and it's not a good idea to refer to people with @nicks, because Twitter's @name convention is much stronger and the two don't overlap perfectly (I am not, for instance, @tptacek on Twitter). I use 'nick to refer to people here, in keeping with our lispy ethos, but really anything other than @nick is fine.
    - whimsicalism 5y ago
      I would not assume any "@" is referring to a twitter user, it is common across a number of apps (not to mention, IRC)
      - opan 5y ago
        It's worth noting that on IRC it refers to someone being an op, and that it's not used for pinging people. (I sometimes see people who are used to other chats put the @ at the start of an IRC message)
      - kadoban 5y ago
        On IRC, typical protocol is to just use people's nickname, with a colon after it if you're replying specifically to them. "@" is uncommon for tagging people.

justinsaccount 5y ago

Generics is the big news, but the fuzzing support is amazing too. I added a fuzz test to an app I have in about 5 minutes. It was no harder than adding a normal test. I expect to see a huge boon in users of fuzzing techniques which will benefit projects across the board.

staticassertion 5y ago
I'm very happy to see fuzzing added to Go, and I don't write Go at all (or every plan to). Bringing concepts like this to the masses is a win for everybody.
sneak 5y ago
Link to the diff? I always learn better by concrete example than by docs.
- nwsm 5y ago
  The docs have concrete examples if you want- https://go.dev/doc/tutorial/fuzz https://go.dev/doc/tutorial/fuzz
2OEH8eoCRo0 5y ago
Nobody at my work has even heard of fuzzing and thought I was making it up. I'm glad senior SWEs are paid so much to keep up with the industry. /s
- movedx 5y ago
  I don't consider those kinds of people engineers at all. They're people who have learned a syntax, some patterns and, thanks to their human brain, can adopt it slightly to certain situations. But they're not engineers. Engineers constantly ask why, explore the unknown and are aware of almost all possible solutions available to them. using this knowledge they select the correct tools and build the solution. What you've described are skilled labourers. I'm harsh with my judgement because I believe our industry has a lot of "statically minded" individuals who stay in their lane, never going outside their boxes, to explore what else is out there to help them solves the engineering problems they're faced with... and it's pissing me off :)

AaronFriel 5y ago

My favorite feature is a tiny, couple line bug fix that I pushed hard to get included during the feature freeze. Full details here, but a summary is below: https://github.com/golang/go/issues/51127 https://github.com/golang/go/issues/51127 For the past ~8 years, many hundreds of people reported on GitHub - and likely many multiples more have encountered and not reported - a program that didn't work with the error "cannot unmarshal DNS..." This error seems to be caused by two things: 1. DNS proxies not adhering to the DNS spec. This would be due to VPNs with integrated DNS proxies such as Cisco AnyConnect, internet connection sharing on Windows (which affects DNS resolution in the Windows Subsystem for Linux), or even just incorrectly implemented recursive resolvers. Specifically, if these servers receive a DNS message that utilizes RFC 1035, section 4.1.4 "message compression", which is an extremely simple compression scheme, then they may transmit a DNS message that doesn't utilize message compression, which means the proxy isn't in response size 1:1 but almost always increases the size of DNS responses. 2. Go's net/dns resolver enforcing a strict 512 byte limit on responses. This is the same behavior as musl (and I would implore a musl maintainer to increase this limit) but not in glibc or most OS distributions' default DNS behavior. I read every single GitHub issue related to this and found the frustration of both end-users and OSS software maintainers overwhelming. End users lacked the tools to diagnose why the software didn't work, maintainers couldn't reproduce the issue. This bug affected major projects: Mesos, Docker, Consul, Terraform, and more. For nearly a decade. Sometimes (as in Mesos) these were projects where they controlled the DNS server and client, so they could implement DNS message compression and solve it. In other cases, such as with Docker or Pulumi, where software runs on end-user machines, maintainers may have had to "close, can't repro" issues. The error was inscrutable and otherwise very skilled maintainers wrote this off as a fluke or user error. And these are just the tools that are typically used by skilled technical users - usually engineers. It's hard to estimate but not difficult to imagine underestimating how many bug reports and issues end-users encountered where a cryptic error message, if shown, never made its way to GitHub. Software that works is better than software that - sometimes cryptically - does not. And when things just work, well, very few people using Go will realize that this fix prevented them from experiencing an afternoon or a day or more of frustration; but I will :) and I think that's what makes contributing to OSS awesome.

tedunangst 5y ago

leetrout 5y ago

Hooray! Couple quality of life improvements to embedded filesystems... you can now use files that start with an underscore :D

henvic 5y ago

Tip: If you've only heard about generics, make sure to check out about fuzzing (*testing.F)!

meetups323 5y ago
Any idea why they have such a low byte budget? testing.Fuzz would be so much more readable. I'll accept test.Fuzz if 9 characters is the limit for any compound identifier. Is this sort of single letter class naming common in the standard library?
- unfunco 5y ago
  Not in the standard library in general, but in the testing package it's the convention. There's testing.B, testing.M, testing.T, and testing.F, and *testing.TB. https://pkg.go.dev/testing#pkg-types https://pkg.go.dev/testing#pkg-types
  - meetups323 5y ago
    Well that's a hard pass from me. I always knew go was quick to compile, I didn't know the lengths they were willing to go to achieve that! Case in point: it's not TB, as you stated, but rather PB.
    - joshuamorton 5y ago
      There's both, TestBase and ParallelBenchmark.
      - IshKebab 5y ago
        He's still right about that. Ridiculous naming. Fortunately the rest of Go uses sensible names so I think it would be silly to avoid Go just because of that.
- gvil 5y ago
  it's super common everywhere, also in third party libraries (`bson.M` is what exactly?). it's one of the reasons that makes go a very displeasing language to work with.

Shadonototra 5y ago

Why not link the announcement? https://tip.golang.org/blog/go1.18 https://tip.golang.org/blog/go1.18 Who cares about the tag What's up mods? @dang yo

_0w8t 5y ago

For me the most puzzling aspect of Go is channels. Ada tried CSP (Concurrent Sequential Processes that Go channels are based on) in eighties and people quickly realized that it lead to bad performance and was unsuitable for a lot of useful cases. So Ada got standard mutexes and signals. So why CSP which does not allow to implement priority delivery or multicasting and makes cancelling much harder compared with normal polymorphic message queue per thread? Moreover, Go crippled CSP even further as one cannot select on channel and file descriptor. Fortunately Go does provide mutexes and signals so one can ignore channels unless required by Go API. Still without proper sum types polymorphic and type-safe message queues are not possible.

pkulak 5y ago
I can never seem to understand why a GCed language has pointers, and makes you memorize when to use stack vs heap.
- mftb 5y ago
  It's pretty straightforward, knowing when to use the stack vs heap can improve your performance. Having both paradigms available in the language means you can start out relying on the GC for everything. Later when you're ready, you can look to make more intelligent use of the stack.
  - bashery 5y ago
    +1
- hnov 5y ago
  I think it's at least partially about value vs (mutable) reference semantics in Golang's case and the hope is that the compiler will know to whether heap or stack allocate based on escape analysis.
- Laremere 5y ago
  Go uses escape analysis to ensure memory safety of pointers. Taking a reference of a local variable means it might end up on the heap, and calling new might allocate on the stack. It all depends on if Go can determine that the lifetime of the pointers is less than the stack frame. It's good if you don't want to care about those details, it's bad if you really care about those details for performance reasons.

cube2222 5y ago

Great to see this! Generics will drastically improve datastructure libraries. That said, for people worrying about overcomplication, fortunately methods can't have type parameters. That means ergonomic monads are not possible to implement, and we'll most probably not see the whole functional story play out in Go.

ed25519FUUU 5y ago
Plenty of great functional alternatives to Go.
- cube2222 5y ago
  Definitely! I'd be worried though that functional developers coming to Go (for whatever reason) would try to write Go functionally. That will fortunately be very hard thanks to this limitation. Nothing specific against functional programming per-se, but as you said, Go's not the language for it.
- zinclozenge 5y ago
  None with the same performance characteristics, ease of use, and ecosystem size. I'm reasonably competent with Rust, but sometimes I don't want to bash my head against the borrow checker or litter my code with copy/clone. Go hits a nice sweet spot, my main quibbles are that there's no native iterators/comprehensions or sum types with compiler checked exhaustive matching. With generics we can get libraries that allow for more functional style programming, and golangci-lint has a linter for exhaustiveness.
  - kaba0 5y ago
    Scala is pretty close to Go in terms of popularity and I would argue that it has a much bigger ecosystem due to the JVM. It is also pretty much a typed python in terms of ease of use, and the JVM has stellar performance — other than small running scripts, for many kind of workloads Java’s state of the art GC will have better throughput than Go’s.

mseepgood 5y ago

Now Go has everything I need in a programming language!

drdaeman 5y ago
Not for me. There is no ?: ternary operator. Having to write 6 additional lines of code for each tiny conditional sucks. It's not frequent, I think I've only had a single case in a few years where I had difficulty working around, but when it happens - it's not fun. err := h(cond(x) ? f(x) : g(x)) vs var temp T if cond(x) { temp = f(x) } else { temp = g(x) } err := h(temp) Hopefully, this can be improved with generics, e.g. now it should be possible to create e.g. `func Coalesce (type T) (...args T) T` function to simplify common scenarios.
- crtc 5y ago
  This is by design: https://go.dev/doc/faq#Does_Go_have_a_ternary_form https://go.dev/doc/faq#Does_Go_have_a_ternary_form Ken Thompson added ?: to B / C and then he took it from us in Go due to the wisdom he gathered in between.
  - RodgerTheGreat 5y ago
    > A language needs only one conditional control flow construct. And yet, Go has a switch statement.
    - MrDOS 5y ago
      Not only that, but despite all of the other syntactic sugar Go is lacking (usually sorely, such as a “try” error handler), the switch statement is really just an “if” statement in disguise. var someVar, anotherVar string // ... switch { case someVar == "whatever": fmt.Println("Tell me how, exactly,") case anotherVar == "nope": fmt.Println("this compiles to a jump table?") default: fmt.Println("Spoiler: it doesn't.") }
      - 5y ago

crtc 5y ago

Finally! This will be the last day I see the words "Go" "lack of"/"no" and "generics" in one sentence.

esprehn 5y ago
That'll have to wait until the next release when the standard library gets updated... But soon!
uluyol 5y ago
I'm sure you'll see plenty of comments saying "Go generics lack support for X". Just ignore them — some people seem to have nothing better to do.
HideousKojima 5y ago
I mean in Java vs. C# fights people still bring up that C# generics are reified while Java generics rely on casting and erase type information at runtime, so probably not.
- int_19h 5y ago
  Go dodged that bullet by reifying theirs!

oxplot 5y ago

When you hear most critics of Go (or any language for that matter), they talk as if Go is merely an alternative syntax for their favorite language. Of course they're bothered by lack of a missing features and unfamiliar ways. As tired of an analogy as it may be, programming languages are like natural languages. Trying to learn Japanese by translating sentences, idioms and proverbs from English word for word will only end in frustration and confusion. If you read the history of Go, the whole point behind its creation (as with many others) was to start with a clean slate so new norms and ways of doing things could form, in service of large distributed teams and long term maintainability. Lack of generics, as unrelated as it may seem, is actually the result of the those and other goals. Specifically, Go authors avoided complicating the language, runtime, and compiler early on and thereby avoided negatively affecting long term maintainability of both the language and the code written for it (v1 compatibility promise) before having a good grasp of how generics should be implemented in this new language or if it should be at all. Copying the so called tried and tested implementations from existing languages would make little sense as generics are so intertwined with the rest of a language. TL;DR approach learning programming languages like you would approach learning a new natural language with the purpose of living among its native speakers.

pie_flavor 5y ago
Certainly a better take than 'I don't like generics, it's somehow less complicated to downcast interface{} everywhere'. It was very interesting reading the justification for not having generic methods, and how that clashed with my assumption of what generics should be, or for that matter what methods should be. Go is the spiritual successor to C, IMO - for all that people use it nowadays for its low-level capability, people forget that its original purpose was to do what every other language of its day did, but way, way more simply.
int_19h 5y ago
Most critics of Go are well aware of its history and purported design goals. The problem is that the set of features that actually are in Go (like channels) versus those that weren't (like generics) or still aren't (like enums) doesn't really make sense when taking those design goals at face value. For example, generics. Like you say, the original claim was that they didn't want to do them because they thought that more time is needed to figure out how to do them "right". And so they waited for a decade, and ended up implementing them in a way that's not fundamentally different from most other languages that had them all along. What, exactly, was gained here to justify the productivity lost while waiting? I will also add that to someone who knows a few PLs, Go is a very boring language in a sense that there's very little new there, neither in terms of individual parts, nor in terms of how they're combined together. So the notion that this combination is somehow so unique that its evolution is like walking on untested ground doesn't pass the smell test.

frenchie4111 5y ago

In celebration of generics release, I was playing around with supporting Optionals via generics. If anyone's interested I am happy to make this a real project https://github.com/frenchie4111/go-generic-optional https://github.com/frenchie4111/go-generic-optional

Mawr 5y ago
type Optional[T any] struct { value *T } Don't use a pointer - it's bad for performance. func MakeOptional[T any](value *T) Optional[T] { Use `New` instead - it's the idiomatic name for a constructor in Go. Drop the `Optional` part - the module name suffices - the caller will see: `opt.New`. Personally I just call the module `optional`, I think it's clearer: `optional.New`. func (o* Optional[T]) Unwrap() (T, error) { 1. `Unwrap` reminds me of Rust's .Unwrap, which panics. Seems confusing. 2. There's no error here, the situation is equivalent to a missing key in a map - it's enough to return a bool. Here's my implementation so far: https://gist.github.com/Mawr-BF2/0a60da26f66b82ee87b98b03336e1f84 https://gist.github.com/Mawr-BF2/0a60da26f66b82ee87b98b03336.... Only thing I'm not sure about is whether the JSON serialization methods are necessary.
- wtfishackernews 5y ago
  For json marshalling, I would defer to the underlying type's marshalling if it's present, and return `null` otherwise.
  - shhsshs 5y ago
    I think this is appropriate in some cases but not others. For example how does the JSON value distinguish between `Some(null)` and `None`?
    - dialogbox 5y ago
      IMO using Optional type means the inner value must be not null. And if it's Some(null), it should mean exactly same as None.

akmittal 5y ago

Hopefully generics will help make better libraries for Graphql. Existing libraries resorted to code generation a lot.

bogomipz 5y ago
Interesting. I'm curious how code generation is/was used to work around the language not having having support for generics? Or was this something specific to Graphql?
- scheme271 5y ago
  The kubernetes api (more specifically the k8s apimachinery) code uses codegen in order to create code so that you can convert custom CRDs to go structures rather than working with json. It's one of the more opaque bits of writing go code that works with k8s.
- akmittal 5y ago
  gqlgen is most popular for graphql and uses codegen. It seem to be good but It felt not that easy to use coming from node world(apollo-server). There were bunch of libraries which helped with code generation to work around generics. I don't think it was specific to Graphql. https://github.com/cheekybits/genny https://github.com/cheekybits/genny is one I have seen.
naikrovek 5y ago
> Existing libraries resorted to code generation a lot. guess what generics is in a lot of languages? code generation! the files just aren't saved to disk. IIRC on a podcast I seem to recall hearing that it was implemented this way for Go, at least for the prototype, and it seems likely to me that it is also done this way in production, but not with textual code.
- akmittal 5y ago
  Thats like saying lets just write assembly because eventually code will be converted to assembly. As a developer now we dont have to bother about codegen.

haolez 5y ago

I hope open source Go code in the wild remains easy to read and understand. Generics look cool, despite this possible downside.

rochak 5y ago
I have already started having trouble understanding open source code using generics. I can see the upsides of having generics, but have lost the enthusiasm with which I used to browse Go code. I am still a junior engineer, so maybe it will get better with time.
- dgb23 5y ago
  Every abstraction tool will get misused, especially early on. I bet the Go community will figure out how ways to mitigate that in the long run, given it’s culture around readability.
  - int_19h 5y ago
    Also, I think that a lot of supposed "misuse" that people are complaining about is actually using the right tool for the job, and the complaints stem from treating the tool itself as inherently too complicated (and thus any use of it as automatically suspect) because it's new and not conceptually trivial. There was a lot of that back when Java and C# first got their generics.
chabad360 5y ago
I've found generic code much easier to read once I started playing with it myself. It might be worth implementing a generic sorter (or some other easily generic construct) just to get more familiar with the new syntax.

deleted 5y ago

[deleted]

exdsq 5y ago

Aaaand now watch every projects abstraction increase tenfold under the weight of generics

kortex 5y ago
Or put another way, 1/10th the surface area of code to write, maintain, review, and bug check. And much less interface{} abuse. That's taking "tenfold" at face value. I don't see that happening personally. The go community has enough of a nucleus of devs with a certain mindset that I don't see crazy Haskell levels of abstraction taking over. What I do see is more type safety coming to interface dynamicism.
avl999 5y ago
Or an expectation of competence from developers and expecting them to consider tradeoffs of their design- in other words doing their damn jobs as opposed to the language baby sitting them away from tools they might use incorrectly.
- exdsq 5y ago
  There’s nothing wrong with a language being strict with what you can do to force good programming styles. An expectation of competence is nice if you can afford it, but it’s also nice to have languages that mean you don’t have to take that risk. It’s why I liked Go and why I disliked working in Haskell. Look at Lisp - large teams get tied in knots because of the freedom. Go was nice because it just stopped you doing ‘smart’ things. Now it has generics you may as well use Rust or something else.
  - jatone 5y ago
    having used rust that isn't a sane trade off. rust is a wonderful language but its orders of magnitude slower than go for development.

voakbasda 5y ago

I hope this gets merged into the upcoming Yocto `kirkstone` LTS release branch, since that branch will use the same pinned version for years to come. The previous `dunfell` LTS release branch provided Go 1.14, which can no longer build the latest versions of many projects.

typical182 5y ago

There is also a new set of FAQs on generics: https://go.dev/doc/faq#Type_Parameters https://go.dev/doc/faq#Type_Parameters

everybodyknows 5y ago
This is the part anyone writing performance-critical code will find troubling: > The compiler can choose whether to compile each instantiation separately or whether to compile reasonably similar instantiations as a single implementation. ...

gnoack 5y ago

The general excitement about generics on this thread makes me uneasy. Please keep in mind that generics are a pretty big hammer - they can add a lot of complication if not used with caution. Only use a language feature if you absolutely must.

HideousKojima 5y ago
I see it the other way around, generics reduce complication and allow for code that's a lot more elegant and simple than without. It definitely adds complexity on the compiler side of things, but using them in C#, TypeScript, and Java has been only a plus. Unless you count that time I tried to do stuff with generic interfaces in Entity Framework Core, but that was EF Core's fault as opposed to generics's.
- tptacek 5y ago
  As with everything else, sometimes this is true, sometimes it isn't. In languages with pervasive generics, figuring out how things work can mean following several extraneous layers of indirection as any opportunity to parameterize something is always taken. But writing the same stupid loop to delete something from a slice is also unclear and complicated. The point isn't that generics are bad, just that they should be used judiciously.
- gnoack 5y ago
  ...and that time when people reinvented boolean expressions and their combinatorics under the disguise of Predicate<T> and Matcher<T>, making test errors hard to comprehend for very little additional benefit. etc etc There is also the problem that people don't generally have a good grasp on how to use type bounds[1] correctly... I believe Go avoids the worst of it through its simple type system, but still... this complicates a language significantly. [1] https://docs.oracle.com/javase/tutorial/java/generics/bounded.html https://docs.oracle.com/javase/tutorial/java/generics/bounde...
  - pjmlp 5y ago
    Still better than messing with code generators and template language workarounds.

mikojan 5y ago

I will forever miss old Go :-(

flippinburgers 5y ago
Me too.

flippinburgers 5y ago

Honestly I think this will make the overall programming experience worse.

HideousKojima 5y ago
In what way? Almost every other major language has them without major issues. Go devs saying generics are a bad thing reminds me of people in Oregon freaking out over being allowed to pump their own gas while the other 49 states have been doing that for decades.
- jatone 5y ago
  never once was it said by the go devs that generics are bad. it was asserted that generics are complicated to get right and they wanted to take their time.
pie_flavor 5y ago
Is it a worse programming experience to understand an esoteric library's use of [T U], or to need to choose between codegen vs interface{} for the most common use cases? The ability to misuse a feature should not be understated, but I think people have been jumping over the missing stair of interface{} for so long that they've forgotten how much of an incredible pain it is.

bborud 5y ago

I really hope people will show restraint.

morelisp 5y ago

strings.Cut / bytes.Cut is really nice.

jadbox 5y ago

Is there a go-to implementation of typed map/reduce/filter with 1.18?

maxekman 5y ago
https://pkg.go.dev/golang.org/x/exp/maps https://pkg.go.dev/golang.org/x/exp/maps https://pkg.go.dev/golang.org/x/exp/slices https://pkg.go.dev/golang.org/x/exp/slices https://pkg.go.dev/golang.org/x/exp/constraints https://pkg.go.dev/golang.org/x/exp/constraints
frenchie4111 5y ago
Someone started a lodash style stdlib replacement: https://github.com/samber/lo https://github.com/samber/lo

t43562 5y ago

I think about Go with pleasure until I remember importing. The miseries I've experienced with modules - the way imports are satisfied......just so hard to understand. Built-in support for SCM sites like github (yuck!). Just struggling to put code in a place where some other bit of my code can use it. The C/C++ preprocessor is an abortion and go seems to have made something that solves all the problems I had with that but ends up much worse to use.

ithkuil 5y ago
My main misery with modules was due to people renaming their GitHub repositories
- jayd16 5y ago
  Fork them (just make a copy you own) so you have control?
  - ithkuil 5y ago
    Usually my problems are with transitive dependencies. I would have to fork quite a few projects to deal with that. I wish there was a more systematic way to do "replace", possibly in libraries as well
    - thiht 5y ago
      There’s a « replace » directive in go.mod.
      - ithkuil 5y ago
        Yeah I know, but it's suboptimal. If you use it your module cannot be "go install" lled, and it doesn't work for libraries
        acchow 5y ago
        Replace in go.mod breaks `go install`?

eatonphil 5y ago

Regarding Windows: while this isn't on scoop yet I was able to get it in Github Actions like so: curl -L -O "https://go.dev/dl/go1.18.windows-amd64.zip" unzip go1.18.windows-amd64.zip Join-Path $pwd "go\bin" >> $Env:GITHUB_PATH A request/suggestion for the Go team: include instructions for how to use the Windows zip! It's not a big deal but I had to figure it out by `ls`-ing around.

dgrr19 5y ago

[dead]

pie_flavor 5y ago

I wish I understood how people can say 'this will result in so much more weird boilerplate garbage code' as it solves a problem that has resulted in an absolutely ludicrous amount of weird boilerplate garbage code. You're not trading off generic code vs non-generic code. Problems are generic. For solving generic problems, you're trading off the generic code that best expresses them, for codegen, dynamic downcasting, or Ctrl-V. The first two are not simpler (in the Go way) than generics, and the third is an antipattern in every programming environment.

dimgl 5y ago
Disclaimer: I'm extremely happy that generics are coming to Go. > I wish I understood how people can say 'this will result in so much more weird boilerplate garbage code' It's pretty simple: there's a lot of developers that misuse/shouldn't use generics. Here's an article I found just casually browsing on Google that shows why this can turn out to be such a huge problem. https://itnext.io/golang-1-18-generics-the-good-the-bad-the-ugly-5e9fa2520e76 https://itnext.io/golang-1-18-generics-the-good-the-bad-the-...
- munificent 5y ago
  There's a lot of developers that misuse/shouldn't use any powerful feature. If the solution is to give them a nerfed language, then you also nerf it for the users that would use the feature well in productive, useful ways.
  - jshen 5y ago
    Yes, it’s a trade-off. In an organization with thousands of developers the right trade-off is likely different than an org with 20. What I don’t understand is why people insist on making Go like every other language that already does what that are looking for. You want a language with generics, purely functional blah blah blah, great there are tons of choices, use one of them. Why insist on reducing the diversity in language choice, and trade-offs?
    - 5y ago

cfors 5y ago

This will no doubt be overshadowed by Generics, but Workspaces[0] are going to be incredibly useful for companies using a monorepo with shared packages. Once again, great job to the Go team! [0] https://go.dev/doc/tutorial/workspaces https://go.dev/doc/tutorial/workspaces

kubanczyk 5y ago
Finally! Helps with both monorepos and multirepos, as illustrated in the tutorial you've linked. (After going through a bunch of associated docs, I'm under impression that their quality is going down, slowly. At least when comparing it with the stdlib docs' quality.)

diehunde 5y ago

I highly recommend checking out the Type Parameters Proposal[1]. It's surprisingly easy to digest and has more realistic and complex examples than the quickstart guide or any other blog post out there. [1] https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md https://go.googlesource.com/proposal/+/refs/heads/master/des...

tapirl 5y ago
Please note that not all features in the proposal are implemented yet.