71–80 of 229 posts
Earlier quoted context omitted.
you're right, it is confusing, but it is optional: some toy kernels already work in nim , and with latest work on memory, you should be able to use most of the language for kernel development ! not the perfect language for that yet though, but i hope we should see more nim os examples
Are you saying that the GC is optional? If you don't use it how do you allocate/free memory?
Earlier quoted context omitted.
you're right, it is confusing, but it is optional: some toy kernels already work in nim , and with latest work on memory, you should be able to use most of the language for kernel development ! not the perfect language for that yet though, but i hope we should see more nim os examples
Are you saying that the GC is optional? If you don't use it how do you allocate/free memory?
otherwise you should be able to use something like destructors eventually
Earlier quoted context omitted.
May I ask why people invent new languages rather than trying to extend or improve existing ones, like C?
You could argue that it's what these languages do, the C heritage is very strong in every one of them. The problem is: do you want to maintain full backcompat or are you willing to break things to do it cleanly? If you do the former you end up with something like C++ which retains almost complete compatibility with C (but they you have a lot of baggage to carry around, which may get in the way at times) or you're wil…
That's a pretty awesome place to be, as C++ is one of the most successful programming languages in history.
Perhaps there are lessons there.
> or you're willing to break things and then why not take the opportunity to improve the syntax and get rid of the cruft?
Break things just for the hell of it is not much of a tech argument.
C is already pretty light, and already gave origin to successful programming languages such as C++ and Objective C. Unless you find a compelling reason to break backward compatibility in a very specific way, I don't see how that argument makes any sense.
> An other big problem with C interop for newer languages is that while C itself is relatively small and easy the C preprocessor isn't.
Arguably, the preprocessor is orthogonal to the programming language itself. I fail to see how that's relevant.
Earlier quoted context omitted.
Nim's GC is optional
How can it be optional if there is lots of code that assumes you are using GC? For example, as far as I can tell the stdlib doesn't do its own allocations. Does this mean you can't use the stdlib with GC disabled? Or am I missing something here?
But you can also think of Nim as macro-able higher level C and write it like that (but indeed you probably still need this minimal allocation support)
Earlier quoted context omitted.
I'm curious too, I'm quite familiar with Rust and never written any Zig in my life so I went digging through the source and I find the syntax remarkably similar for the most part. The only thing that stood out is that apparently you can drop the braces for single-line `if` bodies like in C whereas Rust makes them always mandatory but I'm firmly on Rust's side on this one. The part where Rust can get really messy is w…
I wouldn't call Zig's comptime "C++-style." Unlike Rust, there's very little in Zig that is borrowed from C++. Zig's error reporting and comptime makes it easy to write arbitrary compile-time checks, so Zig uses a single construct and keyword, comptime, to replace all special instances of partial evaluation: generics, concepts/traits, value templates, macros and constexprs. The main difference between Zig and Rust is…
Earlier quoted context omitted.
> I used to do this in Rust but I switched to zig for maintainability and readability over Rust. Can you expand on this ? I'm asking out of curiosity because I want to learn a "system" programming language (for whatever definition there is to this term). So far I briefly tried Rust and Nim and found the former more difficult to read. I know nothing about Zig, how would you place it between these two ?
Bouncing on recently featured HN thread "Hello World": https://drewdevault.com/2020/01/04/Slow.html (and the HN thread: https://news.ycombinator.com/item?id=21954886 ) According to this resource, Zig produces code that is very close to the hand written assembly for the simple use case of outputing "hello world" on the stdout. This is to be taken with a grain of salt though, as of course, caring about the assembly out…
I don't agree! at least for operating systems.
Consider that some operating system code may be run a million times per second, on a million different machines (e.g: block system IO on linux). We very much want our assembly to be pristine in this case.
I also like the idea of "optimality" brought forward by zig. In the post you link, there's an ideal hello_world in asm, can we have a higher level language that doesn't sacrifice this ideal achieved by assembly?
Consider that some network cards are now capable of 400Gibps, and modern OSes are not capable of handling these linerate. I strongly believe the bottleneck should be in the hardware, if the software can't max out your hardware then your software has failed.
I like that zig focuses on optimality.
Earlier quoted context omitted.
> I used to do this in Rust but I switched to zig for maintainability and readability over Rust. Can you expand on this ? I'm asking out of curiosity because I want to learn a "system" programming language (for whatever definition there is to this term). So far I briefly tried Rust and Nim and found the former more difficult to read. I know nothing about Zig, how would you place it between these two ?
In general you'll find that zig is easier to read than Rust (see the first version of this project in Rust [0]) because it's a simpler language. For kernel programming this is even more so the case: * zig has native support for arbitrary sized integers. In Rust I used to do bitshifts, Now I just have a packed struct of u3/u5/u7 whatever (see `src/pci/pci.zig`). Of course Rust has a bitflags crate but I didn't find it…
Earlier quoted context omitted.
> I used to do this in Rust but I switched to zig for maintainability and readability over Rust. Can you expand on this ? I'm asking out of curiosity because I want to learn a "system" programming language (for whatever definition there is to this term). So far I briefly tried Rust and Nim and found the former more difficult to read. I know nothing about Zig, how would you place it between these two ?
In general you'll find that zig is easier to read than Rust (see the first version of this project in Rust [0]) because it's a simpler language. For kernel programming this is even more so the case: * zig has native support for arbitrary sized integers. In Rust I used to do bitshifts, Now I just have a packed struct of u3/u5/u7 whatever (see `src/pci/pci.zig`). Of course Rust has a bitflags crate but I didn't find it…
Arbitrary sized integers do sound very convenient, although I guess the counterargument would be that they simply can't map to machine types so you'll have to have magic behind the scenes which may not make complete sense in low level languages. Still, C has bitfields in structs which are sort of the same thing so why not.
Pointer handling however I'm not sold on. I'd argue that the very cumbersome pointer handling in Rust is a feature, not a bug. It's explicitly discouraged, and for good reasons. Map your pointer into a clean and safe reference, slice or wrapper object ASAP and leave raw pointers to the messy details of C FFIs and ultra low-level code. If you end up having to mess with raw pointers everywhere in your codebase you're doing it wrong, as far as Rust is concerned.
I think this is reasonable even for kernel code. After all typically you wouldn't dereference register pointers directly in C code because of volatility issues and making it obvious that you're accessing hardware and not RAM (readl/writel or similar), so having a safe wrapper adds no overhead in my experience.
Earlier quoted context omitted.
> I used to do this in Rust but I switched to zig for maintainability and readability over Rust. Can you expand on this ? I'm asking out of curiosity because I want to learn a "system" programming language (for whatever definition there is to this term). So far I briefly tried Rust and Nim and found the former more difficult to read. I know nothing about Zig, how would you place it between these two ?
I find Zig's approach to generics to be very cool. Types are a first class citizen, so you basically get generics out of the box. Combined with Zig's `comptime` makes for writing very cool code. This solves lot of things you'd need macros in other languages to do.