7 ms·
I'll be the first to admit I know almost nothing about go, but it's surprises me to find we're still inventing languages with bobby traps like this, especially
by timrobinson333 3y ago
I'll be the first to admit I know almost nothing about go, but it's surprises me to find we're still inventing languages with bobby traps like this, especially bobby traps that were well known and understood in other languages at the time.
Actually it surprises me we're still inventing languages where local variables can be mutated, which seems to be at the root of the problem here
- tazjin 3y agoGo has a long list of booby traps like this and prides itself on them. From outside of the Go team it looks like a small cultural shift might slowly be happening, cleaning up some of the obvious mistakes everyone's been telling them about since the beginning. Rob Pike retiring and giving up some formal power with that probably helps.
- thiht 3y ago> Go has a long list of booby traps like this Huh? Where’s the list? From the top of my head I think this is the only thing that repeatedly bit me, although I’m very aware of the behavior of for loop scoping. Linters save me nowadays at least. Are there other things like that in the language that deserve a fix? Maybe things to do with json un/marshaling?
- kevincox 3y agoThat the printf functions shit garbage into your output if you get the formatting specifiers wrong. I'd much rather have a crash than silently corrupting output.
- telotortium 3y agoTyped versus untyped nil (not sure how this could be easily fixed though)
- the_gipsy 3y agoMy number one is not having algebraic/sum/union types leading to needing zero-values. Which is more like a never idling foot gatling gun.
- deleted 3y ago[deleted]
- wazzaps 3y agoCopying a mutex by value (thus duplicating the lock, causing deadlocks or worse) is far too easy
- icholy 3y ago`go vet` catches this.
- mhh__ 3y agoI use a tool called "type theory"
- icholy 3y agoKeep posting about D, I'm sure it will catch on soon.
- erik_seaberg 3y agoIs there a way to declare any type uncopyable? This is something I always thought Ada got right.
- deleted 3y ago[deleted]
- smasher164 3y agoyou stick this in your struct type noCopy struct{} func (*noCopy) Lock() {} func (*noCopy) Unlock() {}
- usefulcat 3y agoWow, even c++ won't let you do that (without invoking undefined behavior, anyway).
- nu11ptr 3y agoIt has been a while, but yes, there were a lot of them and I forget most. It made it kinda pointless to me that the language was "easy" when the code felt so brittle (Null pointers...really?). One weird thing that always goofed me up was that slices are passed by value but maps by reference. Always made it confusing how to pass them for serialization/deserialization. The compiler didn't complain it just panicked. Seemed like something the type system should catch.
- skitter 3y agoIf you append to a slice, you can't rely on the changes showing up in the original slice, nor on them not showing up.
- rsc 3y agoSpeaking as the person Rob Pike handed the formal power to (8 years ago now), I don't think that change has much to do with it. We've known about the problem for a long time. I have notes from the run up to Go 1 (circa 2011) where we considered making this change, but it didn't seem like a huge problem, and we were concerned about breaking old code, so on balance it didn't seem worth it. Two things moved the needle on this particular change: 1. A few years ago David Chase took the time to make the change in the compiler and inventory what it broke in a large code base (Google's, but any code base would have worked for that purpose). Seeing that real-world data made it clear that the problem was more serious than we realized and needed to be addressed. That is, it made clear that the positive side of the balance was heavier than we thought it was back in 2011. 2. The design of Go modules added a go version line, which we can key the change off. That completely avoids breaking any old code. That zeroed out the negative side of the balance.
- orblivion 3y agoWhat about let's say 5 years from now, someone digs up a Go project from 2022, decides to get it up to speed for 2028, updates the version line. Is there something that would remind them to check for breaking changes, including this one? Perhaps the go project initializer could add a comment above the version line with a URL with a list of such changes. Though, that wouldn't help for this change.
- deleted 3y ago[deleted]
- flakes 3y agoI think the key difference here is to consider toleration vs adoption. Old code is able to tolerate the changes and still work in new ecosystems. There is still work on maintainers if they want to actually adopt the features themselves. Allowing these two concepts to work together is what allows iteratively updating the world, rather than requiring big bang introduction of features. As for validating your software, the answer is the same as its always been… tests, tests and more tests.
- smasher164 3y ago> we're still inventing languages where local variables can be mutated Local mutability is probably one of the most common uses of mutability. A lot of it is using local state to build up a more complicated structure, and then getting rid of that state. Getting rid of that use-case is just giving up performance.
- zdimension 3y agoThere is a recurring joke about Go's language design ignoring many bits of the general language design knowledge collectively acquired through decades of writing new languages. This change is an example of why this joke exists.
- mixmastamyk 3y ago> where local variables can be mutated They aren't local, but belong to the outer scope. The misconception in a nutshell.
- wrboyce 3y agoCompletely unrelated to the point you’re making, but the phrase is “booby trap”; I believe it originates from pranks played on younger schoolboys in 1600s England (the etymology of booby being the Spanish “bobo”).
- deleted 3y ago[deleted]