Drew DeVault's new programming language. Haven't had a chance to check it out yet, but Drew's work tends to be great.
Looks like rust with more annoying design choices. I don't really want to type
voidin 2022.Edit: you have to free your own memory? I'll pass. If you have a language that might implement a borrow checker, you have something that only might be a bit more safe than C.
Dude is a prolific software developer. He's like the Lennart Pottering of suckless-adjacent software.
Why should I use this over Rust? It doesn't look like it has any features that Rust doesn't have, except maybe it's more batteries included wrt the standard library but it also seems like it has fewer safety features, for example no borrow checking.
So Drew has been answering some questions about the language on HN which you could check out here: https://news.ycombinator.com/threads?id=ddevault
But to summarise my understanding, it's targeted towards a different niche. It's a much smaller language that can be easily bootstrapped. It also has a spec. Those two alone make it very different to Rust imo.
Eh honestly I'm not buying their rationale.
Rust is still fairly immature in some areas, especially embedded development but I don't see why you wouldn't just put effort into making it more robust rather than reinventing the wheel one more time. Language wise it has all the features of this language and more.
Looks to me like the guy just really wanted to make his own programming language rather than actually needing exactly that kind of language for his work.
For reference, these are Drew's thoughts on Rust (specifically, as a replacement to C): https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-replacement.html
It's a few years old but it's not out of date. I think his critiques are fair, and I think it's unsurprising that he doesn't want to invest his time in the Rust ecosystem. His issues aren't that the language isn't robust, it's mainly to do with its size and complexity, and I don't blame him for not wanting to fight that fight with the Rust community who are probably not going to change course at this point.
I don't really get why "size and complexity" is considered a bad thing. Why am I supposed to think smaller languages are better? The development machine you're working on can handle it in all likelihood, and the resulting binaries can be reduced to a reasonable size like with C.
C has a consistent & stable ABI.
This is laughable. There is nothing consistent about the C abi. https://gankra.github.io/blah/c-isnt-a-language/
Most of his other arguments boil down to "it's new and it's developing fast and I don't like that for some reason".
The only real argument here IMO is Rust lacking an official spec, which is being worked on supposedly, the rest is just his gut feelings and opinions.
I don’t really get why “size and complexity” is considered a bad thing. Why am I supposed to think smaller languages are better?
I don't think its an either or thing. It all depends on the problem. Embedded systems with limited resources and hard-realtime requirements (thinking of CNC controllers, robotics, avionics, nuclear control systems, etc) must shed all this complexity as a rule. Application software (the vast majority of code anyone sees and interacts with) on the other hand benefits from all these abstractions which allow for rapid cross-platform development.
While Rust might be a better fit for hard-realtime systems than C++, it still has a lot more overhead in binary size than C, and it is stunted by the difficulty in producing compiler toolchains for the various esoteric microcontrollers which dominate this space.
You can make Rust binaries as small as you'd like basically: https://github.com/johnthagen/min-sized-rust
You can also run it on stuff like Arduino: https://creativcoder.dev/rust-on-arduino-uno
It's probably not the ideal tool for those jobs but it's also far from the worst. It very much tries to go by the C++ maxim "you pay for what you use", albeit imperfectly. I just don't see any dealbreakers here that would warrant yet another language in this space, at least none that couldn't be solved by fixing or expanding what Rust already offers.
Would love to spend some free time (when I eventually get some) working on/tinkering with a OS that actually makes sense and is nice to use but idk where to start / if any existing projects are good candidates
Seriously though I don't get *nix nerds preoccupation with dynamic linking, things are different than in the fucking 90s.
Storage space is dirt fucking cheap and you could probably make the kernel a bit smarter so it detects when the same sets of symbols get loaded and thus reduce RAM usage and cache misses.
I've heard this argument a few times but has it ever happened in practice? I guess the static lib would need to be marked as read only and page aligned by the compiler/linker so that the OS can see that multiple processes are using the exact same page and combine them
Something like that. I haven't also really seen anybody actually do it, just talk about it I think. Forgot how the technique is called and I'm not able to google it.
Also maybe you wouldn't need to hunt down specific pages of memory but rather just hash all the memory regions marked as executable in the process and just make sure to map them to the same physical memory.
Can't we do shared memory pages now, so the old argument of "dynamic linking saves RAM" doesn't matter as much?Nvm space_comrade said what I was thinking of
It seems it's not as close as I remembered it, this is the only mention of it I can find right now: https://doc.rust-lang.org/stable/reference/#what-the-reference-is-not
So basically the answer is "we'll get there eventually". I can understand it not being a huge priority, official specs are only useful if you want to have multiple compiler implementations, which I don't think is super important right now anyway.
Yeah Linux kernel development seems like something they could aim for considering it features many safety improvements versus C but is not as difficult to bootstrap as Rust.
i saw this blog post (from a year ago) posted - https://tilde.team/~kiedtl/blog/hare/ .. not exactly a raving review..seems kinda interesting (proper namespacing/modules) .. i wouldnt personally have a use for it even though i use "systems languages" for almost everything because of their desire to avoid proprietary operating systems.
I'll be extremely interested to try it out, though most of what I do is high enough level that it may not be that useful to me.
