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!
Go 1.18
321–330 of 614 posts
Re: Go 1.18
#322Earlier quoted context omitted.
> simpler, more concrete, more standard code. All three of these things are subjective. > in so many conversations I've had with Go critics esp over generics, the conversation eventually terminates at some variation of "Go forces me to think about programming differently than I'm used to" At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is.
>At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is. This justifies anything popular, including things that are now universally seen as bad, but once were popular.
In the context of a discussion about programming languages, no, it really doesn't. Not all slopes are slippery.
Re: Go 1.18
#323Earlier quoted context omitted.
> simpler, more concrete, more standard code. All three of these things are subjective. > in so many conversations I've had with Go critics esp over generics, the conversation eventually terminates at some variation of "Go forces me to think about programming differently than I'm used to" At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is.
> All three of these things are subjective. Not really. They aren’t formally defined, but there’s pretty wide consensus even among Go detractors about these qualities. > At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is. Not when there are plenty of people willing to think differently and reap the benefits.
[deleted]
Re: Go 1.18
#324Earlier quoted context omitted.
> simpler, more concrete, more standard code. All three of these things are subjective. > in so many conversations I've had with Go critics esp over generics, the conversation eventually terminates at some variation of "Go forces me to think about programming differently than I'm used to" At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is.
> All three of these things are subjective. Not really. They aren’t formally defined, but there’s pretty wide consensus even among Go detractors about these qualities. > At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is. Not when there are plenty of people willing to think differently and reap the benefits.
> there’s pretty wide consensus even among Go detractors about these qualities
[citation needed]
> there are plenty of people willing to think differently and reap the benefits
"Reap the benefits" is, again, subjective. It's something you like, not something objectively beneficial or worth the trade-offs in all, most, or even necessarily many projects.
This is precisely the unduly arrogant attitude amongst Gophers that others have already mentioned several times in this thread.
Re: Go 1.18
#325Generics 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.
Did it break anything/uncover anything?
Re: Go 1.18
#326Earlier quoted context omitted.
I like parts of Go. It's refreshing. I'm excited for this release. What I don't like is how its weak parts are consistently defended instead of having its shortcomings be acknowledged. Before any rational analysis and criticism can begin, we need to look at the context of these arguments. I'll do that through some of the comments on this post. - Issues people bring up are dismissed as non-issues or as personal prefer…
In case anyone is interested, here are my technical critiques of Go: - Boilerplate increases the surface area that a bug can hide in. The fact that most of the boilerplate is around error handling is especially worrying. Yes, the flexibility of "Errors are values"[1] is nice. But I also don't know any languages where errors _aren't_ values, so the main value add seems to be reduced boilerplate compared to individual…
> But I also don't know any languages where errors _aren't_ values
(look, i know you understand how exceptions work, please bear with me)
yes, Exception objects are technically values, but you don't return them to the caller; you throw them to the, uh, catcher. basically, you get a special, second way of returning something that bypasses the normal one! but in the EaV approach, errors just are returned like every other thing.
the uniformity of EaV comes in handy when doing generic things like mapping a function over a collection - don't have to worry if something will throw, because it's just a value! and that lets you go to some pretty powerful places w.r.t abstraction: see e.g. haskells `traverse`.
but yeah, EaV needs some syntactic sugar to reach ergonomic par with exceptions, otherwise you get if-err-not-nil soup :P
Re: Go 1.18
#327Earlier quoted context omitted.
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-goo…
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.
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?
Re: Go 1.18
#328Earlier quoted context omitted.
>At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is. This justifies anything popular, including things that are now universally seen as bad, but once were popular.
In the context of a discussion about programming languages, no, it really doesn't. Not all slopes are slippery.
It seems like it does to me. Why doesn't it?
Re: Go 1.18
#329Earlier quoted context omitted.
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
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.
There's both, TestBase and ParallelBenchmark.
Re: Go 1.18
#330Earlier quoted context omitted.
> 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'm a big Go proponent, and I'm pretty "meh" on generics. They'll make some code easier to read and write, but they'll make a lot of code a lot harder to read (because contrary to popular beli…
I think people are going to go off the rails with functions that abstract over for loops. I see it all the time in Javascript code, where people iterate over an Array multiple times because that's what the API makes easy. For example, say you want to separate a slice into two slices, one that contains matches and one that contains everything else. Right now, you'd just write: var matches, mismatches []whatever for _,…
This is a perfect example of the fundamental and probably irreconcilable disconnect between Go advocates and detractors. To me, your "bad" example is much better: not only is it less code, it directly expresses the intent rather than making the reader infer it from the sequence of manual loops and ifs.