Earlier quoted context omitted.
Welcome to Go as a project.
Child hood trauma led to if err != nil and now the rest of us get to share that trauma? Makes slight sense I guess.
[deleted]
Go 1.27
91–100 of 277 posts
Re: Go 1.27
#92I love these release notes but I really wish they would add syntax highlighting to the Go blog. I'm always a little bit surprised/disappointed whenever I land on a go.dev link since I know the code will be just a little harder to visually parse than it needs to be.
There's a reason for this. Rob Pike was asked about it and said that syntax highlighting reminds him of the bright colors of children's toys and he personally disables it so that he can focus on the text. I don't know why it's still like that but that's the original reasoning.
What is childish is holding up one guy's editor preferences as a religious sacrament when 99.9% of your readers have different preferences.
Re: Go 1.27
#93Earlier quoted context omitted.
There's a reason for this. Rob Pike was asked about it and said that syntax highlighting reminds him of the bright colors of children's toys and he personally disables it so that he can focus on the text. I don't know why it's still like that but that's the original reasoning.
That makes sense as a personal preference for him, but it's odd for that to still be the company/project stance. Like, surely he knows he's the minority for not wanting highlighting?
Oceania had always been at war with Eastasia.
Re: Go 1.27
#94Earlier quoted context omitted.
Unfortunately for people SELECTing UUIDs out of a DB directly into a uuid struct, the built-in uuid structs don't implement the necessary interface for that, so you'll have to continue using the google package, or a plain string.
The database/sql package gained native support[1] for the uuid.UUID type so it will Just Work even without the methods. This probably should have been mentioned in the release notes and database/sql package docs. [1] https://cs.opensource.google/go/go/+/refs/tags/go1.27.0:src/...
Doesn’t the type name uuid.UUID violate go’s style guide for type naming? I seem to recall a fairly specific prohibition on stutter-types.
Re: Go 1.27
#95does it have goroutine termination, i recently found out you need a runtime patch for it
Re: Go 1.27
#96I love how proactive the crypto team is about post quantum. They released https://pkg.go.dev/crypto/mldsa . The lead maintainer Filippo Valsorda wrote a nice piece here[1] to urge the tech world to start deploying good enough versions of post quantum crypto. [1] https://words.filippo.io/crqc-timeline/
While I'm highly sympathetic to competing priorities crowding out movement to pq cryptography. At the same time it's not sudden at all. It's been 10 years since nist first said "move shit over"?
Yeah the deadline to move everything is drawing near I am actually not impressed by how fast things are going but all progress is good.
Re: Go 1.27
#97Earlier quoted context omitted.
The database/sql package gained native support[1] for the uuid.UUID type so it will Just Work even without the methods. This probably should have been mentioned in the release notes and database/sql package docs. [1] https://cs.opensource.google/go/go/+/refs/tags/go1.27.0:src/...
Doesn’t the type name uuid.UUID violate go’s style guide for type naming? I seem to recall a fairly specific prohibition on stutter-types.
No. What else could it reasonably be named? Hard to imagine.
The rule has always been intended to cover types that have another word in them but still choose to pointlessly repeat the package name.
`uuid.UUIDGenerator` is a hypothetical example of the anti-pattern that would instead be better named as `uuid.Generator`.
Re: Go 1.27
#98Earlier quoted context omitted.
The database/sql package gained native support[1] for the uuid.UUID type so it will Just Work even without the methods. This probably should have been mentioned in the release notes and database/sql package docs. [1] https://cs.opensource.google/go/go/+/refs/tags/go1.27.0:src/...
Doesn’t the type name uuid.UUID violate go’s style guide for type naming? I seem to recall a fairly specific prohibition on stutter-types.
Repeating the package name is fine if it's exactly the same name (modulo capitalization) and there's nothing better to name the type anyway. The style issue would arise with e.g. uuid.UUIDVersion, which should just be named uuid.Version. There used to be a gopls lint that would flag names like uuid.UUID but it got relaxed awhile ago.
Re: Go 1.27
#99I really want to like Go, but I can't stand looking at Go code. The error handling is such a turn off.
Re: Go 1.27
#100Wasn't Go supposed to be "simple"? I remember how Go advocates used to boast about not having generics and now it almost seems like Go is trying to become some sort of C# or Java Frankenstein. I'm not even trying to badmouth Golang - just legitimately confused.
> almost seems like Go is trying to become some sort of C# or Java Frankenstein The original Go team was trying to avoid this: "Java, JavaScript (ECMAScript), Typescript, C#, C++, Hack (PHP), and more [...] actively borrow features from one another. They are converging into a single huge language." [0] That team has since moved on, and now Go has begun to join that convergence. The problem is that most programmers se…
I would argue that languages like Java (C#, Kotlin, etc.) strike a very good compromise between modeling ability and comprehension, which is why they are popular and people gravitate toward them.
You can have more complex languages like Scala that provide stronger modeling ability, but at the cost of complexity. Golang started off as extremely naive/simplistic, and is now converging in some ways. But it still has a ways to go: no generics on interfaces, no unions/ADTs, no pattern matching, no proper enums, error handling leaves much to be desired, and much more.