111–120 of 131 posts
My fave golang slice trick is the len of an empty slice is 0, but the slice itself is == to nil, but the len of nil won't compile. Can't understand that one. https://go.dev/play/p/MslCkBphl7q?v=gotip
Because the bare value `nil` has no type. Typing it, e.g. `len([]int(nil))` works fine.
Earlier quoted context omitted.
Because the bare value `nil` has no type. Typing it, e.g. `len([]int(nil))` works fine.
This is the most satisfying answer, but it doesn't make the implications less complex.
In languages with null and type inference, `var x = null` is probably not going to infer the type you want. In languages with function overloading (which is essentially the case for Go `len`), `f(null)` is going to be a compile-time error if multiple overloads are potentially null.
Earlier quoted context omitted.
TLDR: The best part of Go is that there is very little magic in Go. If you understand that slices are just fat pointers implemented as a built-in, there is nothing confusing about them. I can understand every part of a Go program, all the way down to the language syntax that generate assembly. I don't have to be afraid of or be mystified by any language feature, because 1) there are few, 2) they are just programs imp…
Why not just use c at that point?
why do people write articles about go features? when PHP was in its prime, almost nobody wrote blogs explaining how they found some philosophy in PHP. there's a reason for that. when you see someone open their article explaining a language feature by talking of the implementation details or specific use cases, that's a language smell (of course all industrial PLs stink). ironically go is the only post 80s language th…
I'm not sure how your snippet above exemplifies memory unsafety. Concurrent access does let you hit some 'fun' behavior, but you have to be doing pretty dumb things to hit them. And while the implementation may be able to save you from something like that, such things would likely bubble up elsewhere(disk i/o, network i/o, etc) if doing that kind of thing.
Earlier quoted context omitted.
> The best part of Go is that there is very little magic in Go. If you understand that slices are just fat pointers implemented as a built-in, there is nothing confusing about them. It's just a tautology. If you understand something, of course by definition you aren't confuse about them. By using the same logic, all languages have "very little magic."
But the big difference is time to understand it
My fave golang slice trick is the len of an empty slice is 0, but the slice itself is == to nil, but the len of nil won't compile. Can't understand that one. https://go.dev/play/p/MslCkBphl7q?v=gotip
Earlier quoted context omitted.
"Proto" meaning protobuffers?
I think it rather "communication via some protocol" in general. In other words if we are not talking about giant monolith - we have N small systems to begin with.
Earlier quoted context omitted.
This is the most satisfying answer, but it doesn't make the implications less complex.
What implications did you have in mind? In languages with null and type inference, `var x = null` is probably not going to infer the type you want. In languages with function overloading (which is essentially the case for Go `len`), `f(null)` is going to be a compile-time error if multiple overloads are potentially null.
Earlier quoted context omitted.
What implications did you have in mind? In languages with null and type inference, `var x = null` is probably not going to infer the type you want. In languages with function overloading (which is essentially the case for Go `len`), `f(null)` is going to be a compile-time error if multiple overloads are potentially null.
the ability to cast nil as a zero length array means there's no difference between a function that returns a zero length array and a function that returns nil (assuming some casting process takes place). It could be a subtle and annoying bug to track down the difference.
Of the various legitimate issues around nil (box vs. unboxed, nil receivers, nilability of all pointers), this is the most not-actually-ever-an-issue.
Earlier quoted context omitted.
I'm not sure how your snippet above exemplifies memory unsafety. Concurrent access does let you hit some 'fun' behavior, but you have to be doing pretty dumb things to hit them. And while the implementation may be able to save you from something like that, such things would likely bubble up elsewhere(disk i/o, network i/o, etc) if doing that kind of thing.
I would also consider this to be memory unsafe. If you have an "array", you should not be able to index (or slice) beyond its bounds. If you are allowed to do so, you may have unpredictable junk in your array.