Hobby x86 kernel written with Zig • Hacker News Board

Re: Hobby x86 kernel written with Zig

#201

Post by zozbot234 » Tue, Jan 07, 2020, 2:45 AM UTC

DSMan195276 wrote: post #198

zozbot234 wrote: post #178

Earlier quoted context omitted.

> Sure, but now we're back to the issue that it's unclear what constraints `unsafe` code actually has to hold The Rust Nomicon actually documents these constraints for each 'unsafe' operation. Code that can ensure that these constraints hold can be regarded as 'safe' and rely on an unsafe{ } block. Code that can't, should be marked unsafe and document its own constraints in turn. > You may think you have a safe inter…

> The Rust Nomicon actually documents these constraints for each 'unsafe' operation. Code that can ensure that these constraints hold can be regarded as 'safe' and rely on an unsafe{ } block. Code that can't, should be marked unsafe and document its own constraints in turn. > > If you're relying on internal details, you're most likely doing it wrong, even by the standards of 'unsafe'. There are ways to nail down thes…

> - it's not a breaking change to introduce or realize there are more constraints.

These breaking changes are allowed precisely because they're meant to address soundness concerns. Even if at any given time they're just a "best guess" of what's actually needed, that's still wildly better than what e.g. C/C++ do, which is just to not guess at all. Even wrt. formal memory models, perhaps the most complex issue among the ones you mention here, C/C++ only got an attempt at a workable memory model with the 201x standards (C11, etc.). It's not unreasonable to expect that Rust may ultimately do better than that.

Re: Hobby x86 kernel written with Zig

#202

Post by Vendan » Tue, Jan 07, 2020, 3:35 AM UTC

Arnavion wrote: post #200

Vendan wrote: post #192

Earlier quoted context omitted.

So then it's the editor that's at fault. Most editors let you do a "run formatter on save", and zig has(had? at least it did last I played with it) a formatter that can do correct "indent with tabs and align with spaces" with only a minor tweak

I'm not aware of any editor or auto-formatter that handle the case of https://news.ycombinator.com/item?id=21969323 correctly.

Visual studio does it for C#, at the very least. Other formatters choose other options, and it's a matter of preference in any case (I personally think it's a code smell to have that many arguments or that long of names, and I also don't limit myself to 80 columns, cause I've got a widescreen monitor)

Either way, it's a trivial algorithm to implement. Calculate len("function_with_lots_of_arguments("), add that many spaces after your indentation tabs on the next line, continue arguments. The fact that editors/auto-formatters don't do that speaks far more to their lack of desire for that code style then it does to the difficulty of doing it.

The simple fact remains that using tabs provides many accessibility benefits that spaces are just unable to provide, like being able to drop tab size when you boost font size (legibility for poor vision) so your code doesn't indent off the side of the screen, or far better support for indentation for proportional fonts (another thing that people swear by for increasing legibility).

Re: Hobby x86 kernel written with Zig

#203

Post by Arnavion » Tue, Jan 07, 2020, 3:52 AM UTC

Vendan wrote: post #202

Arnavion wrote: post #200

Earlier quoted context omitted.

I'm not aware of any editor or auto-formatter that handle the case of https://news.ycombinator.com/item?id=21969323 correctly.

Visual studio does it for C#, at the very least. Other formatters choose other options, and it's a matter of preference in any case (I personally think it's a code smell to have that many arguments or that long of names, and I also don't limit myself to 80 columns, cause I've got a widescreen monitor) Either way, it's a trivial algorithm to implement. Calculate len("function_with_lots_of_arguments("), add that many s…

Just to be clear, I prefer tabs over spaces myself, so I'm not arguing against tabs. What I'm arguing against is mixing tabs with spaces, with the expectation that every contributor to the codebase uses sufficiently smart editors to not break the formatting.

With that out of the way...

>Either way, it's a trivial algorithm to implement. Calculate len("function_with_lots_of_arguments(")

That breaks for `foo(bar(a,\nb,\nc))`

And if you fix it to be "len till the last unmatched (" then it breaks for `foo(bar(a,\nb),\nc)` because the two lines have to indent to different levels.

