Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.27 Interactive Tour

victoriametrics.com

Post reply on HN
Print view View original

201–210 of 219 posts

Re: Go 1.27 Interactive Tour

#201

Post by zerr »

majewsky wrote: post #197
zerr wrote: post #143

Earlier quoted context omitted.

As a C++ (including modern) developer for more than 20 years, I had written a "template" keyword only for a handful of times. Maybe once in every 5 years on average... :) Unless you are a compiler/stdlib vendor or contributing to Boost, there are features that you just don't use it daily.

But you would still have to deal with the mental load associated with having templates in your stack. I don't know if C++ is still as bad as it was back in my day about vomiting 20-line error messages at you because "std::vector " or something has a billion implied template arguments. That was definitely a cost that one had to bear even if one never used the "template" keyword.

Ah, yes, it is much better now!

Re: Go 1.27 Interactive Tour

#202

Post by foldr »

kccqzy wrote: post #180
hnlmorg wrote: post #100

Earlier quoted context omitted.

I’ve written a lot of libraries too. The problem is generics only solve a very small part of the equation: compile time checks for composite types. But to use composite types in anything non-trivial in Go, you then need reflection. Which is slow. And if you then need reflection, you’re already passing interface types anyway plus you’re back to having to handle type-handling errors in the runtime. So if you’re writing…

Yes it is precisely Go’s shortcomings that would require typical use of generics to also require reflection most of the time. You would want Rust traits (or Haskell type classes) or C++ style type traits and then the need for reflection is much reduced. So Go has painted itself into a corner where generics feel bolted on and less useful than generics in other languages. It’s still Go’s fault and people rightfully arg…

>You would want Rust traits

Go generics does have this feature. You can require a generic type to implement an interface.

Re: Go 1.27 Interactive Tour

#203

Post by jerf »

drivebyhooting wrote: post #24
jerf wrote: post #16

Earlier quoted context omitted.

No. I kind of want to leave it there. But that will probably be looked on disfavorably. I've seen at least a dozen attempts. It's not like it's hard to write it out. There's maybe a couple of variants but they're all just a handful of lines. The problem is, once you have an Option in hand, you end up trading: val, err := whatever(...) if err != nil { // handle error } // use val for val := whatever(...) if err, isErr…

I think my opinion will be even more maligned: I like Java-style checked exceptions. It forces awareness of the error and a clean way to propagate it.

I share the general community's dislike for the way Java did it, but I do agree that it may be an overgeneralization to then conclude the entire idea is bad.

Still, to really make it work nicely is non-trivial in the presence of things like closures and I couldn't tell you right now how to fix it.

Re: Go 1.27 Interactive Tour

#204

Post by jerf »

bajsejohannes wrote: post #105
jerf wrote: post #16

Earlier quoted context omitted.

No. I kind of want to leave it there. But that will probably be looked on disfavorably. I've seen at least a dozen attempts. It's not like it's hard to write it out. There's maybe a couple of variants but they're all just a handful of lines. The problem is, once you have an Option in hand, you end up trading: val, err := whatever(...) if err != nil { // handle error } // use val for val := whatever(...) if err, isErr…

If you get the ? from rust in addition to the option, then it’s suddenly a lot more convenient. It will do `if err != nil { return err; }` in a single symbol. There’s also convenience at the returning side. You can always just return the error, and not have to care about dummy values for the other return values (which is especially annoying when changing the returned types). That said, it might still not be worth the…

The problem with ? is that it is not handling the error. It gives you a one-character mechanism for not handling the error. This is a regression from Go, from the point of view of Go's design philosophy, not an advantage. It's one of the major things that has killed error handling proposals... anything that makes "if err != nil { return err }" easier is a bad thing.

The minimal error handling code in Go is really:

    if err != nil {
        return fmt.Errorf("can't do thing thing I'm trying to do: %w", err)
    }
That is actually the code we want to be made easier.

"if err != nil { return err }" in my code is actually a specific claim that for error-handling purposes this function is conceptually part of the function that is calling it and it has just been factored out for other reasons.

Re: Go 1.27 Interactive Tour

#205

Post by xboxnolifes »

neilprosser wrote: post #55
my-next-account wrote: post #46

>The quieter but bigger change I really wish they didn't use such stupid LLM-isms.

