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

191–200 of 219 posts

Re: Go 1.27 Interactive Tour

#191

Post by SubjectToChange »

sirsinsalot wrote: post #183
zerr wrote: post #118

Earlier quoted context omitted.

We often forget that our profession (computer programming) belongs to STEM. Some (like Go 1.0 :)) wish to think it is Arts & Humanities. The sooner we realize that yes, it is OK and actually expected to bear a cognitive weight of "(b Box[T]) Map[U any](f func(T) U) Box[U]" the sooner we get back to reality... :)

Programming language evolution has always been the pursuit of abstractions that enable expressiveness and simplicity. Your comment boils down to "I'm smart", which in the end, isn't terribly smart. Having simplicity and expressiveness as a goal, and a general direction of achieving things through lazy means is at the heart of mathematics and engineering. Celebrate laziness and a want for simplicity. True simplicity i…

>Your comment boils down to "I'm smart", which in the end, isn't terribly smart.

They are saying that a programmer should be able to cope with the cognitive dissonance of not immediately understanding something.

>Celebrate laziness and a want for simplicity.

Concepts like generics might be intellectually more challenging, but they are clearly the “lazy” approach for actually writing code. Writing and maintaining multiple versions of the same function, or using code generation, is intellectual lazy but manually intensive.

Re: Go 1.27 Interactive Tour

#192

Post by hnlmorg »

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…

I picked Go for the language, so your argument is incorrect.

Go’s shortcoming is also its strength. Language design is a constant battle of tradeoffs. And I happen to find many of the decisions C++ and Rust made weren’t analogous with my preferences.

> It’s still Go’s fault and people rightfully argue that they should prefer a different language.

It’s no more Gos fault than it is the people using Go. It’s called an “opinion” and “preference”. Please don’t assuming your preference is some global truth, because it is not.

Re: Go 1.27 Interactive Tour

#193

Post by SubjectToChange »

wannabe44 wrote: post #157
zerr wrote: post #118

Earlier quoted context omitted.

We often forget that our profession (computer programming) belongs to STEM. Some (like Go 1.0 :)) wish to think it is Arts & Humanities. The sooner we realize that yes, it is OK and actually expected to bear a cognitive weight of "(b Box[T]) Map[U any](f func(T) U) Box[U]" the sooner we get back to reality... :)

In terms of tooling, Go is one of the few languages which remembers that we are in STEM.

I’m not sure if you are complementing or denigrating golang’s tooling. Most “STEM software” packages are horrendous in terms of user/developer experience, to the point of hampering their utility. For instance, MPI really reminds HPC users that we are in “STEM”, but not for a good reason.

Golang has good “implementation level” tooling, but that is still nothing when compared to tooling available to Java and C#. Even if GoLand is closing the gap on the IDE front (idk, I haven’t tried it), golang simply doesn’t offer the features found in OpenJDK or Dotnet (GC parameters/implementations, profiling/introspection data, interoperability/ffi, etc.). It just feels like golang’s tooling looks good when it’s competing against python, ruby, or JS/TS.

Re: Go 1.27 Interactive Tour

#194

Post by majewsky »

LukeShu wrote: post #151
YesThatTom2 wrote: post #131

"The best way to teach something new is to compare it to something the audience already understands." Could someone take the example, reduce it to a non-generic version for two types I DO understand, then show that with the new feature I can collapse them into the Box/Map example in the doc? I have 10+ years of Go experience and I can't make heads or tails of "(b Box[T]) Map[U any](f func(T) U) Box[U]"

type IntBox struct { v int } type StrBox struct { v string } func (b IntBox) MapToStr(f func(int) string) StrBox { return StrBox{v: f(b.v)} } (Please forgive any typos I made on mobile.) It wasn't a great example because "Box" isn't really a useful type. But the point is that you no longer need to define a separate "MapToXXX" method for every type you might want to map to; now you can have just one type-generic "Map"…

> "Box" isn't really a useful type.

It is very close to one. My Option[T] type [1] cannot have a Map method in stable Go because of the type system restriction in question. Instead, I have a separate package with freestanding functions with the same purpose, including Map [2].