Just saying it's not as trivial as it seems.

>The fact that editors/auto-formatters don't do that speaks far more to their lack of desire for that code style then it does to the difficulty of doing it.

And is a reason to not use such a style in the first place, as I said.

Re: Hobby x86 kernel written with Zig

#204

Post by DSMan195276 » Tue, Jan 07, 2020, 3:57 AM UTC

zozbot234 wrote: post #201

DSMan195276 wrote: post #198

Earlier quoted context omitted.

> The Rust Nomicon actually documents these constraints for each 'unsafe' operation. Code that can ensure that these constraints hold can be regarded as 'safe' and rely on an unsafe{ } block. Code that can't, should be marked unsafe and document its own constraints in turn. > > If you're relying on internal details, you're most likely doing it wrong, even by the standards of 'unsafe'. There are ways to nail down thes…

> - it's not a breaking change to introduce or realize there are more constraints. These breaking changes are allowed precisely because they're meant to address soundness concerns. Even if at any given time they're just a "best guess" of what's actually needed, that's still wildly better than what e.g. C/C++ do, which is just to not guess at all. Even wrt. formal memory models, perhaps the most complex issue among th…

I highly disagree with that assessment, in regards to C you're comparing apples to oranges IMO, because C is very lax compared to what Rust enforces now and could enforce in the future, just by virtue of having so many less actual features. With that, if you commit to being `gcc` (and `clang`) specific, you have a very high number of guarantees and flexibility, even more depending on what extra feature flags you pass.

> It's not unreasonable to expect that Rust may ultimately do better than that.

But, when? Rust is almost 10 years old, and questions about this stuff has been posed for years now - I was having these same conversations over two years ago. Last year's roadmap included working on the 'unsafe guidelines' I posted, and as an outsider looking in it's unclear to me how much progress has actually being made. Don't get me wrong - they've made a fair amount of progress, but there's still a lot to be done.

