Post B5QblrPL0GcH4PvpB2 by navi@social.vlhl.dev
(DIR) More posts by navi@social.vlhl.dev
(DIR) Post #B5Q1EzGv99aXYS1Jb6 by whitequark@social.treehouse.systems
1 likes, 0 repeats
deeply unfortunate that in 2026 we have to choose between "a programming language developed by people with a deep respect for memory safety" and "a programming language developed by people with a deep respect for labor rights" but i suppose it's not too surprising after a culture shift resulting from decade of limp-wristed leadership and empowering Palantir Guys so as to not scare away Microsoft
(DIR) Post #B5Q1EzVSH7DMHWovFg by IngaLovinde@embracing.space
0 likes, 0 repeats
@whitequark which one is the latter?
(DIR) Post #B5Q1MXOChHUXOZ1jvM by whitequark@social.treehouse.systems
0 likes, 0 repeats
@IngaLovinde zig
(DIR) Post #B5Q1MXYU53iNuRpwwq by IngaLovinde@embracing.space
0 likes, 0 repeats
@whitequark oh nice, this was my guess but I wasn't sure about labor rights specifically
(DIR) Post #B5Q1UWSE3dpSoNiRPs by whitequark@social.treehouse.systems
0 likes, 0 repeats
@IngaLovinde (i know one could debate this point ad nauseam but even merely acknowledging that the problem exists is a deeper stance than most OSS leaders today, so.)
(DIR) Post #B5Q1UWdvM9BdOfBmeO by IngaLovinde@embracing.space
0 likes, 0 repeats
@whitequark most OSS leaders today are not a leadership material very much imo
(DIR) Post #B5Q6fPlxjvsT2qxcnY by resistor@mastodon.online
0 likes, 0 repeats
@whitequark @IngaLovinde maybe I should give Zig another look…
(DIR) Post #B5Q6fPwb6ONtZpw7NI by whitequark@social.treehouse.systems
0 likes, 0 repeats
@resistor @IngaLovinde i have historically not liked the language a lot (strictly with my PL designer hat) but i'm thinking i'll write my next firmware with zig
(DIR) Post #B5Q6fQ90MGJECJk1iK by resistor@mastodon.online
0 likes, 0 repeats
@whitequark @IngaLovinde I’ve never used it in earnest, but I recall just not seeing the point of it previously.
(DIR) Post #B5Q6fQMpWrMstCD4GO by whitequark@social.treehouse.systems
0 likes, 0 repeats
@resistor @IngaLovinde i think it's a significant upgrade on c and c++ when used in the systems/embedded space. rust is a much bigger upgrade from a technical pov but. you know
(DIR) Post #B5Q6fQYAqgRTSNW7we by IngaLovinde@embracing.space
0 likes, 0 repeats
@whitequark @resistor zig is nice, I did some stuff with it too, and I miss some of its features in rust (my day job is mostly working with rust).But too relaxed for my taste to do large-scale complex projects in it. With rust, I can e.g. refactor things and if the code still compiles afterwards then it almost certainly works and the tests will almost certainly pass; but with zig it unfortunately feels much more difficult to do things like that, and with fewer guarantees.
(DIR) Post #B5QJf1MRnfhAjpAWY4 by the_art_of_giving_up@mastodon.social
0 likes, 0 repeats
@IngaLovinde @whitequark I must have missed some news, what is the relation of these languages and labor rights?
(DIR) Post #B5QPGasnC4bhON28DQ by chaos@gts.schizofucked.monster
0 likes, 0 repeats
@resistor @whitequark @IngaLovinde agree, it eventually felt like if we wanted to add anything to our projects we'd have to refactor half the project to add itespecially as we was using it in the pretty early days and ended up having to fork a good part of the stdlib just to get our program not crashing due to hitting unimplemented or 'unreachable' code pathsit seems a lot better nowadays though and we've been considering trying it again for writing memory safe wrappers and abstractions
(DIR) Post #B5QPGb7KK2EW7Rpjs0 by IngaLovinde@embracing.space
0 likes, 0 repeats
@chaos @resistor @whitequark refactoring is not a problem per se. The problem is that with zig, it's much easier to break things accidentally without noticing during the refactoring than it is with rust (where almost all such accidental breakages will simply result in a compile-time error).
(DIR) Post #B5QZwxIDGNdibElIEC by SRAZKVT@tech.lgbt
0 likes, 0 repeats
@whitequark honestly even like 2 years ago (before llms became such a cancer on foss) i saw more of a future in zig than in rustrust has for a long time been hostile to bootstrapping, abi compatibility (mostly being able to be used from other languages), and compiler reimplementationit's still unsure how zig will fare for those, but honestly, i am more optimistic, and when meson/muon supports zig, i'm probably going to start using it
(DIR) Post #B5QZwxWOPeyxJDOcKW by whitequark@social.treehouse.systems
0 likes, 0 repeats
@SRAZKVT i don't think bootstrapping and having a stable abi are an essential component of a healthy ecosystem. in particular not having a robust interoperability story can motivate people to reimplement a lot of existing software, hopefully while taking lessons learned to heart(i'm not saying that this is how it always goes, nor that it's the only way to build a language, just that it can have a benefit; Amaranth for example has a robust interop story with Verilog but people avoid the latter for non-technical reasons, resulting in a stronger language that is suitable for more tasks overall)certainly for my main interest in rust (embedded projects) i do not care if there's one rust compiler or ten thousand. i'm going to pick one, stick with it, and it better be a good one; so spreading efforts thinner isn't something that i inherently value
(DIR) Post #B5QZwxkvXcbm2ICDz6 by navi@social.vlhl.dev
0 likes, 0 repeats
@whitequark @SRAZKVT > i don't think bootstrapping and having a stable abi are an essential component of a healthy ecosystem. in particular not having a robust interoperability story can motivate people to reimplement a lot of existing software, hopefully while taking lessons learned to heartrust doesn't have a stable abi across rust <-> rust modules/crates, which has nothing to do with makes does the opposite of what you say -- all it does is making rust-rust dynamic linking impossible, so people have to drop to the system abi for it, and/or make any sort of build cache invalid whenever you update the compiler
(DIR) Post #B5QZwxwyooFWdfpqls by whitequark@social.treehouse.systems
0 likes, 0 repeats
@navi @SRAZKVT i know how rust works. any sort of friction at module boundaries creates a dual effect: first, it disincentivizes people from maintaining mixed codebases (we'd see a lot more mixed rust/c++ codebases if you could directly use polymorphic rust methods from c++, for example); second, it lets you avoid freezing the internals of your runtime on an implementation that more certainly than not has significant flaws (c++'s itanium abi dynamic_cast for example), or at least reduces how quickly that happens. these two things let you focus on addressing just your own mistakes, instead of adding everyone else's mistakes into the mix
(DIR) Post #B5QZwyHXaMhDfRSGoq by navi@social.vlhl.dev
0 likes, 0 repeats
@whitequark @SRAZKVT a stable abi does not need to be exported to other languagesit'd be even ideal to have rustc have an abi for rlibs and say "do not use this from somewhere else, we will not help you" -- and that would solve so many packaging pains with rusta system's programming language without a stable abi is pure hellfor application programming maybe, not for system's
(DIR) Post #B5QZwyXqbjjwU15IEi by whitequark@social.treehouse.systems
0 likes, 0 repeats
@navi @SRAZKVT there is nothing unique about systems programming that requires a stable ABI. there are many things about old Linux distributions that are built around the assumptions of having one, but that's a separate thing and if we are to have a discussion of this at all that's the one i want to have, not a proxy for it
(DIR) Post #B5QZwyg07QGItItnwe by navi@social.vlhl.dev
0 likes, 0 repeats
@whitequark @SRAZKVT the unique thing is the kind of software that is written in themand as someone that suffered to package rust and tools in similar languages, that's a discussion i can have if desired yes -- mostly involving dynamic linking, but even with static linking, the lack of being able to package prebuilds also creates issues (not even considering the pain that lockfiles are)
(DIR) Post #B5QZwyqzSZ3JRO2a4e by whitequark@social.treehouse.systems
0 likes, 0 repeats
@navi @SRAZKVT my position on distributions boils down to "it is pretty weird and otherwise unprecedented that we've normalized it that once you release software some other group of people (who don't really understand how it works) is going to build and publish it, giving you little to no say in the matter, but leaving you responsible for support in the end". so far as this is true i think the value distributions provide to me as a developer, and also as a user, is neutral to negative. Debian is the worst at this but I think the entire model should be replaced
(DIR) Post #B5QZwz2KmO7u0ZLdku by navi@social.vlhl.dev
1 likes, 0 repeats
@whitequark @SRAZKVT and i think that staggering software distribution is a benefit for the user, as a ton of developer do not ever consider setups that differ from their on even in the slightest -- as an example nix and gentoo packagers so often send dozens and dozens of patches upstream fixing build systems that had baked in expectationsi've personally sent patches out fixing autotools issues with cross-building a handful of packages from portagesure there is distros whose people make no effort to learn about the software they package, nor to fix issues, but most if not all packagers i've ever talked to are not like that at all, and that includes packagers for gentoo, nix, guix, alpine, void, and a few debian ones (though i am *well* aware of many issues debian in general has with packaging)decent distros have their own bug tracker, on gentoo the majority of bugs go there, before going upstream (if the problem turns out to not be with the downstream packaging) -- it does help when the package has some branding build-time flags where we can replace e.g. the upstream issues tracker url with our bug tracker, makes it easier to direct users there firststaggered releases are to the benefit of users, if users had gotten the newest xz as soon as the developer pushed it, instead of having it land on a testing branch first, how many more people wouldn't have been affected day 1in particular also gentoo held back the shadow package from hitting stable for a while because new versions had a ton of refactoring of security sensitive code, so the packager wanted to be sure it was all okay before pushing it for everyone (though if one wanted, they can select per-package ~$arch, to enable testing packages on said $arch)--and redistribution being seen as weird is odd to me, the nature of foss is collaborative and communitarian, and not unique to foss, we're pretty okay with libraries redistributing books
(DIR) Post #B5QblqxKgODNfYpSWe by whitequark@social.treehouse.systems
0 likes, 0 repeats
@navi @SRAZKVT if libraries edited books before redistribution without talking about it with the author (or even understanding the subject well), just to fit it to their policy goals, i'd object to that too!
(DIR) Post #B5QblrEhdo6qXQxKbI by whitequark@social.treehouse.systems
0 likes, 0 repeats
@navi @SRAZKVT i agree about staggered deployment but that is neither specific to, nor requires distros. i think go is planning to do it ecosystem wide, for examplei also agree that a lot of software bakes developers' assumptions into it but i don't see anything packagers like as universal good. FHS was a mistake. non-reproducible builds are a mistake. non-hermetic builds are a mistake... some of these things distros get right, some very much not
(DIR) Post #B5QblrPL0GcH4PvpB2 by navi@social.vlhl.dev
1 likes, 0 repeats
@whitequark @SRAZKVT sure none of it may exclusive from distros, but the point is that distros (should, nay, must) look after their users -- the main point is being communitarian, not under exclusive control of the developer, e.g. upstreams often don't do releases to fix big regressions, distros can patch those when neededsometimes upstreams go haywire and the distro attempts to protect the users (newer keepassxc being masked on gentoo)it's harder to do when the developer has complete control of the distribution method