Nothing fundamentally. Calls for restructuring the teams and making responsibilities clearer are old. E.g. here’s 2 posts from 2018, both focusing on that angle completely. https://yakshav.es/rust-2019-rethinking-the-team-structure/ (mine) https://without.boats/blog/rust-2019/ (boats)
I really love Swift (Smol Dungeon is written in it), so I’m glad to see Apple slowly pushing more and more pieces out to the open and written in Swift.
I’m not yet convinced Swift will ever really break free of Apple in any meaningful way, but moves like this are really encouraging.
Riding in what’s looking to be a cold, wet, muddy, cyclocross race.
One thing I miss almost on a daily basis in Go are enums. Using
iota is no proper replacement, it’s error prone and opaque. Also, you need a linter to check that all variants of the “enum” consts are covered in a switch-case expression. I am curious why they designed Go without support for enums. Was it because there is no support for union types (could not find any details about the design decision)?
I miss enums as well, the whole const & iota piece feels very magical and un-Go like in my opinion.
To me it perfectly fits Go’s idea of making the language small. Instead of an
enum which is a big-ish language feature focused on one thing, you get a tiny general-purpose
iota primitive that you can use to make yourself a DIY
enum or something else.
It’s the same idea as having multiple return values (a general purpose primitive) instead of more specific features for error handling.
enums are hardly a “big” language feature. They are simply essential. The number of
enums I write in an average application is tremendous - status codes, loading states, visual states, domain concepts - all are naturally “one of a set of values” that the enum is a 50 year old solution for.
iota is the same cost to the language as introducing an
enum concept! Only
iota is completely specific to Go, no one has ever seen a language construct used this way before, so it has even more cognitive overhead than just adding
“DIY enum” - that should be your clue. Go makes you write unnecessary code here. It’s a really bad choice.
Enums can grow into a bigger feature, e.g. they can be exhaustive or non-exhaustive, have unique non-int types (and related conversions), used as sets/bitfields, tied to switch statements (with other enum features making exhaustiveness checks difficult). Rust has also popularized sum types as enums, but that needs pattern matching, and works best with generics. Unless you do a half-assed job that C did, and Go didn’t want to repeat, it can easily grow to a big feature tied to other big features.
I’ve specifically compared this approach to error handling, because it’s also an essential feature, and yet it’s another DIY pattern in Go, and boilerplate it needs is a butt of jokes.
iota is by far the most enraging feature in Go. They take such pride in simplicity in the language, and argued for 10 years over generics when everyone knows it’s necessary with static types. But - they added by far the most idiosyncratic feature I’ve ever seen in a language:
iota. And, I watched a talk somewhere where Rob Pike said that was one of his most proud features!!
The problem is, I don’t see Go adopting pattern matching, so enums will be less useful. But regular C-style enums would even be extremely appreciated. I agree, it’s my most missed feature when writing Go.
I agree. What is also annoying is that
iota is so opaque and can be used in various inconsistent ways. All the forms below are equal, but luckily I never saw the last one in production. Personally I just prefer a mapping table over
iota, despite its runtime overhead.
const ( A1 = iota A2 A3 ) const ( B1 = iota B2 B3 = iota ) const ( C1 = iota C2 = iota C3 = iota ) const ( D1 = 0 _ D3 = iota D2 = iota - 2 )
Having really weak string support like this really kills a language’s ergonomics for me. Rust also blew it in this regard. I understand why for both Zig and Rust but it’s still disappointing.
Yeah, Rust string methods are as complete as any other language I know. Presumably kris meant that Rust strings are not ergonomic? Because borrow checker and String vs. &str vs. &mut str vs. whatever str is. (Which is all a necessary consequence of borrow checking and zero-cost abstractions, but that doesn’t make it less confusing to a beginner.)
I agree that it is confusing, but strings in general are hard, Rust just exposes that from the day one instead of pretending that everything is ASCII until it is not.
An immutable string type is just so convenient that’s it’s really hard to do justify doing string stuff in a language without it.
In Rust, immutable and mutable strings would have exactly the same API and would have the same ergonomics. The only difference between the two would be in performance
operation | “immutable” | “mutable” clone | O(1) | O(N) push char | O(log(N)) | O(1)
More work on https://littlefish.fish and some pixel art.
No concrete plan this weekend, I might noodle on https://littlefish.fish some or go through my notes and do some “project shopping”.
Sadly, it’s useless unless you’re talking to someone with the “Listening Attentively” Superpower.
IME, if this is a problem, turning it around and asking the other person questions about what you’re discussing is a way to both get them engaged in the topic, and identify gaps in their understanding so you can work towards filling them.
Not a perfect solution, of course, but questions are a powerful way to turn a passive listener into an engaged participant in the conversation.
This is part of communicating. The idea that you can just spew out the perfect set of sounds and everybody “worth your time” will just grok you is a sure sign of being a shitty communicator.
I’m a shitty communicator too, but at least I know it :)
Actually, step 0 is patience.
If somebody is overloaded or trying to do something or understand something…. Telling them what to do is useless. Your voice is just “Noise in their Head”.
If they have a bee stuck in their bonnet… you can talk until you blue in the face, all you will do is frustrate everybody.
Sometimes “Show, don’t Tell” will break the impasse.
Yeah, I think this is the point of the blog post. Even if somebody has the “Listening Attentively” superpower, and even if they are calm, collected and think they are getting it, it is still sometimes nigh-on impossible to “just tell” them anything.
Listening attentively also involves verifying what you’re hearing, repeating it back, in a sense, not just nodding your head. Truly listening well can effectively act as a parity check on the other persons’s ideas. Many folks don’t practice this sort of conversation, though, because it requires investing yourself in another person’s mental landscape, which isn’t often valued, outside of the therapy profession.
More experiments with my little ai project https://littlefish.fish and a sprint workout.
More noodling on my ai project https://littlefish.fish We tried playing D&D last week for the first time and it was fun so we’re gonna try continuing the campaign this weekend. I’ll def get some exercise and I’ll probably watch the Euro Cup finals.
Not yet :-) I’m not in a shape to run a race yet. But I’m working hard to be able to do it one day.
More work on my ai project littlefish. Last week I tried to improve performance by reducing memory allocations - the gains weren’t as big as I wanted (about 20% faster). Those changes added significant complexity to the program so I scrapped that work. Luckily, as a result of that work I did stumble into a small improvement in the quality of predictions.
I’ve got a few experiments I’d like to explore this weekend that might improve the quality of the pattern detection. I’m trying to keep the user experience as simple as possible: you put in some numbers and you quickly get quality numbers out.
More work on https://littlefish.fish and a trail run.
I’m working on a tiny AI project called littlefish, been really fun noodling in a domain I don’t have much experience in. There’s a public version anyone can play with at https://littlefish.fish
I wonder if we will see the next wave of dynamic languages soon. We got Rust, Swift, and Go in the last decade. I feel like there could be a great new Perl/Python/Ruby out there with some modern flavor.
It took Rust almost ten years to gain its momentum, so chances are good that the next Perl/Python/Ruby already exists
What “modern flavour” would you add to Python?
The main reason to switch to a new language is to add new inabilities.
I dunno, probably a lot of “historical baggage cleanup”. I’m reading through Crafting Interpreters so maybe I’ll just try to make it.
I hope so! Julia is pretty great but there’s plenty more space out there to explore.