My big concern (which I don't consider to be unfounded) is that because there aren't that many big users of Rust actually developing really low-level stuff, the work on defining it isn't getting done. But to me it feels like a self fulfilling prophecy - a project like the Linux Kernel isn't going to end-up using Rust if there's big issues with connecting what they're doing now to Rust idioms (Ignoring the LLVM thing...), even though when Rust was first maturing it was being billed as the replacement for C (and still is).

Re: Hobby x86 kernel written with Zig

#205

Post by Vendan » Tue, Jan 07, 2020, 4:40 AM UTC

Arnavion wrote: post #203

Vendan wrote: post #202

Earlier quoted context omitted.

Visual studio does it for C#, at the very least. Other formatters choose other options, and it's a matter of preference in any case (I personally think it's a code smell to have that many arguments or that long of names, and I also don't limit myself to 80 columns, cause I've got a widescreen monitor) Either way, it's a trivial algorithm to implement. Calculate len("function_with_lots_of_arguments("), add that many s…

Just to be clear, I prefer tabs over spaces myself, so I'm not arguing against tabs. What I'm arguing against is mixing tabs with spaces, with the expectation that every contributor to the codebase uses sufficiently smart editors to not break the formatting. With that out of the way... >Either way, it's a trivial algorithm to implement. Calculate len("function_with_lots_of_arguments(") That breaks for `foo(bar(a,\nb,…

> Just to be clear, I prefer tabs over spaces myself, so I'm not arguing against tabs. What I'm arguing against is mixing tabs with spaces, with the expectation that every contributor to the codebase uses sufficiently smart editors to not break the formatting.

That's still just an argument for "everyone use a specific formatter with these settings". Go's formatting is simple, built into the main implementation, and has no knobs, as a result, everyone uses it, and all code is formatted with tabs and spaces. It can work, esp. if a language adopts it early (like Zig could have).

Re: Hobby x86 kernel written with Zig

#206

Post by throwaway17_17 » Tue, Jan 07, 2020, 5:53 AM UTC

mratsim wrote: post #91

baq wrote: post #64

Earlier quoted context omitted.

C is portable assembly, I’d recommend learning it together with the assembly for the platform you’re learning on, so you can actually understand the stack, heap, calling conventions, etc.

C is portable assembly until it isn't: - no access to carry/overflow flag in registers making it a chore to write bigint libraries - no way to guarantee emitting add with carry or sub with borrow even though those are simple instructions and some architecture (6502) don't even provide a normal add/sub - need to drop down to assembly to implement resumable function/fibers to avoid the syscall costs of ucontext/setjmp/…

The following is a genuine question (not a flippant remark):

Is there any way to have those concepts be portable across ISAs/architectures. I don’t think those types of ops are exposed in LLVM-IR or GCC’s various intermediate levels (but could be wrong). I’d love to be able to investigate a language that enables a level of hardware access possible in a portable manner.

Re: Hobby x86 kernel written with Zig

#207

Post by loeg » Tue, Jan 07, 2020, 6:15 AM UTC

BubRoss wrote: post #194

loeg wrote: post #180

Earlier quoted context omitted.

Good! Even Windows Notepad, the extreme example of "not a code editor editor," supports \n newlines now: https://devblogs.microsoft.com/commandline/extended-eol-in-n...

Why is it good to force all your users to figure out how to set their text editors to do something different and unnecessary just because you refuse to do what essentially every other non toy language has always been able to do? How is a decision like that not a giant red flag of user hostility and bad judgement?

Is your metaphor about Windows since XP or about Zig?

Re: Hobby x86 kernel written with Zig

#208

Post by loeg » Tue, Jan 07, 2020, 6:22 AM UTC

roblabla wrote: post #188

loeg wrote: post #175

Earlier quoted context omitted.

> The kernel, Zircon, is written entirely in C No, it's written in C++[1]. They're very different languages. That said, Google seems to think C++ has something to offer to all kinds of development. It seems to work for them, but they are a heavily C++ shop. I wouldn't read too much out of their use of C++ anywhere; it'd be more surprising and interesting to see them use anything else. [1]: https://fuchsia.googlesourc…

Oh that's interesting. Zircon is based on LK[0] which is in C, which is why I thought it was still written in C. I wonder how much is left of the original LK code then. [0]: https://fuchsia.dev/fuchsia-src/concepts/kernel/zx_and_lk

Interesting, I didn't know about LK. Thanks for sharing :-).

Re: Hobby x86 kernel written with Zig

#209

Post by pjmlp » Tue, Jan 07, 2020, 6:27 AM UTC

loeg wrote: post #183

pjmlp wrote: post #68

Earlier quoted context omitted.

It doesn't fix use-after-free, double free().

There is some aphorism about perfection, the enemy of good, and some way in which they relate. It is relevant to understanding "why Zig?"

Object Pascal and Modula-2 dialects already offer better than Zig memory "safety", so "Why Zig" indeed.

I am all for any language that helps reduce C's usage, including Go, even when I dislike its design decisions.

Now Zig, if it doesn't fix what are about 60% of yearly expenses fixing security exploits, according to Google and Microsoft security reports, then one needs to analyse how much is it worth actually.

Re: Hobby x86 kernel written with Zig

#210

Post by littlestymaar » Tue, Jan 07, 2020, 7:00 AM UTC

pron wrote: post #110

pcwalton wrote: post #102

Earlier quoted context omitted.

> There is also the difference in their approach to safety, but that's a complicated subject that ultimately boils down to an empirical question -- which approach is safer? -- which we don't have the requisite data to answer. We do have the requisite data to answer whether preventing use-after-free is better than not preventing it. You can argue (not successfully, in my opinion) that it's not worth the loss in produc…

> We do have the requisite data to answer whether preventing use-after-free is better than not preventing it. I expect Zig will prevent use-after-free. It will be sound for safe code and unsound for unsafe code (by turning this on only in debug mode for testing). > but it's impossible to argue that not trying to prevent UAF is somehow safer. First, see above. Second, it is not only possible but even reasonable to arg…

> reducing bugs of kinds A, B and C -- for a similar cost -- may well be safer.

What kind of bugs do your have in mind that Zig would prevent and Rust doesn't ? I can think about several Rust does and Zig doesn't thanks to its afine type system, but I've yet to see a safety feature benefit in Zig.