If there is one thing that I find missing is proper enum support in the Go language.
There are quite a few subtle caveats you can run into without proper support in the language like the article mentions. (E.g. Using iota, passing in an undefined enum)
This might be a very simple and ignorant thought, but I'd be fine if they completely worked the same as Rust's enum's. [if let] is such a powerful feature, along with match arms.
Rust got those basic type system and pattern matching things so incredibly right it’s not even funny. I even like Go more for other reasons but I still cringe every time I have to use the error prone hacks mentioned in this post. Not to mention the largest source of noise: `if err != nil`, which Rust solved so elegantly using partly their enum types.
That’s not an enumeration like the parent and grandparent are discussing (think of a collection of consts), that’s a tagged union you’re talking about. Confusing because rust used the name enum in their syntax for this (Haskell calls it data - well, Haskell uses data in their syntax for both product and sum types).
What we're discussing here is always an actual sum type though, it's just a question of whether you're interested in half-assing it, and Rust is not.
There are people who want C's "surprise it's actually just an integer" which lets them use C's enums as bit flags, and that I agree isn't just a sum type, but the fact that Rust will let you sum things which aren't units isn't that this is "really" a tagged union, that's a possible implementation detail but not the core idea.
This is not C++ std::variant which really is just a tagged union. Option<OwnedFd> isn't a tagged union, it's "just" much nicer sugar for C's signed integer type. Option<&str> isn't a tagged union it's sugar for a fat pointer which can be null. And so on.
Sure, but "the same as Rust's enums" including a mention of pattern matching, is a really big expenditure on the novelty budget from the point of view of Go. What Rust does there is perfectly normal... for an ML. But before Rust you didn't really see an ML down there counting CPU cycles, so this wasn't even on the radar when Go was invented.
I think to do that you'd probably give up a lot of the simplicity Go is aiming for. I personally think that simplicity is somewhat illusion (Amos' "I want off Mr. Golang's Wild Ride" https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-... says it better than I could) but we should be clear that it's not that Go aimed to do what I want and missed but that it was never interested in that at all. An F1 car doesn't want to be useful for taking the kids to school, so it's silly if we're scoring it poorly for lack of child seat fixtures.
> Sure, but "the same as Rust's enums" including a mention of pattern matching, is a really big expenditure on the novelty budget from the point of view of Go.
Following the addition of type sets for generics I think go actually has all the pieces for union types already and it’s a matter of putting them all together at the compiler level:
- allow type sets as types (currently they’re only valid for constraints), probably excluding those using “underlying types”
- implement match completeness for type switches over type sets
And there you go, you’ve got unions from which you can easily implement sums via type declarations:
type Foo int
type Bar struct {}
type FooOrBar interface { Foo | Bar }
func Thing(v FooOrBar) {
switch vv := v.(type) {
case Foo:
// you have a foo
case Bar:
// you have a bar
// a default case is required if the cases are not exhaustive, forbidden if they are
}
}
Is this perfect? Not even remotely, this suffers from the usual Go issues of zero values, unenforceable constructors, and nil interfaces.
But these are issues of the language, they should be fixed in the language in a hypothetical Go 2, I don’t think there is a good reason to try and work around them here.
Also completeness requirements could probably be extended to all “trivial” switches (types or values, not generalised expressions) via a go.mod stricture, similar to the new loop semantics.
C# is basically a "Microsoft Java". They tried this already with J# and their own runtime, but then got sued and decided to make their own JVM but this time with blackjack... and hookers.
Microsoft Java makes it sound likes it's an inferior clone. Rather C# is Java reinvented with the benefit of hindsight, and improved with new concepts and sound language design from there.
Both languages have a too enterprisey ecosystem for my taste, but when given the choice between Java and C# I would take C# every time. Though modern Java certainly made efforts to catch up again.
> So how can AI usefully suggest design-level and conceptual ideas in a way that doesn’t require a user “trigger”?
I'm just guessing here. But maybe make it part of some other (already natural and learned) trigger made by the user.
I'm thinking part of refactoring. Were your AI is not only looking at the code, but the LSP, recent git changes (both commit and branch name), which code files you've been browsing.
And if you want to make it even more powerful. I guess also part of your browser history will be relevant (even if there is privacy concerns)
No, turns out there are enough other muscles/tendons pulling on it I haven't really missed it, there's nothing obvious I can't do with it - I suspect the ones that pull it down are more important than the ones that pull it up
The most of the students will not use it for improving their own text or iteration process, unless the penalties for cheating are very high. They instead copy-paste the instructions, add some adjustments, and then copy-paste the output. This will give them results in the shortest amount of time, if there are assignments where something needs to be returned. But how to detect cheaters?
Too many students do tasks as in "completion" oriented way, not in learning oriented way. I am mostly talking from college/university perspective.
Had similar issues as well. I use a Nordic layout for my keyboard (which includes åäö). These extra characters were a pain to bind certain key combinations to.
Been using preview versions of Aspire for a while now. At early stages there were a lot of bugs, but since preview 3 (or if it was 4) it's been pretty stable.
Adding services has also been really nice. I've even found my self not writing docker-compose files anymore.
Kind of hyped what upcoming versions of it will offer.
Be aware tho, be careful to use .Net 9 version of the packages as of now. They can be a bit iffy if you mix .net 8 packages with 9. It will probably be fixed very soon tho
