I don’t know why almost everybody descended from Unix is still so adamant that you only build for target X on target X. The only project I can think of going another way is Zig.
The deadlock ended up happening when the full http1 and http2 request were all included in the first Write call. With the 1ms sleep it is chunked up into multiple writes and then responses flow as expected. Tried a few things to better understand why it was locking, but eventually gave up :(
A program that can simulate all sorts of martial arts moves and visualize them with 3D characters. The program should also be able to rate and rank all known martial arts moves, and also use genetic algorithms to try to find even better moves.
XFS is quite popular in the server space if I’m not mistaken. At least at GitLab I believe it was the filesystem we ran for everything, though perhaps that has changed since I left.
Around 10 years ago, I chose XFS because it had features I needed that ext4 did not at the time. I don’t recall exactly what those were (64-bit inodes maybe?), but it also performed better with lots of small files, doesn’t require a fsck at pre-determined intervals. And it’s just been rock-solid. It’s like the Debian of filesystems.
It’s solid, stable and fast. It’s boring, but in a good way.
There is more seldom a disk check that delays the boot, compared to ext4. It did not have the raid issues btrfs had. And it’s not as experimental as bcachefs.
I’ve started using it for NixOS because it seems to cope better with its high demand for inodes than ext4 does. It also seems to be faster than btrfs, particularly in VMs for some reason.
My anecdotal evidence as a XFS user since XFSv4 (probably the last 6 years? I lost the count to be honest).
XFS used to be a filesystem only recommended for servers and other systems that had some kind of backup power system to ensure clean shutdown. I used in a desktop for a few months, until a system forced reboot mounted my system read-only, and xfs_repair completely corrupted the file system. But even before that I lost a few files thanks to forced shutdowns. Well, went back to Ext4, and stayed there for a few years.
After trying btrfs and getting frustrated with performance (this was before NVMe were common, so I was using a SATA SSD), I decided to go back to XFS and this time not only it solved my performance issues, I hadn’t have problems with corruption or missing files anymore. The file system is simple rock solid. So I still use it by default, unless I want some specific feature (like compression) that is not supported in XFS.
It’s a popular filesystem in some low-latency storage situations such as with Seastar-based software like ScyllaDB here and Redpanda.
We use it at work for our Clickhouse disks. If we could start over I’d have probably gone with ext4 instead as that’s what Clickhouse is mainly tested on. There was some historic instability with XFS but it seems to have gotten better (partly with updates, partly with tuning on our end to minimise situations where the disk is under high load). Like most things XFS is a good choice if your software is explicitly tested against it.
At the time I chose XFS several years ago, I wanted to be able to use things like reflinks without needing to use btrfs (which is pretty stable these days but I wasn’t very confident in it back then). I can certainly say that’s it’s been quite resilient, even with me overflowing my thin pool multiple times (I am very good at disk accounting /s) and throwing a bunch of hard shutoffs at it.
If you often have problems filling up your disk, you are going to have a very, VERY bad time on btrfs. Low disk space handling is NOT stable in btrfs. In fact it is almost non-existent.
After 15 years, btrfs can still get into situations where you’re getting screwed by its chunk handling and have to plug a USB drive in to give it enough free space to deallocate some stuff. Even though df / reports (<10 but >1) gigabytes of free storage. This blog post was 9 years old when I consulted it, and I still needed all the tips in it.
I find it unconscionable that Fedora made btrfs the default with this behavior still not fixed. I will never, ever be putting a new system on btrfs again.
I find it unconscionable that Fedora made btrfs the default with this behavior still not fixed. I will never, ever be putting a new system on btrfs again.
100% this.
I have had openSUSE self-destruct 5 or 6 times in a few years because snapper filled the disks with snapshots and Btrfs self-destructed.
For me the killer misfeatures are this:
Self-destructs if the volume fills up
Volumes are easy to fill by accident because df does not give accurate or valid numbers on Btrfs
There is no working equivalent of fsck and the existing Btrfs-repair tool routinely destroys damaged volumes.
Any one of those alone would be a deal-breaker. Two would rule it straight out. All 3 means it’s off the table.
Note: I have not yet even mentioned the multiple problems with multi-disk Btrfs volumes.
I have raised these issues internally and externally at SUSE; they were dismissed out of hand, without discussion.
Thank you! Count me along with the camp of “btrfs is great except for when you really need it to be” — low disk being one of those times (high write load being my personal burn moment)
I wanted bcachefs to work but this and related articles are keeping me away from it too.
I force my Fedora installs to ext4 (sometimes atop lvm) and move on with my life :shrug:
This is why I bite the out of tree bullet and just use ZFS. People tell me I’m crazy for running ZFS instead of Btrfs on single disk systems like my laptop, but like, no! I cannot consider Btrfs reliable in any scenario.
100% agree. I have found DKMS ZFS to be more stable than in-tree btrfs. Other than one nasty deadlock problem years ago it’s been rock solid. (Just some memory accounting weirdness…)
Yeah, I still get bitten by that one once or twice a year. I find btrfs useful for container pools, etc, but I still don’t use it for stuff I can’t easily regenerate.
Count me among the XFS users, albeit only on one machine at this point. I think I set up my current home server (running Fedora) around the same time Red Hat made XFS the default for RHEL, and I wanted to be E N T E R P R I S E. I’ll likely use Btrfs for my next build, as I have for all my laptops and random desktop machines in recent years. Transparent compression is very nice to have.
EDIT: I believe Fedora Server also defaults to XFS, or at least it did at some point.
Last time I mkfs’d (going back a few years now) it had dynamic sized xattr support, and ext4 set a fixed size at creation time. This was important for me at the time for preserving macOS metadata.
This article ignores a ton of issues with go: sum types, horrendous slice type that doesn’t distinguish between vectors and slices, no support for immutability, zero thought about zero values’ ergonomics combined with channels breaking the moment you send nil. Even stuff it addresses, it only does partially: the issue with errors in go is really that it’s easy too easy to handle them incorrectly, either forgetting to handle them or accidentally falling through after doing so. Exceptions are horrible because it’s easy to silently ignore them, yet go does the same mistake all over again. Also, swift doesn’t use exceptions, it uses errors as values, just making it look like exceptions (throw it’s basically just return Err() and try is the same as rust’s question mark operator). I don’t care much about the FFI story as I think the current FFI system is pretty horrible itself, but all the aforementioned stuff is bad enough already to just call Go poorly designed. If you like Go, use it, no one’s stopping you from doing so, just don’t pretend that ist’s a well designed language
If you like Go, use it, no one’s stopping you from doing so, just don’t pretend that ist’s a well designed language
“Go has flaws, thus it is not a well designed language”. By this logic, I posit there are no well-designed languages. It’s probably better to dispense with this “flaws, thus not well designed” logic in favor of one which weighs the cons agains the pros. It’s also very likely that different people will assign different weights to the pros and cons, so that someone who cares singularly about sum types and is willing to forsake all other affordances toward productivity will find Go to be a poorly designed language but other people who prize productivity will consider Go to be a well-designed language.
someone who cares singularly about sum types and is willing to forsake all other affordances toward productivity will find Go to be a poorly designed language but other people who prize productivity will consider Go to be a well-designed language.
You’re making it sound like it’s an “either-or” situation. You can design a language with sum types and add as many affordances towards productivity as you want. There is no reason the presence of sum types shouldn’t cause a negative impact towards productivity.
By this logic, I posit there are no well-designed languages.
Yes. There’s no well-designed language for all purposes. All of them have trade-offs, that different people weigh differently.
You’re making it sound like it’s an “either-or” situation. You can design a language with sum types and add as many affordances towards productivity as you want. There is no reason the presence of sum types shouldn’t cause a negative impact towards productivity.
I think you misread the quote. In particular, I took special care to say “all other affordances toward productivity”. I agree with you that sum types do not negatively impact productivity.
I have found in the last few years that I am singularly more productive with access to even a fake version of algebraic data types and exhaustive case analysis (e.g. Python with mypy and frozen dataclasses). It’s not just an amusing academic exercise; it makes it easier to write, modify, and test(!) code.
Golang doesn’t clearly distinguish between a growable array that owns an allocation on the heap (what Rust calls a Vec) and a variable-size segment of an array that refers to someone else’s memory (what Rust calls a slice). (C and C++ programs make this distinction too, it isn’t a Rust thing.) Golang doesn’t help the programmer to keep track of aliasing and mutability, and for slices it also doesn’t help the programmer to know when it’s safe to append. When you get this wrong it can lead to weird symptoms that are hard to understand and difficult to predict because they depend on how slices overlap and the capacity of the allocation that they share.
YES! Thank you, I was trying hard to put this into words and couldn’t. To address the other two points, consts can’t be assigned a non-const type, so they are basically useless to make immutable bindings and zero values instead of ensuring the variable is initialised and making it a compiler error if it’s not in some branch is just laziness of the language devs not willing to increase the compiler complexity and in no way a good language design decision
consts are very different than immutable variables. consts can only be certain types, it’s impossible to have array, map or struct constants. It’s also impossible to take the address of a constant.
consts aren’t immutable variables, they’re their own special case with entirely different semantics. They’re immutable, yeah, but they’re not at all like immutable variables.
Declares variables and steucts have zero values instead of being left undefined. Yes, pointers can be nil, but zero values have been thought of.
They have been thought of, but @WeeHet’s point is that it almost seems that major issues with the ergonomics of zero-as-default have not been thought of. I don’t experience the case that they describe, but I run into the simpler case of it being impossible to distinguish between an intentional zero value and an “uninitialized” value all the time. I end up using pointers just as a poor man’s Option everywhere.
Another weird case that I’ve run into is sending on a nil channel (the zero value of a channel) just silently blocking forever. I’d love some kind of error for this case rather than this behavior, or ideally it being impossible to create a nil channel.
Keep in mind that AUR is, from the point of view of Arch Linux, unofficial and not part of the Arch Linux distro. Also note that Arch Linux ARM is an excellent, but separate, project. Arch Linux may support more architecures in the future, though.
Sure, if you don’t mind your mainline kernel not being updated for half a year at a time with no communication whatsoever and no way to actually change anything about this. Also no way to report bugs, except scream into a phpBB2 forum.
ALARM is in fact so bad, Asahi moved away from it and publicly blasted it for how dead it is.
Arch Linux ARM has always worked fine when I’ve tried it, but these are all fair points.
My main message though, for people that might not be aware of it, is that Arch Linux ARM is a separate distro from Arch Linux. And AUR is also separate.
The packages on AUR are not official packages. They are not enabled or made available in Arch Linux by default. Users will have to actively choose to use packages from AUR.
AUR is not part of the Arch Linux distribution. For example, it does not come with the ISO file that users can download when they choose to download and install Arch Linux.
aur.archlinux.org and archlinux.org share the same domain, and there is some overlap of people working on both, but they are different projects / sub-projects.
There are arguments both for and against AUR also supporting other architectures than x86_64:
Arch Linux is x86_64 only. AUR had Arch Linux in mind when it was started, so it makes sense if they support the same architectures as Arch Linux supports.
If someone wants AUR to support more architectures, they can create their own AUR software that supports this. Heck, since aurweb is open source, they can just deploy it to a new server.
Managing all the AUR packages is a lot of volunteer work. It is understandable if only some architectures are supported.
aarch64, RISC-V and friends are the future, so both Arch Linux and AUR should move to support them. AUR should lead the way by supporting multiple architectures first.
Arch Linux ARM, being a separate distro from Arch Linux, should set up their own AUR instance for all the architectures that they wish to support.
(I’m not neccessarily for or against any of these points, I just tried to list all the pros and cons I could think of).
If someone wants AUR to support more architectures, they can create their own AUR software that supports this. Heck, since aurweb is open source, they can just deploy it to a new server.
This one has at least two follow up points too.
AUR helpers (which, whether you like it or not, is how most users consume PKGBUILDs from AUR) could be patched to swap AUR instance endpoint, or support two AURs alltogether.
The latter would create further complexity inside the dependency resolving module. [1]
and also
it might be pertinent to accept that aurweb is de facto a code forge, just highly specialized.
[1] compare and contrast to the drama around the hardcoded flake registry inside nix.
Keep in mind that AUR is, from the point of view of Arch Linux, unofficial and not part of the Arch Linux distro.
Exactly, why then AUR maintainers have decided to gate keep out packages that soon will be there anyway? IMHO the optics of removals are terrible. It just creates friction to the soon to be your users, comes as prideful, and frankly bit disrespectful.
It’s even more surprising because usually Arch as whole is on point and avoid visible drama.
I have the impression that the hunt for theoretical beauty often starts with Haskell, Agda, Prolog, maths, NixOS, declarative statements and abolishing systemd, but ends up with Arch Linux, a simple DE like Xfce4, embracing/ignoring systemd, using PostgreSQL and a practical programming language like Lua, Go, C# or Odin.
I came to Nix from a practical and serious software engineering background. I’ve never had a better experience with a Linux distribution than this.
Nix goes beyond just “beauty”, it’s stupidly practical and it allows me to do things I never before imagined in days what would previously have taken me months.
For a single machine / environment, quite possibly, yeah, but I find configuration management gets out of hand very quickly once you go beyond that, and none of the mainstream tools really address that problem well - they just seem to move the faff and complexity around a bit.
I’m middle aged now and not in perfect health, and can definitely feel my ability to learn new stuff fading. I’ve sort of accepted my chances of acquiring a new programming language are ebbing away, but I’m giving learning nix a damned good shot because it seems to solve quite a few of my personal issues with technology.
(That’s not to say, however, that the tooling isn’t infuriating in many ways - but I reckon the inconvenience will be worth it!)
I dunno I think ansible and chef are still pretty decent at config management. The Chef model is the model that I like, but the fact that it’s in Ruby is a big drag since nobody under 35 or so knows Ruby. Ruby is Perl for millenials.
When you learn nix I think it’s helpful to get to grips with the nix language first as a regular programming language. Enough to know how to solve simple problems, transform data structures, etc. That way when you start using it to declare config, you stand a good chance of being able to understand what the config code is doing. Whereas if you start by building up a nixos config without understanding the language, you’ll not really be able to get yourself out of trouble without trial and error/copy-pasting example configs.
Something I found tricky is that because it’s a lazy language, you can’t just evaluate your entire config to dump out its representation. I think it’s worth the effort to learn!
I’ve seen photos of it, but never bothered to learn more. Thanks for mentioning it, it looks pretty cool! Surprised to see it was made by Panic, who are (at least to me) known for macOS&iOS dev-specific apps and utilities.
UPD: Oh, apparently Panic is also a video game publisher! One of the games I really enjoyed was Firewatch, which TIL was published by them. Untitled Goose Game is also fun.
LÖVE expects these files exists and panics (calls error) if they don’t.
This is fine because in a game, you should be able to expect all the required files exist. If you still want to handle the error, you can use pcall as shown in the blog post.
I think this will be great, but will they have the restraint to add too many features over time and the stamina to maintain it over time? Only time will tell. Best of luck.
Submitted a paper to CVPR but I realized that my project management and time management are really terrible. Any tips specifically for software engineering projects? How do you manage 2-3 engineers on a right deadline?
Zig doesn’t have default function parameters, only default fields.
It could additionally support optional&default function parameters, but that would make the language more complex for relatively little benefit, given that field defaults address this use-case well enough. It is reasonable to disagree with this particular cost-benefit analysis, but that’s what Zig chose.
It used to be the case e.g. with formatting functions. It was deliberately changed as it was deemed better to be explicit about argument lists if I recall.
For embedded systems, the Linux kernel, busybox (comes with an init system) and an ssh server is usually most of what one needs, distrowise. I don’t understand the frustration with systemd in this context.
What are the two situations you’re comparing the readability of?
Imagine a custom iterable type, like a b-tree. The new situation this feature permits is one function defining an iterator and many for loops that use it. The two prior alternatives are:
Inlining the iteration code at every for loop that wants to iterate. This works fine for simple types, but would be a repetitive mess for more complex iterators like b-trees.
Defining a custom iteration function, that’s called like a regular function and can’t be used in a for loop. It’s slightly simpler to define the iteration function, but it makes the use sites more complicated (no for loop, no break, no continue).
Which of these things are you comparing the readability of?
Yeah. A third consideration is, given some data structure, how do I iterate over it? The golang standard library has several different ad-hoc iteration protocols, so each time you have to read the documentation carefully to get the details right.
I’ve written more Rust than I care to divulge, but I’ve only hit a bug related to this issue once: and it was entirely because it was a hobby project in which I was ignoring warnings. If I’d checked the warnings, it would have been obvious when I wrote it.
Replace “Rust” with almost any other language and post it in a Rust forum and I promise you that this argument will be hammered down quicker than you can say “borrow checker”.
Note that the issue you linked has an accepted proposal to completely eliminate the footgun from the language. No lint, no naming-convention-based workaround. According to the milestone assigned to the issue, that’s expected to land in 0.15.0, or earlier if a contributor steps up and does the work before the core team gets around to it.
I can’t help but notice that it was at one time or another also part of the 0.7, 0.8. 0.9, 0.10, 0.11, 0.12, 0.13, and 0.14 milestones… has something changed with the project management to make the milestone fields a more reliable indicator?
Either way, I don’t want to take away from the main point that it’s a known issue in a pre-1.0 language with a planned and principled fix.
No not really. The amount of issues solved per release is fairly consistent however. I use those milestones to make sure and visit each issue before tagging the respective release, even if the issue ends up being postponed. That said I have been more aggressively using the “unplanned” milestone lately.
I don’t know anything about game development and design, but I’m
wondering: some time ago there was this hot language called Haxe, which
was positioned as a go-to language for gamedev. Is it still the case?
Gamedev often seems like a totally separate world. You don’t have a lot of dependencies, and overlap with open source parts is much reduced compared to almost anything else out there, apart from fiddling around with PLCs…
Haxe seemed to embody that, with public discussion not being a very good mirror of its actual use. I mean, you know what open source games are built with, you might know what AAA games are using. But what’s in that slot machine? What powers this online game with the annoying fanservice avatars?
A few years back, it seemed Haxe was a common answer. It’s very hard to tell if you’re not deep inside that “scene”, whether that’s still the case. But IIRC, it never was regarded as a general solution, mostly for 2D games and being able to write your PHP server components with the same syntax as your JS or Flash parts.
I wish there were benchmarks comparing the cognitive overhead of various programming languages.
Wouldn’t those have to be very much tailored to specific individuals? I feel like I experience near-zero cognitive overhead for some things that colleagues find carry an unmanageable amount of cognitive overhead sometimes, and sometimes vice versa.
Sort of the same way different natural languages are easier or harder for people of different backgrounds to learn.
Or is there some general metric you think might apply broadly?
I agree: this is something I have thought about, and I’m curious to know what others think a good benchmark for comparing the cognitive overhead of various programming languages would necessarily look like?
Would this benchmark be an empirical study of some sort? E.g., I could imagine showing developers a short fragment of a larger unknown codebase (written in a language they know), asking these developers to recreate the fragment from memory, and comparing say fragment length to recreation accuracy (using e.g. parse tree edit distance?) across programming languages.
Or do you have a different type of approach in mind? Say more theoretically motivated, e.g. coming up with some sort of cross-language mechanical metric (think cyclomatic complexity) that measures some sort of cognitive overhead score (symbols in scope / etc.) for each part of a program?
How does one even define cognitive overhead? So many questions I guess.
I don’t know why almost everybody descended from Unix is still so adamant that you only build for target X on target X. The only project I can think of going another way is Zig.
Go, Python, Java, C#, Rust etc. all care about either cross compilation or running on multiple platforms.
Wonder where there is a missing mutex or waitgroup.
The deadlock ended up happening when the full http1 and http2 request were all included in the first Write call. With the 1ms sleep it is chunked up into multiple writes and then responses flow as expected. Tried a few things to better understand why it was locking, but eventually gave up :(
A program that can simulate all sorts of martial arts moves and visualize them with 3D characters. The program should also be able to rate and rank all known martial arts moves, and also use genetic algorithms to try to find even better moves.
People are still using xfs? Is there a reason for that?
It’s fast and it has a clear codebase with great authors. For a classic filesystem, XFS is still my choice over ext4.
Although fedora comes with btrfs which has worked great. Raid1 with compression.
I wish all the luck for Kent. I’ll be coming back to bcachefs in a few years.
XFS is quite popular in the server space if I’m not mistaken. At least at GitLab I believe it was the filesystem we ran for everything, though perhaps that has changed since I left.
Around 10 years ago, I chose XFS because it had features I needed that ext4 did not at the time. I don’t recall exactly what those were (64-bit inodes maybe?), but it also performed better with lots of small files, doesn’t require a fsck at pre-determined intervals. And it’s just been rock-solid. It’s like the Debian of filesystems.
It’s solid, stable and fast. It’s boring, but in a good way.
There is more seldom a disk check that delays the boot, compared to ext4. It did not have the raid issues btrfs had. And it’s not as experimental as bcachefs.
I’ve started using it for NixOS because it seems to cope better with its high demand for inodes than ext4 does. It also seems to be faster than btrfs, particularly in VMs for some reason.
My anecdotal evidence as a XFS user since XFSv4 (probably the last 6 years? I lost the count to be honest).
XFS used to be a filesystem only recommended for servers and other systems that had some kind of backup power system to ensure clean shutdown. I used in a desktop for a few months, until a system forced reboot mounted my system read-only, and
xfs_repaircompletely corrupted the file system. But even before that I lost a few files thanks to forced shutdowns. Well, went back to Ext4, and stayed there for a few years.After trying btrfs and getting frustrated with performance (this was before NVMe were common, so I was using a SATA SSD), I decided to go back to XFS and this time not only it solved my performance issues, I hadn’t have problems with corruption or missing files anymore. The file system is simple rock solid. So I still use it by default, unless I want some specific feature (like compression) that is not supported in XFS.
It’s a popular filesystem in some low-latency storage situations such as with Seastar-based software like ScyllaDB here and Redpanda.
We use it at work for our Clickhouse disks. If we could start over I’d have probably gone with ext4 instead as that’s what Clickhouse is mainly tested on. There was some historic instability with XFS but it seems to have gotten better (partly with updates, partly with tuning on our end to minimise situations where the disk is under high load). Like most things XFS is a good choice if your software is explicitly tested against it.
It’s (was?) the default filesystem in at least RHEL/CentOS.
At the time I chose XFS several years ago, I wanted to be able to use things like reflinks without needing to use btrfs (which is pretty stable these days but I wasn’t very confident in it back then). I can certainly say that’s it’s been quite resilient, even with me overflowing my thin pool multiple times (I am very good at disk accounting /s) and throwing a bunch of hard shutoffs at it.
If you often have problems filling up your disk, you are going to have a very, VERY bad time on btrfs. Low disk space handling is NOT stable in btrfs. In fact it is almost non-existent.
After 15 years, btrfs can still get into situations where you’re getting screwed by its chunk handling and have to plug a USB drive in to give it enough free space to deallocate some stuff. Even though
df /reports (<10 but >1) gigabytes of free storage. This blog post was 9 years old when I consulted it, and I still needed all the tips in it.I find it unconscionable that Fedora made btrfs the default with this behavior still not fixed. I will never, ever be putting a new system on btrfs again.
100% this.
I have had openSUSE self-destruct 5 or 6 times in a few years because
snapperfilled the disks with snapshots and Btrfs self-destructed.For me the killer misfeatures are this:
dfdoes not give accurate or valid numbers on Btrfsfsckand the existing Btrfs-repair tool routinely destroys damaged volumes.Any one of those alone would be a deal-breaker. Two would rule it straight out. All 3 means it’s off the table.
Note: I have not yet even mentioned the multiple problems with multi-disk Btrfs volumes.
I have raised these issues internally and externally at SUSE; they were dismissed out of hand, without discussion.
Thank you! Count me along with the camp of “btrfs is great except for when you really need it to be” — low disk being one of those times (high write load being my personal burn moment)
I wanted bcachefs to work but this and related articles are keeping me away from it too.
I force my Fedora installs to ext4 (sometimes atop lvm) and move on with my life :shrug:
This is why I bite the out of tree bullet and just use ZFS. People tell me I’m crazy for running ZFS instead of Btrfs on single disk systems like my laptop, but like, no! I cannot consider Btrfs reliable in any scenario.
I’ve been using ZFSBootMenu on my Fedora single disk laptops for a while now and find it hard to imagine a different setup.
100% agree. I have found DKMS ZFS to be more stable than in-tree btrfs. Other than one nasty deadlock problem years ago it’s been rock solid. (Just some memory accounting weirdness…)
Yeah, I still get bitten by that one once or twice a year. I find btrfs useful for container pools, etc, but I still don’t use it for stuff I can’t easily regenerate.
Count me among the XFS users, albeit only on one machine at this point. I think I set up my current home server (running Fedora) around the same time Red Hat made XFS the default for RHEL, and I wanted to be E N T E R P R I S E. I’ll likely use Btrfs for my next build, as I have for all my laptops and random desktop machines in recent years. Transparent compression is very nice to have.
EDIT: I believe Fedora Server also defaults to XFS, or at least it did at some point.
Last time I mkfs’d (going back a few years now) it had dynamic sized xattr support, and ext4 set a fixed size at creation time. This was important for me at the time for preserving macOS metadata.
This article ignores a ton of issues with go: sum types, horrendous slice type that doesn’t distinguish between vectors and slices, no support for immutability, zero thought about zero values’ ergonomics combined with channels breaking the moment you send nil. Even stuff it addresses, it only does partially: the issue with errors in go is really that it’s easy too easy to handle them incorrectly, either forgetting to handle them or accidentally falling through after doing so. Exceptions are horrible because it’s easy to silently ignore them, yet go does the same mistake all over again. Also, swift doesn’t use exceptions, it uses errors as values, just making it look like exceptions (
throwit’s basically justreturn Err()and try is the same as rust’s question mark operator). I don’t care much about the FFI story as I think the current FFI system is pretty horrible itself, but all the aforementioned stuff is bad enough already to just call Go poorly designed. If you like Go, use it, no one’s stopping you from doing so, just don’t pretend that ist’s a well designed language“Go has flaws, thus it is not a well designed language”. By this logic, I posit there are no well-designed languages. It’s probably better to dispense with this “flaws, thus not well designed” logic in favor of one which weighs the cons agains the pros. It’s also very likely that different people will assign different weights to the pros and cons, so that someone who cares singularly about sum types and is willing to forsake all other affordances toward productivity will find Go to be a poorly designed language but other people who prize productivity will consider Go to be a well-designed language.
You’re making it sound like it’s an “either-or” situation. You can design a language with sum types and add as many affordances towards productivity as you want. There is no reason the presence of sum types shouldn’t cause a negative impact towards productivity.
Yes. There’s no well-designed language for all purposes. All of them have trade-offs, that different people weigh differently.
I think you misread the quote. In particular, I took special care to say “all other affordances toward productivity”. I agree with you that sum types do not negatively impact productivity.
I have found in the last few years that I am singularly more productive with access to even a fake version of algebraic data types and exhaustive case analysis (e.g. Python with mypy and frozen dataclasses). It’s not just an amusing academic exercise; it makes it easier to write, modify, and test(!) code.
I agree. I think you may have misread or misunderstood my comment.
Golang doesn’t clearly distinguish between a growable array that owns an allocation on the heap (what Rust calls a Vec) and a variable-size segment of an array that refers to someone else’s memory (what Rust calls a slice). (C and C++ programs make this distinction too, it isn’t a Rust thing.) Golang doesn’t help the programmer to keep track of aliasing and mutability, and for slices it also doesn’t help the programmer to know when it’s safe to append. When you get this wrong it can lead to weird symptoms that are hard to understand and difficult to predict because they depend on how slices overlap and the capacity of the allocation that they share.
I don’t think you can say that C makes this distinction.
Yeah, that’s why I phrased it as the programs making the distinction not the languages. I can be quite pedantic.
Ah, yeah, fair enough.
YES! Thank you, I was trying hard to put this into words and couldn’t. To address the other two points, consts can’t be assigned a non-const type, so they are basically useless to make immutable bindings and zero values instead of ensuring the variable is initialised and making it a compiler error if it’s not in some branch is just laziness of the language devs not willing to increase the compiler complexity and in no way a good language design decision
Not the OP, but…
consts are very different than immutable variables. consts can only be certain types, it’s impossible to have array, map or struct constants. It’s also impossible to take the address of a constant.
https://go.dev/ref/spec#Constants
https://go.dev/play/p/WKJLMxudZZk
consts aren’t immutable variables, they’re their own special case with entirely different semantics. They’re immutable, yeah, but they’re not at all like immutable variables.
They have been thought of, but @WeeHet’s point is that it almost seems that major issues with the ergonomics of zero-as-default have not been thought of. I don’t experience the case that they describe, but I run into the simpler case of it being impossible to distinguish between an intentional zero value and an “uninitialized” value all the time. I end up using pointers just as a poor man’s
Optioneverywhere.Another weird case that I’ve run into is sending on a
nilchannel (the zero value of a channel) just silently blocking forever. I’d love some kind of error for this case rather than this behavior, or ideally it being impossible to create anilchannel.time.Timer comes to mind. The implementation internally tests for whether something has been zero-as-initialization. But sync.Mutex.
This is not consistent even inside the standard library itself.
Keep in mind that AUR is, from the point of view of Arch Linux, unofficial and not part of the Arch Linux distro. Also note that Arch Linux ARM is an excellent, but separate, project. Arch Linux may support more architecures in the future, though.
Sure, if you don’t mind your mainline kernel not being updated for half a year at a time with no communication whatsoever and no way to actually change anything about this. Also no way to report bugs, except scream into a phpBB2 forum.
ALARM is in fact so bad, Asahi moved away from it and publicly blasted it for how dead it is.
Arch Linux ARM has always worked fine when I’ve tried it, but these are all fair points.
My main message though, for people that might not be aware of it, is that Arch Linux ARM is a separate distro from Arch Linux. And AUR is also separate.
Unless I’m missing something terribly obvious, it’s false.
It is true, but I could be more specific:
The footer of the aur.archlinux.org says:
While the footer of the archlinux.org page says:
Oh, I’ve read it as “ALARM has their own separate A(LARM)UR”.
But then the fact that AUR is separate from the Arch proper should be even further argument against removing ARM-only PKGBUILDs.
There are arguments both for and against AUR also supporting other architectures than
x86_64:x86_64only. AUR had Arch Linux in mind when it was started, so it makes sense if they support the same architectures as Arch Linux supports.aarch64,RISC-Vand friends are the future, so both Arch Linux and AUR should move to support them. AUR should lead the way by supporting multiple architectures first.(I’m not neccessarily for or against any of these points, I just tried to list all the pros and cons I could think of).
This one has at least two follow up points too.
and also
[1] compare and contrast to the drama around the hardcoded flake registry inside nix.
Exactly, why then AUR maintainers have decided to gate keep out packages that soon will be there anyway? IMHO the optics of removals are terrible. It just creates friction to the soon to be your users, comes as prideful, and frankly bit disrespectful.
It’s even more surprising because usually Arch as whole is on point and avoid visible drama.
I have the impression that the hunt for theoretical beauty often starts with Haskell, Agda, Prolog, maths, NixOS, declarative statements and abolishing systemd, but ends up with Arch Linux, a simple DE like Xfce4, embracing/ignoring systemd, using PostgreSQL and a practical programming language like Lua, Go, C# or Odin.
I came to Nix from a practical and serious software engineering background. I’ve never had a better experience with a Linux distribution than this.
Nix goes beyond just “beauty”, it’s stupidly practical and it allows me to do things I never before imagined in days what would previously have taken me months.
Like what though?
For a single machine / environment, quite possibly, yeah, but I find configuration management gets out of hand very quickly once you go beyond that, and none of the mainstream tools really address that problem well - they just seem to move the faff and complexity around a bit.
I’m middle aged now and not in perfect health, and can definitely feel my ability to learn new stuff fading. I’ve sort of accepted my chances of acquiring a new programming language are ebbing away, but I’m giving learning nix a damned good shot because it seems to solve quite a few of my personal issues with technology.
(That’s not to say, however, that the tooling isn’t infuriating in many ways - but I reckon the inconvenience will be worth it!)
I dunno I think ansible and chef are still pretty decent at config management. The Chef model is the model that I like, but the fact that it’s in Ruby is a big drag since nobody under 35 or so knows Ruby. Ruby is Perl for millenials.
When you learn nix I think it’s helpful to get to grips with the nix language first as a regular programming language. Enough to know how to solve simple problems, transform data structures, etc. That way when you start using it to declare config, you stand a good chance of being able to understand what the config code is doing. Whereas if you start by building up a nixos config without understanding the language, you’ll not really be able to get yourself out of trouble without trial and error/copy-pasting example configs.
Something I found tricky is that because it’s a lazy language, you can’t just evaluate your entire config to dump out its representation. I think it’s worth the effort to learn!
This week I’ve been playing with Love2D, a simple game engine, wrote a prototype in Lua, and found it a refreshingly clear and a pleasant language.
Btw, the game Balatro - which is amazing IMO - is written in Lua on Love2D.
Balatro is awesome.
Have you seen the Playdate console? Its SDK is Lua based and should feel familiar to Love.
I’ve seen photos of it, but never bothered to learn more. Thanks for mentioning it, it looks pretty cool! Surprised to see it was made by Panic, who are (at least to me) known for macOS&iOS dev-specific apps and utilities.
UPD: Oh, apparently Panic is also a video game publisher! One of the games I really enjoyed was Firewatch, which TIL was published by them. Untitled Goose Game is also fun.
What’s the error handling like, after having tried it out for a while?
I notice that the examples just loads from file like this:
whale = love.graphics.newImage("whale.png")and:
sound = love.audio.newSource("music.ogg", "stream").LÖVE expects these files exists and panics (calls
error) if they don’t.This is fine because in a game, you should be able to expect all the required files exist. If you still want to handle the error, you can use
pcallas shown in the blog post.To my relief, this post is not about someone using AI to generate eternal discussions about adding Rust to Git.
I think this will be great, but will they have the restraint to add too many features over time and the stamina to maintain it over time? Only time will tell. Best of luck.
I’ll try Odin this year.
For anyone with even just a tiny bit of interest in graphics programming, this article is a treat.
Swimming, spending time with family, building a shower cabinet, playing Go and Bannerlord.
Submitted a paper to CVPR but I realized that my project management and time management are really terrible. Any tips specifically for software engineering projects? How do you manage 2-3 engineers on a right deadline?
Features, quality and being on time: select 2?
This is all well and good, and the post is a great read! But…
Why couldn’t
f(.{})simply bef()in Zig? If it’s the default struct with the default parameters, why bother with.{}at all?Zig doesn’t have default function parameters, only default fields.
It could additionally support optional&default function parameters, but that would make the language more complex for relatively little benefit, given that field defaults address this use-case well enough. It is reasonable to disagree with this particular cost-benefit analysis, but that’s what Zig chose.
It used to be the case e.g. with formatting functions. It was deliberately changed as it was deemed better to be explicit about argument lists if I recall.
For embedded systems, the Linux kernel, busybox (comes with an init system) and an ssh server is usually most of what one needs, distrowise. I don’t understand the frustration with systemd in this context.
The possibilities this offers is great, but I think the readability that Go is known for suffers a bit here.
What are the two situations you’re comparing the readability of?
Imagine a custom iterable type, like a b-tree. The new situation this feature permits is one function defining an iterator and many
forloops that use it. The two prior alternatives are:Inlining the iteration code at every
forloop that wants to iterate. This works fine for simple types, but would be a repetitive mess for more complex iterators like b-trees.Defining a custom iteration function, that’s called like a regular function and can’t be used in a
forloop. It’s slightly simpler to define the iteration function, but it makes the use sites more complicated (noforloop, nobreak, nocontinue).Which of these things are you comparing the readability of?
Yeah. A third consideration is, given some data structure, how do I iterate over it? The golang standard library has several different ad-hoc iteration protocols, so each time you have to read the documentation carefully to get the details right.
I am starting to look more favorably towards Zig and their goal of having as few surprises as possible.
I’ve written more Rust than I care to divulge, but I’ve only hit a bug related to this issue once: and it was entirely because it was a hobby project in which I was ignoring warnings. If I’d checked the warnings, it would have been obvious when I wrote it.
Replace “Rust” with almost any other language and post it in a Rust forum and I promise you that this argument will be hammered down quicker than you can say “borrow checker”.
Hey, at least Rust’s footguns have lints. https://github.com/ziglang/zig/issues/5973
Note that the issue you linked has an accepted proposal to completely eliminate the footgun from the language. No lint, no naming-convention-based workaround. According to the milestone assigned to the issue, that’s expected to land in 0.15.0, or earlier if a contributor steps up and does the work before the core team gets around to it.
I can’t help but notice that it was at one time or another also part of the 0.7, 0.8. 0.9, 0.10, 0.11, 0.12, 0.13, and 0.14 milestones… has something changed with the project management to make the milestone fields a more reliable indicator?
Either way, I don’t want to take away from the main point that it’s a known issue in a pre-1.0 language with a planned and principled fix.
No not really. The amount of issues solved per release is fairly consistent however. I use those milestones to make sure and visit each issue before tagging the respective release, even if the issue ends up being postponed. That said I have been more aggressively using the “unplanned” milestone lately.
The load bearing part is not the milestone, but “accepted proposal”. The issue didn’t have accepted solution before!
At least this isn’t a memory safety surprise, and is extremely rare to encounter (you have to ignore numerous warnings).
I don’t know anything about game development and design, but I’m wondering: some time ago there was this hot language called Haxe, which was positioned as a go-to language for gamedev. Is it still the case?
Haxe still exists, but I think of it more like the successor to Macromedia/Adobe Flash.
Gamedev often seems like a totally separate world. You don’t have a lot of dependencies, and overlap with open source parts is much reduced compared to almost anything else out there, apart from fiddling around with PLCs…
Haxe seemed to embody that, with public discussion not being a very good mirror of its actual use. I mean, you know what open source games are built with, you might know what AAA games are using. But what’s in that slot machine? What powers this online game with the annoying fanservice avatars?
A few years back, it seemed Haxe was a common answer. It’s very hard to tell if you’re not deep inside that “scene”, whether that’s still the case. But IIRC, it never was regarded as a general solution, mostly for 2D games and being able to write your PHP server components with the same syntax as your JS or Flash parts.
Less cognitive overhead is a good thing. I wish there were benchmarks comparing the cognitive overhead of various programming languages.
Wouldn’t those have to be very much tailored to specific individuals? I feel like I experience near-zero cognitive overhead for some things that colleagues find carry an unmanageable amount of cognitive overhead sometimes, and sometimes vice versa.
Sort of the same way different natural languages are easier or harder for people of different backgrounds to learn.
Or is there some general metric you think might apply broadly?
I agree: this is something I have thought about, and I’m curious to know what others think a good benchmark for comparing the cognitive overhead of various programming languages would necessarily look like?
Would this benchmark be an empirical study of some sort? E.g., I could imagine showing developers a short fragment of a larger unknown codebase (written in a language they know), asking these developers to recreate the fragment from memory, and comparing say fragment length to recreation accuracy (using e.g. parse tree edit distance?) across programming languages.
Or do you have a different type of approach in mind? Say more theoretically motivated, e.g. coming up with some sort of cross-language mechanical metric (think cyclomatic complexity) that measures some sort of cognitive overhead score (symbols in scope / etc.) for each part of a program?
How does one even define cognitive overhead? So many questions I guess.
It’d be nice. Measuring what goes on in human brains is pretty hard though. :C
One can use fNIRS to measure the oxygenated and deoxygenated haemoglobin concentration.
It’s not a perfect technique, though. Related article: https://arxiv.org/abs/2411.02650v1