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

Go 1.21 Release Candidate

go.dev

Post reply on HN
Print view View original

221–230 of 236 posts

Re: Go 1.21 Release Candidate

#221

Post by doctor_eval »

panzi wrote: post #220
doctor_eval wrote: post #179

Earlier quoted context omitted.

It's hardly standard behaviour. I mean in Java for example there didn't used to be value types, so everything was a pointer and the effect of this would be the same as the new behaviour in Go. The only lesson to be learned here is that languages are different. But I think the new Go behaviour is more ergonomic.

In Java you can only close over final variables, so you can't close over the loop variable at all. (Unless that changed since last time I used Java, which - granted - was a long time ago.)

The problem being fixed doesn’t affect only closures, but the body of the for loop itself. So for example taking the address of the loop variable would unexpectedly return the same value for the duration of the loop.

Re: Go 1.21 Release Candidate

#222

Post by metaltyphoon »

racingmars wrote: post #112
metaltyphoon wrote: post #108

Earlier quoted context omitted.

Lets be honest, its a terrible choice

In what way? Overall as a language, identifier shadowing is a feature of the language in nested scopes. Are you saying built-in identifiers (that aren't language keywords) should be treated specially and work differently than user-declared identifiers?

It's terrible, IMO, because every package that has generic words is now a variable name I can't use. A simple example which i find unreasonable:

  package main

  import (  
   "fmt"  
   "path/filepath"  
  )

  func main() {  
   filepath := filepath.Dir("./")  
   //filepath.Dir('./") -> This is now a string. Can't use filepath package anymore
   fmt.Println(filepath)  
  }
Now I have to make up variable names because `filepath` will shadow the package. How it this sensible in any shape? Zip just does this better by having @ in front of builtins.

Re: Go 1.21 Release Candidate

#223

Post by philosopher1234 »

stouset wrote: post #215
yencabulator wrote: post #212

Earlier quoted context omitted.

You're distorting the real story to fit your bias. Once the NaNn edge case was discovered, work to deal with that edge case was started.

This isn't remotely close to the first or even the tenth time I've seen this exact pattern play out. Finally there's some straw that forces the golang team to backpedal on a dogmatic position, but along the way there's dozens of comical defenses of the current state of things.

So you say, with no actual reference. Maybe what you refer to happened in your head, and not in the real world.

Re: Go 1.21 Release Candidate

#224

Post by alex_lav »

philosopher1234 wrote: post #223
stouset wrote: post #215

Earlier quoted context omitted.

This isn't remotely close to the first or even the tenth time I've seen this exact pattern play out. Finally there's some straw that forces the golang team to backpedal on a dogmatic position, but along the way there's dozens of comical defenses of the current state of things.

So you say, with no actual reference. Maybe what you refer to happened in your head, and not in the real world.

1. Generics

2. Clear

Are the two already covered not enough?

Re: Go 1.21 Release Candidate

#225

Post by fuzztester »

stouset wrote: post #211
maccard wrote: post #198

Earlier quoted context omitted.

Every language has sharp edges, but go's whole MO is to avoid rabid footguns at the expense of verbosity (IMO). The for-shadow issue thats fixed this release is a great example of go deciding to do the intuitive thing rather than the "correct" thing because that's how people work. I don't think the implementation details matter to a user of a map or a slice (or an array for that matter) - they're language builtins (a…

In my experience, go has tons of footguns that come because of the verbosity. Rather than having clear abstractions that handle edge cases for you, you get to reimplement these things yourself every single time. Case in point, clear. Or "typed nils". Or accidentally swallowing errors because you had to handle them manually. Or reimplementing higher-level job control on top of channels every single time .

>Or reimplementing higher-level job control on top of channels every single time.

Can you please explain this?

Re: Go 1.21 Release Candidate

#226

Post by philosopher1234 »

alex_lav wrote: post #224
philosopher1234 wrote: post #223

Earlier quoted context omitted.

So you say, with no actual reference. Maybe what you refer to happened in your head, and not in the real world.

1. Generics 2. Clear Are the two already covered not enough?

I would like to see some content from the go team on generics or clear that fits your claim. Yes, there are many in the community who speak the way you suggest, but you don’t seem to know much about the Go teams pov.

Re: Go 1.21 Release Candidate

#227

Post by preseinger »

euroderf wrote: post #213
preseinger wrote: post #207

Earlier quoted context omitted.

huh? there's no dogma involved here, it's just an observation of the properties of the type a context is created with each request, and destroyed at the end of it and values stored in a context are accessible only through un-typed, runtime-fallible methods -- not something you want to lean on, if you can avoid it

In practical terms there's pros & cons I guess, but in general doesn't loading a Context with session variables make code more concise and easier to understand ? DB connections, loggers, and the like. If you really want to pass around Context's in all your API signatures then at least try to make the most of it. Are pitfalls ever actually encountered ?

if you pass a logger to a foo as a parameter to the foo constructor, then missing a logger is a compile-time error

if you pass a logger to a foo as a parameter in the request context, then missing a logger is a run-time error

Re: Go 1.21 Release Candidate

#228

Post by arp242 »

saghm wrote: post #219
arp242 wrote: post #144

Earlier quoted context omitted.

But it's not "removing items", at least not for all meanings of the word "removing". You can see this with something like: s := []string{"hello", "world", "foo", "bar"} fmt.Println(s) // [hello world foo bar] s = s[:0] fmt.Println(s) // [] s = append(s, "XXX") s = s[:2] fmt.Println(s) // [XXX world] Which will print back "XXX world" because it's using the same array, and nothing was ever "deleted": only the slice's l…

Okay, yeah, that definitely isn't what I expected. It's pretty wild to me that `s = s[:2]` will ever work fine if `len(s) == 1`; I would have assumed that it would always be the same regardless of how the slice was created. Playing around with it, it seems like this means that if you pass a subslice to a function, that function can get access to things from the entire slice, including the portions that weren't in the…

Slices in Go are a tad counter-intuitive, I agree, but the approach does make sense I think. It allows you to use "dynamic sized arrays" for most cases like you would in Python and not worry too much about the mechanics, at the price of some reduced performance, but in cases where this kind of performance does matter it allows you to be precise about allocations and array sizes. So you kind of get the best of both.

Anyhow, this explains it in detail, if you're not already familiar with it: https://go.dev/blog/slices-intro

Re: Go 1.21 Release Candidate

#229

Post by alex_lav »

philosopher1234 wrote: post #226
alex_lav wrote: post #224

Earlier quoted context omitted.

1. Generics 2. Clear Are the two already covered not enough?

I would like to see some content from the go team on generics or clear that fits your claim. Yes, there are many in the community who speak the way you suggest, but you don’t seem to know much about the Go teams pov.

https://news.ycombinator.com/item?id=23033183

A pretty apt write up.

But I accept there’s probably not an amount of evidence to change your belief on Go’s dogmatism. And that’s okay! You like a language. That’s great!

Re: Go 1.21 Release Candidate

#230

Post by preseinger »

metaltyphoon wrote: post #222
racingmars wrote: post #112

Earlier quoted context omitted.

In what way? Overall as a language, identifier shadowing is a feature of the language in nested scopes. Are you saying built-in identifiers (that aren't language keywords) should be treated specially and work differently than user-declared identifiers?

It's terrible, IMO, because every package that has generic words is now a variable name I can't use. A simple example which i find unreasonable: package main import ( "fmt" "path/filepath" ) func main() { filepath := filepath.Dir("./") //filepath.Dir('./") -> This is now a string. Can't use filepath package anymore fmt.Println(filepath) } Now I have to make up variable names because `filepath` will shadow the package…

you're complaining that the nomenclature for packages is not differentiated in a way that allows user code to have variable names with the same name as package names

you can still allow this, of course, by aliasing the package import

but needing to do this is "terrible"

is that correct?

Post reply on HN