I do wonder whether, as a group of people being regularly exposed to text written by LLMs, we'll gradually end up writing and talking like that in our normal language. At that point perhaps text written by LLM and human will be indistinguishable. I already find myself using terms like 'footgun' in jest more than I ever did before! "The creatures outside looked from pig to man, and from man to pig, and from pig to man…

There's no doubt that people will. Even without LLMs people adopt writing styles from what they read.

Re: Go 1.27 Interactive Tour

#206

Post by HumblyTossed »

majewsky wrote: post #198
HumblyTossed wrote: post #112

Earlier quoted context omitted.

Right? Sigh. I really dislike this. There are 37000 programming languages, stop forcing every single one that gets popular to look like this.

It's almost as if the choices that make languages "look like this" are the ones that are generally associated with a more productive development workflow.

Actually no. It’s dev FOMO. A tremendous amount of go has been written without all this. Go has just gotten more popular so devs want to make it into something they’ve used before instead of learning to use the language the way it is.

Re: Go 1.27 Interactive Tour

#207

Post by kccqzy »

foldr wrote: post #202
kccqzy wrote: post #180

Earlier quoted context omitted.

Yes it is precisely Go’s shortcomings that would require typical use of generics to also require reflection most of the time. You would want Rust traits (or Haskell type classes) or C++ style type traits and then the need for reflection is much reduced. So Go has painted itself into a corner where generics feel bolted on and less useful than generics in other languages. It’s still Go’s fault and people rightfully arg…

>You would want Rust traits Go generics does have this feature. You can require a generic type to implement an interface.

Requiring the implementation of a Go interface is less powerful than requiring a trait.

It reminded me of early years of Rust where people saw traits and asked, well Java had interfaces for many decades, what’s the innovation?

Re: Go 1.27 Interactive Tour

#208

Post by foldr »

kccqzy wrote: post #207
foldr wrote: post #202

Earlier quoted context omitted.

>You would want Rust traits Go generics does have this feature. You can require a generic type to implement an interface.

Requiring the implementation of a Go interface is less powerful than requiring a trait. It reminded me of early years of Rust where people saw traits and asked, well Java had interfaces for many decades, what’s the innovation?

I'm not sure you can really argue that Rust's traits are innovative. Haskell typeclasses, OO-style abstract interfaces, and C++-style associated types were already well-known and well-established features. The particular mix of those features in Rust may be new, but the same could be said for Go's, or really any programming language's, particular mix of features.

You're right of course that traits are more powerful than interfaces. Go simply isn't designed to satisfy fans of elaborate type systems. This can be frustrating at times, but it also means that you don't have to deal with overarchitected library code like this: https://github.com/marshallpierce/rust-base64/issues/213 (Yes, you can overarchitect code in Go too, but the simplicity of the language, and the model of the stdlib, do tend to discourage this in practice.)

I've never written Rust professionally, but I did have a Haskell job for a couple of years. IME the sophistication of the type system is a double-edged sword. Sometimes it lets you concisely express important invariants; sometimes you end up spending way too much time writing elaborate types for code that isn't really doing anything very interesting. I understand the appeal of fancy type systems. In practice, I get a productivity boost from any kind of basic static typing, and then rapidly diminishing returns from the fancier stuff.

Re: Go 1.27 Interactive Tour

#209

Post by lowmagnet »

> A quick credit first: the interactive Go tours were started by Anton Zhiyanov, who wrote one for every release from Go 1.22 through Go 1.26. He’s decided to stop, so we’re picking up where he left off.

But he actually wrote those and they made sense.

Re: Go 1.27 Interactive Tour

#210

Post by lowmagnet »

Altern4tiveAcc wrote: post #96

>func (b Box[T]) Map[U any](f func(T) U) Box[U] {} That's completely unreadable.

It's showing you it's blending the `Box[T]` with a function that takes a function that applies over `T` to get a new type `Box[U]`. It's a bit convoluted, and it's also unnecessary. I think it's more readable like this:

`func (b Box[In]) Map[Out any](f func(In) Out)Box[Out]`

Or

`func Apply[In, Out any](in []In, f func(In) Out) []Out`

Which can be used anywhere and is not tied to a "Box"

Honestly if it wasn't written in go it'd fit right in with Java, with a Verb in the kingdom of Nouns.

Post reply on HN