[1] https://pkg.go.dev/go.xyrillian.de/gg/option#Option [2] https://pkg.go.dev/go.xyrillian.de/gg/options#Map

Re: Go 1.27 Interactive Tour

#195

Post by majewsky »

adrianmsmith wrote: post #50
baalimago wrote: post #42

This: "(b Box[T]) Map[U any](f func(T) U) Box[U]" is the type of cognitive weight I was happy that Go avoided.

I never understood the convention of using single letter names for generic parameters. I guess this started in C++ and every language has copied that convention. I think that code would be a lot easier to read if the types were called IN and OUT or In and Out or TIn and TOut or something like that.

I'm not necessarily disagreeing, but I'm following the single-letter convention because "TIn" or "InputType" looks too much like an exported symbol. Whenever I tried to write type arguments like that, this threw me off, so I reverted to single letters.

Re: Go 1.27 Interactive Tour

#196

Post by foldr »

whateveracct wrote: post #188
foldr wrote: post #155

Earlier quoted context omitted.

Like this, you mean? https://haskellforall.com/2012/05/scrap-your-type-classes Fine in principle, but AFAIK it never really caught on because the ergonomics suck. Interfaces/traits/type classes do seem to be a popular feature across languages, for what it's worth.

right but type classes are basically vtables aka dictionary passing but the compiler figures out which dictionary to summon for you but the key is they build seamlessly on top of real parametric polymorphism. you still get a real "forall a." in your proposition language. Go fucked up early on with their core language design due to an inability to learn from the 1970s so now it's terminally dookie sadly

Type classes are nice, yes, but SML doesn’t have them, or anything that can really stand in for Go’s interfaces.

Re: Go 1.27 Interactive Tour

#197

Post by majewsky »

zerr wrote: post #143
twsted wrote: post #63

Earlier quoted context omitted.

I really understand your feeling, I escaped from C++ years ago when I was overwhelmed by meta programming (initially i loved it). But anyway I find this in Go much more bearable.

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.

Re: Go 1.27 Interactive Tour

#198

Post by majewsky »

HumblyTossed wrote: post #112
baalimago wrote: post #42

This: "(b Box[T]) Map[U any](f func(T) U) Box[U]" is the type of cognitive weight I was happy that Go avoided.

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.

Re: Go 1.27 Interactive Tour

#199

Post by majewsky »

kune wrote: post #48
mappu wrote: post #13

Automatically draining http response bodies is a risky silent behaviour change. I think it will be an improvement for most applications, but it's very subtle if you were relying on the old behaviour

The Go team is addressing that in the release notes: https://go.dev/doc/go1.27 They think it will only affect use cases where a high number of idle connections were allowed to linger, for instance by setting MaxIdleConns in Transport to 0. They recommend to disable keep alives in that case.

> for instance by setting MaxIdleConns in Transport to 0

Which a lot of libraries are doing because they wrote an http.Transport{...} literal in an earlier version, and then std added new fields to the type in a way that silently breaks existing users. The zero value should have matched the previous default behavior.

Case in point: https://github.com/prometheus/client_golang/pull/1885/change...

We had the same in our own library, and now have a testcase checking if our own custom instantiation of http.Transport matches http.DefaultTransport, so that the tests scream loudly when upstream pulls this shit again: https://github.com/sapcc/go-bits/pull/309/changes

Re: Go 1.27 Interactive Tour

#200

Post by wccrawford »

63stack wrote: post #185
wccrawford wrote: post #81

Earlier quoted context omitted.

If you try a new thing and run into 1 (or maybe 2 errors), maybe it's worth the time to report them. If you run into a few errors, it's into "this isn't ready" or "they didn't try hard enough" territory, and it's not worth reporting the problems.

It's also not worth posting "I tried didn't work" because nobody knows what you tried. There is zero information in it, and it's a waste of bits that just pollutes the discussion.

It seems like that, but it's not. When trying to figure out a problem, even that tiny bit of information is worthwhile. If nobody else has posted it, it's the first indication that it doesn't work.

If others have posted, it's an indication that it's a wider-spread problem than you knew.

I'd still rather have more information, and I look down on people who only post something that useless. But it does have information I've used to figure problems out.

Post reply on HN