161–170 of 236 posts
Earlier quoted context omitted.
You can const x = min(a, b) assuming a and b are const.
I can't think of a use case for that. If all the inputs are consts, then you know the values and can just assign it to be the less of a or b. Am I missing something here?
Earlier quoted context omitted.
I guess, but that seems expected to me at this point, and consistent within the semantics of how slices and maps work (and other values). Maps are kind of like type map *struct{ len int; ... } Slices are kind of like type slice struct{ len int; ... } We get a lot of convenience by having the pointers auto-dereferenced, but the cost is that the semantics are still different and there are no syntactic markers to remind…
> The slice in Go is more or less equivalent to &[] in Rust or std::span in C++. My understanding is, to use the Rust/C++ term, slices in Go are owned, but they are not in Rust or C++. That is, they're a pointer + length in the latter two, but a pointer, length, and capacity in Go.
Earlier quoted context omitted.
I can't think of a use case for that. If all the inputs are consts, then you know the values and can just assign it to be the less of a or b. Am I missing something here?
Const are build-time constants, they are not necessarily the same value across all build configurations.
Earlier quoted context omitted.
I guess, but that seems expected to me at this point, and consistent within the semantics of how slices and maps work (and other values). Maps are kind of like type map *struct{ len int; ... } Slices are kind of like type slice struct{ len int; ... } We get a lot of convenience by having the pointers auto-dereferenced, but the cost is that the semantics are still different and there are no syntactic markers to remind…
> The slice in Go is more or less equivalent to &[] in Rust or std::span in C++. Not really, because they are mutable, they can mutate the underlying memory, and they can re-allocate. They are a weird mix of &mut []/Vec or std::{span,vector}. In contrast, a Rust &[] can may the underlying storage (if it's an &mut []), but cannot spin out a new storage on its own and start a new life without a backing structure – and…
Java: We added structured concurrency and virtual threads!
Golang: We added a min function!
Most of the standard lib still doesn't properly support generics, and at this pace, it will be another 5 years at least before it does.
Earlier quoted context omitted.
I guess, but that seems expected to me at this point, and consistent within the semantics of how slices and maps work (and other values). Maps are kind of like type map *struct{ len int; ... } Slices are kind of like type slice struct{ len int; ... } We get a lot of convenience by having the pointers auto-dereferenced, but the cost is that the semantics are still different and there are no syntactic markers to remind…
> The slice in Go is more or less equivalent to &[] in Rust or std::span in C++. Not really, because they are mutable, they can mutate the underlying memory, and they can re-allocate. They are a weird mix of &mut []/Vec or std::{span,vector}. In contrast, a Rust &[] can may the underlying storage (if it's an &mut []), but cannot spin out a new storage on its own and start a new life without a backing structure – and…
If you talk about how Go slices are tricky for beginners, but you cite C++ as some kind of gold standard against which Go should be compared, then I think you’ve lost the plot—C++’s type system is a complete and utter trash fire for people who are new to programming. Rust, as well, is very difficult for people to get into. Even the Python semantics for lists get people tripped up all the time.
a = [[]] * 5
b = [[] for _ in range(5)]
The nuances of how references and values work is something that you have to work through, and then you have to come to terms with the conventions for the particular language you are using. IMO, Go’s slices are fine… you really just have to be careful about aliasing a slice you don’t own, but then again, that’s true for languages like C++, Python, Java, and C# as well. Rust is the only one that’s really different here.
Earlier quoted context omitted.
Isn't it considered bad practice?
yes, in general the context stores request-scoped data, whether or not the logger is a request-scoped value is a grey area and to reply to sibling comment, opentelemetry is basically a house of antipatterns, definitely do not look to it for guidance
Earlier quoted context omitted.
Isn't it considered bad practice?
yes, in general the context stores request-scoped data, whether or not the logger is a request-scoped value is a grey area and to reply to sibling comment, opentelemetry is basically a house of antipatterns, definitely do not look to it for guidance
"Look on My Works Ye Mighty and Despair!"
https://github.com/open-telemetry/opentelemetry-collector/tr... -> https://github.com/open-telemetry/opentelemetry-collector-re... ... and then a reasonable person trying to load that mess into their head may ask 'err, what's the difference between go.opentelemetry.io/collector and github.com/open-telemetry/opentelemetry-collector-contrib?'
$ curl -fsS go.opentelemetry.io/collector | grep go-import
It is interesting to see them add things like the "clear" function for maps and slices after suggesting to simply loop and delete each key one at a time for so long. Is this a result of the generics work that makes implementation easier vs. the extra work of making a new "magic" function (like "make", etc.)?
Those were always bad alternatives to a real design problem, they just didn't have a good alternative to offer at the time.
Earlier quoted context omitted.
Clearing a container is usually a much simpler and faster operation than looping through all and removing them individually. That's not a question of tidying something up.
There were compiler optimizations for clearing by iterating. I haven’t looked at the code, but I suspect this won’t be much more efficient than iterating was with the optimizations.