@whitequark which one is the latter?
-
@whitequark @IngaLovinde maybe I should give Zig another look…
-
@whitequark @IngaLovinde I’ve never used it in earnest, but I recall just not seeing the point of it previously.
-
@whitequark Yeah I didn’t expect you meant it that way!
-
@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.
-
@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.
@IngaLovinde @resistor yep, that is what i would expect
unfortunately, tradeoffs exist
-
@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.
@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 it
especially 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 paths
it seems a lot better nowadays though and we've been considering trying it again for writing memory safe wrappers and abstractions -
@whitequark oh nice, this was my guess but I wasn't sure about labor rights specifically
@IngaLovinde @whitequark I must have missed some news, what is the relation of these languages and labor rights?
-
@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 it
especially 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 paths
it seems a lot better nowadays though and we've been considering trying it again for writing memory safe wrappers and abstractions@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).
-
@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 rust
rust has for a long time been hostile to bootstrapping, abi compatibility (mostly being able to be used from other languages), and compiler reimplementation
it'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
-
@whitequark yeah, understandable. i mostly value reimplementability and compatibility, as that is how you empower people (imo), by providing a stable base, and rust is the opposite of that
-
@whitequark good thing university taught rawdogging riscv assembly
-
@whitequark i am fundamentally against making things hard to reimplement, especially compilers, because i want to put as little friction as possible in the way of people porting software in a language to their platform.
making reimplementations impossible isn't how you protect users, it's how you lock them to a specific technical instance, and to the whims of whoever decides the direction it goes. allowing reimplementations allow the users to at least partially put their trust into another party instead, giving them much more power
non standard extensions in compilers is not enough of a cost to not do it imo, since it is up to projects to be responsible about which extensions to use or not
PS: also fuck ISO sucks, requiring payment to have access to documentation is the opposite of empowerement, and we can have standards without ISO anyway
-
@SRAZKVT now, i don't think compilers should be intentionally hard to reimplement. i just don't think that "ease of reimplementation" is a valuable target to pursue on its own and it has a somewhat negative effect on the language overall; whether this negative effect will become a serious problem in practice basically depends on how homogeneous your culture is, i think
-
@whitequark it is up to the maintainer to decide which extensions they require, if a downstream user's compiler doesn't support it, then they can either add it to their compiler, patch the codebase to not require it, or go for something else instead
-
@SRAZKVT now, i don't think compilers should be intentionally hard to reimplement. i just don't think that "ease of reimplementation" is a valuable target to pursue on its own and it has a somewhat negative effect on the language overall; whether this negative effect will become a serious problem in practice basically depends on how homogeneous your culture is, i think
@SRAZKVT or to put it in much more primitive terms: if you fork the language then have the decency to change the name, too
-
@whitequark it is up to the maintainer to decide which extensions they require, if a downstream user's compiler doesn't support it, then they can either add it to their compiler, patch the codebase to not require it, or go for something else instead
@SRAZKVT the practical outcome of all three cases is make-work
-
@SRAZKVT now, i don't think compilers should be intentionally hard to reimplement. i just don't think that "ease of reimplementation" is a valuable target to pursue on its own and it has a somewhat negative effect on the language overall; whether this negative effect will become a serious problem in practice basically depends on how homogeneous your culture is, i think
@whitequark obviously, it isn't absolute, but if you have the option as language designer between doing just syntax sugar around already existing features, or adding a whole new component, then the former should be prioritised
-
@SRAZKVT the practical outcome of all three cases is make-work
@whitequark yes, making software work on a system it wasn't designed for is make-work, it would be regardless
having more options on how to tackle makes it less bad though
-
@whitequark yes, making software work on a system it wasn't designed for is make-work, it would be regardless
having more options on how to tackle makes it less bad though
@SRAZKVT there's several things implicit here that i don't really like:
- placing the burden of making it work on the end user and/or maintainer (ocaml sidesteps this nicely by providing a baseline bytecode interpreter that's mostly fast enough; no language extensions are involved at any point)
- biasing the language towards the endless scope-creep of implementations that gave us c instead of going "no, if you want this to run on a 8-bit AVR, get a different language, this one isn't fit for the use case" (which would leave everyone involved happier in those cases)
-
@SRAZKVT there's several things implicit here that i don't really like:
- placing the burden of making it work on the end user and/or maintainer (ocaml sidesteps this nicely by providing a baseline bytecode interpreter that's mostly fast enough; no language extensions are involved at any point)
- biasing the language towards the endless scope-creep of implementations that gave us c instead of going "no, if you want this to run on a 8-bit AVR, get a different language, this one isn't fit for the use case" (which would leave everyone involved happier in those cases)
@whitequark yes, the language should have a baseline that is expected to be implemented everywhere, that's the language without extensions
widely implemented extensions should be included in the baseline eventually to better compatibility
and for the second, yeah, but if you are on 8bit avr, you likely don't need a kernel with system utilities written by someone else who has no knowledge of your system, you'll likely need something completely custom anyway
