91–100 of 116 posts
Earlier quoted context omitted.
> They need Go 2 with T and ? T - that would be nice language to use. Zig has basically been this to me. As a developer, writing Zig feels a lot like writing Go, except with basically all of the pain points addressed. - Zig has different pointer types for different things. The default pointer type points to exactly one value. It also has an optional pointer type as described. Arrays and slices are also pointers of so…
I really like Zig, but the lack of easy to use interfaces is kind of a dealbreaker for me. One issue but I can't look past it when building anything of substantial size.
This is the mess a language lands on when it conflates optionality (a semantic concept) with references/pointers (purely a machine concept). In Go, the requirement " need (non-optional) a reference to an object" is simply not expressible. This is a solved problem in other languages, for example `&T` vs. `Option ` in Rust.
This is the most boring argument in computer science. It's like arguing about whether a language should have "goto" or not. There is no new ground to tread here. Most mainstream languages have null references. An entire cinematic universe of languages have been built from the premise that you should not have null references. This is a fundamental rift in programming language theory, and the very best you can do on HN…
We all agreed they shouldn't, right? I'm not familiar with any language designed in the last 15 (20?) years that has a goto statement.
So, yes, I agree this is a very old argument and it's sad that Golang repeated the failures of its predecessors.
At least it doesn't include "goto", though the temptation to do it for the wordplay must have been intense.
Edit: Amusingly, it appears that PHP added goto in version 5.3 (August 2014) https://www.php.net/manual/en/control-structures.goto.php
Earlier quoted context omitted.
This is the most boring argument in computer science. It's like arguing about whether a language should have "goto" or not. There is no new ground to tread here. Most mainstream languages have null references. An entire cinematic universe of languages have been built from the premise that you should not have null references. This is a fundamental rift in programming language theory, and the very best you can do on HN…
> It's like arguing about whether a language should have "goto" or not We all agreed they shouldn't, right? I'm not familiar with any language designed in the last 15 (20?) years that has a goto statement. So, yes, I agree this is a very old argument and it's sad that Golang repeated the failures of its predecessors. At least it doesn't include "goto", though the temptation to do it for the wordplay must have been in…
We didnt't agree to that, only thet thr over usage of goto hurts readability, but it is perfectly fine where appropriate (as a JMP analog to non-assembly[0]). Any language that supports loop naming implements a subset of goto, and proves why it's sometimes necessary.
0. Why isn't JMP considered harmful?
Earlier quoted context omitted.
I like maybe_value dereferences NULL with SIGILL and you have at least a backtrace with exact invalid access position.
Oh, you can get the information at compile time as well. https://godbolt.org/z/hTYbTE8j8 (or https://godbolt.org/z/K1M68sY3Y but this will be tricky in a larger code base)
You can't fool yourself and have to handle all cases: https://godbolt.org/z/4GqMdPej3
This is exactly what LLMs are really bad at. They don't have the knowledge (and don't ask for) the invariants of the system and write defensive code at every step of the way, which is not just unnecessary, it's bad because if an unexpected state still get into the system, you will never notice and bad data will flow through and makes everything unpredictable.
It was the first time I got surprised about AI code QA
It will note an inconsistency on: nil check, on constructor, returning an error VS nil check, on process function, failing silently
If only that could be expressed in the type system. Instead, the programmer is now forced to think about these things everywhere over their entire codebase.
I very much like Go's simplicity, but nils are terrible. Pointers carry 3 different intents that are not encoded in the code: - Optionality - Mutability - Memory optimisation I agree with the author that when the pointer is here for mutability or to limit copies you need to check nullity at the outer layer. But for optionality you need to check it each time you access that value. Sometimes the intent is not clear and…
So the JSON APIs would accept nulls or absent keys when sending data to the API. But when retrieving it we would get golang default values for those keys. And, of course, the backend code was full of == 0, == "", == false...
Earlier quoted context omitted.
Oh, you can get the information at compile time as well. https://godbolt.org/z/hTYbTE8j8 (or https://godbolt.org/z/K1M68sY3Y but this will be tricky in a larger code base)
That's the reason language/compiler should directly support optionality. You can't fool yourself and have to handle all cases: https://godbolt.org/z/4GqMdPej3