Elixir and Rust - Mea culpa, mea maxima culpa
July 21, 2024
I've been down on Rust lately. Unfairly so. I may even have said – what I totally did say was – "Rust is a terrible language for game development. Probably a terrible language for any app with a GUI right now. Again there are things to like, but more things not to."
Mea culpa, mea maxima culpa. Rust can be a terrible language. It can certainly be used terribly. Lord knows, I've tried. But for the right sort of problem. Where the solution to the problem's framed in the right sort of way… it can work well. It does have a lot going for it. More than I may have implied (than I totally, literally said).
Even if the only thing Rust had going for it was that it wasn't beholden for its existence to one of the giant tech companies that would still be a lot. C# is only ever going to be as open source as Microsoft wants it to be. Kotlin is only ever going to do what Google tells JetBrains to do with it, and theirs is the only Kotlin IDE in town. Swift got result builders because Apple wanted them, & when Apple says jump the answer isn't ever going to be anything but a gung ho "how high?" But the problem Rust is used to solve has to be framed just so.
All of the pain (& a lot of the payoff) in Rust revolves around its rules for references. Any number of read-only ones, or just the one at any one time if it's a mutable reference. Which is fine if the problem's simple. Or small. Or both. It gets harder to do when a problem's large & changing as it's solved, which is what happens often in game development, but it can probably be done.
Rust is not the solution to every problem, & it is galling – which was the source of my, ahem, recent outburst… s (plural) – to be forced to jump through hoops when the business logic prevents the kind of race condition this is all meant to prevent from ever occurring any way. But that's probably a function of breaking up the problem the wrong way. Possibly. It's a baby/bathwater situation, not any kind of breach.
There's a great explanation of ownership on without.boats I read recently, in References are like jumps, & Ownership, that I wouldn't even attempt to summarise here. Interestingly Mojo & Lattner come up again in the context of value semantics. Less flatteringly, as you might guess.
While I'm at it…
The Elixir community on Reddit sucked, but is probably not necessarily all that representative of the Elixir community generally. I have been tempted by the language once or twice again over the years since bad mouthing it here & flouncing away from it. I could never really find a problem big enough to warrant solving with what Elixir brings to the table, but small enough that it couldn't already be done with some combination of other more readily available tools though. Add Redis for caching, Systemd for restarts, or whatever, & most any server-side language can do what Elixir does without having to leave the mainstream behind. (This may not be helping…)
I used Elixir in anger when I self hosted an instance on the Fediverse. That was with Akkoma. I never dug too deeply into the code, & was luckily never personally a victim of "Akkoma Database Rot", where the database gradually falls apart because of some strange schema/JSON choices made with it, so while I don't think I'd recommend it, for the short time I ran it, it ran OK. It wasn't the problem with self hosting.
I did also write a toy Gemini server in Elixir for fun just the other week. But I also wrote one in C#, Go, Python, Ruby, Rust & Swift too. I was interested in playing around with how the different languages deal with TCP & TLS connections, & with the Gemini Protocol. This is Gemini the minimalistic Gopher-like set up, not Gemini the Google AI model. It's really a very small thing a Gemini server, perfect to play with.
But none of that makes me an Elixir developer any more than it makes me a Go developer. Just a curious one. That much hasn't changed.
Chris Lattner on Swift
July 14, 2024
Chris Lattner the original author of the Swift language has had a few things to say about it. Lattner's working on a new language called Mojo so he's out & about spruiking that.
The interview's on YouTube, and is worth watching in full, but the money quote on Swift to my mind starts at about 22 minutes, depending on ads & other annoyances, & it's worth quoting the man at length:
Swift, the original idea was factor complexity. So you have really powerful features that are available and accessible within the language, but you don't thrust them in peoples' face[s], you make it so that it's simple to get going then powerful as you dig in, and so progressive disclosure of complexity is this UI paradigm which is, you know, you can have powerful things that are simple to learn, but then enable power users to discover the power as they progress in their experience instead of thrusting all that complexity into their faces all at once…
that was a big focus of my work on Swift, a big focus of the early language. Massively failed in my opinion by the way. So massive lessons learned. Swift has turned into a gigantic, super complicated bag of special cases, special syntax, special stuff. It's all locally well intentioned…
it had a lot of internal technical debt because it was built very rapidly & we didn't expect the adoption to be so quick, & so the whole team was behind, & then instead of fixing the core what the team did – both when I was there, so partially my fault, but also subsequently – was they started adding all these special cases. There's also some things like SwiftUI added result builders & stuff like this. Result builders is a well intentioned meta programming thingy, you get rid of commas to make some code look better on a slide, right. So, a lot of the stuff got added under extreme time pressure to enable a feature like SwiftUI, & there are good aspects to it, but it's one of the reasons that Swift compile times are not great…
…Swift is still a beautiful language, it's amazing, & it's got a lot of really great things in it, but I can't say it's a simple language…
With apologies for any transcription errors on my part.
Now, he's said similar things before. I've said this sort of stuff before on this blog and elsewhere as a simple user of the language. My 2021 post still sums up the history of the language pretty well I feel. But to hear the man himself say it. Oof.
Matz is nice so we are nice
June 29, 2024
Well that didn't take long. Zine's back, & so, so is Ruby.
There's a lot to like about Python, but there's a lot not to. I will however keep it nice, Ruby is like that. Python has something of the same sort of problem that JavaScript does, it has a beginner coder problem. Python coders are perfectly good & clever people, but a big chunk of them haven't been writing code for very long, & it shows. Python in addition also has a lot of incidental coders, people for whom coding is something they only do on the way to getting their main job done. Again perfectly fine & often very clever people, but with no love of the craft, & keen to finish writing their code & get back to doing whatever it is they were actually trying to do. No matter how carefully I write, no matter how often I test, sooner or later my code's going to rely on theirs, & boom, bad things will happen.
It happened with this site. I was using Pelican, which is mostly OK, though it takes a LOT of configuration to get it to fly, but the code highlighting library it comes with, & the HTML minifying library I got recommended to use with it… Oh boy. Class attributes added to header tags. The head tags themselves minified out of existence. A hot mess.
So I still have some Python code I'm using, & I'm not hating on Python or Python coders, but Ruby's back, & so is Zine.
Choose yourself a language you like coding in & can rely on. Popularity doesn't even figure in that. I chased easy access to libraries & the monkey paw closed. My current thinking is the more unpopular the language the better the quality of the (small amount of) code there'll be out there to use. Up to a point I suppose.