251–260 of 281 posts
Earlier quoted context omitted.
Elixir is great, and I have recently started using it myself, but its not a substitute for Rust. Try writing device driver in Elixir, or anything CPU intensive.
GP said nothing of what they were building. Seems pretty probable it was a web service/application rather than a device driver.
Earlier quoted context omitted.
That's the most eloquently diplomatic way to address it. He really does have a way with words. At the same time, it makes me a little sad that when pressed, the best thing that could be said about Zig is that it's unapologetically weird right after a sentence about not agreeing with how they manage the project. I had high hopes for Zig, but the current situation feels like they're actively moving toward being a niche…
> moving toward being a niche language and away from being something that I could make a case for in a business context That indeed seems hard. Also, at this point in time, what would be the benefit of using Zig over Rust?
Earlier quoted context omitted.
I tried that, but the Rust build process was too painful, and agents seemed to burn a lot of tokens guessing how to get the code to compile. I rewrote my project in Elixir and it’s been going much more smoothly
You mean your LLMs had an easier time with Elixir. Do you actually know either of the two yourself?
Earlier quoted context omitted.
I tried that, but the Rust build process was too painful, and agents seemed to burn a lot of tokens guessing how to get the code to compile. I rewrote my project in Elixir and it’s been going much more smoothly
Elixir is great, and I have recently started using it myself, but its not a substitute for Rust. Try writing device driver in Elixir, or anything CPU intensive.
Earlier quoted context omitted.
> moving toward being a niche language and away from being something that I could make a case for in a business context That indeed seems hard. Also, at this point in time, what would be the benefit of using Zig over Rust?
Simplicity, and a much easier transition from C. Zig very much takes an "extend (or as they actually say: maintain) it with Zig" philosophy, rather than the classic "rewrite it in Rust". Zig integration with C rivals that of C++. Rust can do it, but it introduces a lot of friction by design, and that friction may or may not be desirable for a given project.
For the most part, I find Rust to be somewhat boring once you get past the initial learning curve of the borrow checker. It's almost uneventful code and reminds me a lot of writing code in F#.
The only area that Rust feels very friction-y can be with async programming, but basically no language except Erland and Elixir make that frictionless.
Earlier quoted context omitted.
$ podman image ls --all --sort=size …or was the point more about doing it in a pipeline?
Yes, the point was about doing it in a pipeline. The pipeline is the basis for composition of plain text in the unix shell. If something as basic as sorting a table is hard to do, it should make us question just how good the unix shell/plain text philosophy actually is. Baking --sort flags into shell tools is a sign that the tools do not compose well.
I don't think a `--sort` flag is a failure of composability, the producer understands image size semantics better than the sort command, you can either bake everything into sort, making it an all encompassing command or you can simplify the previous step with a sort flag.
Your original powershell command is way more verbose and complicated, and maybe that's the price to pay for composability, but I'd rather just use the `--sort` flag and not spend hours or days coming up with some other undocumented and undiscovered way of doing it, the answer is right there ready to be used.
I think my point is that it's a violation of the UNIX principle of doing one thing really well, but I don't think that is a violation of composability.
Earlier quoted context omitted.
0 because it's not supported. However I did write ADA and C for those.
> However I did write ADA and C for those. Ok, but recently? I too wrote code for obscure platforms once upon a time, but not in, say, the last 15 years. Now that PCs, game consoles, and mobile devices are basically all either amd64 or ARM, there's just not such a long tail of weird platforms to develop for. (the embedded world I will grant you, still lots of bespoke toolchains running around in that space)
Earlier quoted context omitted.
Yes, the point was about doing it in a pipeline. The pipeline is the basis for composition of plain text in the unix shell. If something as basic as sorting a table is hard to do, it should make us question just how good the unix shell/plain text philosophy actually is. Baking --sort flags into shell tools is a sign that the tools do not compose well.
I've spent some time thinking about it, and I respectfully disagree. I don't think a `--sort` flag is a failure of composability, the producer understands image size semantics better than the sort command, you can either bake everything into sort, making it an all encompassing command or you can simplify the previous step with a sort flag. Your original powershell command is way more verbose and complicated, and mayb…
Thanks for taking some time to think about it. Despite my pretty absolute wording in GP, I do think that there's nuance here. But what I want to drive home is that the tight coupling/brittleness inherent in plain text composition systematically limits composition.
What I'm not saying is that every --sort option is bad sign for composition. Like you point at, sometimes it's just a simpler UX to have such an option included with your command. As a matter of fact, you see that in PowerShell sometimes with the -Filter option on various cmdlets.
Plain text's brittleness limits composition by promoting exactly the extremes that you point at (the extremes being overloaded sort, or overloaded producer):
> the producer understands image size semantics better than the sort command, you can either bake everything into sort, making it an all encompassing command or you can simplify the previous step with a sort flag.
I think it should be obvious that baking everything into sort is a bad idea in the general case. Like you say, the producer understands the size semantics better. Moreover, the ergonomics are lousy (see comments by users alloyed and i15e).
Baking everything into --sort is bad because it limits sorting to the producer's own predefined semantics. While arguably better than relying on sort's, the producer won't always have the semantics that the user cares about. E.g. maybe the user wants to analyze the disk space used only on a certain datastore. Maybe some datastores do transparent compression and sorting should be done by physical disk usage. And so on.
These two extremes are basically your only options in a plain text world, but structured data gives you more opportunities for composition. By moving to structured data and eliminating the need for ad-hoc parsing, users and their code can operate at a higher semantic level. In particular, the loose coupling introduced by this approach gives you access to things like lambdas. You're not alone in objecting to PowerShell's verbosity. Here's a terser version that would work if podman image output structured data rather than text, thereby kinda steelmanning this position:
podman image ls --all |
sort {podman size -h $_.size} -d
An alternate version if no specialized podman size command is needed and the sort cmdlet would by default look at an object's size property:
podman image ls --all |
sort -d
Now, tools shouldn't always oblige the user to compose. Composition is frequently not the best UX. But a shell that systematically limits composition is prima facie worse than one that promotes it. And plain text shells do indeed limit composition.
Sorry for the essay.
Earlier quoted context omitted.
> moving toward being a niche language and away from being something that I could make a case for in a business context That indeed seems hard. Also, at this point in time, what would be the benefit of using Zig over Rust?
Simplicity, and a much easier transition from C. Zig very much takes an "extend (or as they actually say: maintain) it with Zig" philosophy, rather than the classic "rewrite it in Rust". Zig integration with C rivals that of C++. Rust can do it, but it introduces a lot of friction by design, and that friction may or may not be desirable for a given project.
Also languages do not exist in isolation, thus the question remains what product will drive Zig adoption, beyond its core community.