The linux kernel community is discussing convert the linux kernel from c to modern c++

Brainstorming
1

https://lore.kernel.org/lkml/3465e0c6-f5b2-4c42-95eb-29361481f805@zytor.com/

I think zig is more suitable (and simpler) than c++ in kernel development, maybe it’s time to introduce zig to the linux kernel community.
I think we can show them the power of zig by replace makefiles and kconfig by zig build system, and convert a simple driver to zig by zig translate-c.

Alexey Dobriyan maintaining Linux++ patchset since Linux 5.3, he share some experiences of convert c code of linux kernel to c++, we can learn what language features does the linux kernel need from his post.
https://lore.kernel.org/lkml/7e72d2eb-0013-4289-9714-cf2dd0bf0076@p183/

3 Likes
2

l like zig, but there’s no way they go for a language that is self declared not stable.

12 Likes
3

For some context, a quote from Linus from 2007:

C++ is a horrible language. It’s made more horrible by the fact that a lot
of substandard programmers use it, to the point where it’s much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do nothing but keep the C++ programmers out,
that in itself would be a huge reason to use C.

I’ve come to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really would prefer to piss
off, so that he doesn’t come and screw up any project I’m involved with.

If you want a VCS that is written in C++, go play with Monotone. Really.
They use a β€œreal database”. They use β€œnice object-oriented libraries”.
They use β€œnice C++ abstractions”. And quite frankly, as a result of all
these design decisions that sound so appealing to some CS people, the end
result is a horrible and unmaintainable mess. But I’m sure you’d like it more than git.

5 Likes
4

I get the impression that Linus doesn’t like C++… lol

4 Likes
5

They could use the stable branch, particularly if Zig commits to always having an easy migration path to newer versions, even if this migration path only works for the linux kernel. It would be a big commitment from Zig, but it might be worth it to convince Linux to switch to Zig. I truly think the stability is the only reason for the Linux Kernel not to switch to Zig.
Zig already does everything C does in a much better and safer way. If we can sweeten the pill for them, it might be worth it.
If we could even get Linus to say β€œI’m looking into Zig for the Linux Kernel”, it would be a huge win for the language.

1 Like
6

Linux will not convert to C++ as long as Linus is running the show. Zig is too unstable at the moment to be the main work-horse but it can be a good language for some niche device drivers. It can do anything C does and more.

2 Likes
7

I think it could be interesting as a showcase/experiment, but personally I think a better way is to work on the language and ecosystem, until it becomes the best choice and people just start using it by their own choice.

I don’t like pushing languages on people, I don’t think it is a great experience when somebody comes in saying β€œhey I rewrote your project in my favorite language, it is much better now, by the way I don’t have time to maintain it, so please do that for me, will you?”
I don’t think that is what you intend, but I think it is likely that it is received that way.

Based on what, are you a kernel developer?
I prefer zig over c++ too, but I have no kernel experience, why would I make choices for them? I don’t think theoretical language comparisons are enough, we can’t just discard other peoples practical experience and preferences, just because it is difficult for us to get their perspective.

I think you only should be part of language choices in projects where you are an active contributor, I don’t work on the kernel, so I prefer to let them make their own choices. I don’t think it makes sense to β€œbackseat game” other communities.

If you are part of the kernel developer community that changes things,
then maybe you should try to find other kernel developers interested in zig.

Zig zen:

  • Together we serve the users.

Lets build good tools, instead of building hype.

19 Likes
8

I think it’s also important for the Zig core team to flesh out the language to it’s logical and (mostly) final syntax first. There’s been some breaking changes (that are very fundamental, not just add-ons) that could make the progress frustrating. For instance, we have multiple value initialization that just got brought in last year (I believe). I’d like to see that side of the language fleshed out first.

I think it’ll get to that point, but if you just go through the git issues list, there’s plenty to choose from that should be finished first before using it to replace large parts of infrastructure. Love or hate C, it has decades of work thrown at it. I also don’t think we can really say for sure until the issues with LLVM are sorted out.

So yes, avoid hype - stay honest. Best path forward.

10 Likes
9

I could see Zig being used for some new driver in the kernel, but converting the entire kernel would be pretty much impossible. I mean, it’s over 17 million LoC. Even C-translate wouldn’t work, since it might get some but then you’d have to comb through the generated code to fix what it either couldn’t translate or make what it did translate more idiomatic. It’s an interesting thought experiment though. I do think Zig is too unstable right now for a project like Linux. Once the language gets stable, I could definitely see it used.

10

I agree tha Zig isn’t ideal yet. The problem is Linux has used C for 32 years. If they pick up C++, they’ll only consider a new language in another 32 years. It would be a shame if Zig lost this spot when it’s so close to being ideal for the job.

11

I’ve made some waves in FreeBSD community also.

2 Likes
12

It’s so nice to see a well-informed group having a technical discussion:
aylead96

I see a syntax resemblance of javascript in example code. I assume that zig is not native/compiled language and that is a big no no is OS development mostly.

The vast majority of people there are C zealots, that firmly believe C is peak programming, making it literally impossible to surpass. Never thought I would see so much religiousness in an OS forum.

One guy kept arguing that Zig wasn’t fit because of it requiring bindings to C code, even after being told, with multiple references, that it doesn’t.

4 Likes
13

I assume that zig is not native/compiled language

Mamma Mia… :flushed:
β€œΠ˜ эти люди Π·Π°ΠΏΡ€Π΅Ρ‰Π°ΡŽΡ‚ ΠΊΠΎΠ²Ρ‹Ρ€ΡΡ‚ΡŒΡΡ ΠΌΠ½Π΅ Π² носу”
I (and google too) do not know how to express this phrase in English.

3 Likes
14

I think this will happen naturally. As someone who’s a C developer, I can tell you that nobody that I know really β€˜wants’ C; it’s just the de facto. C has many qualities, but I think it’s reasonable to say that a language designed 50 years ago is not shaped to define the next 50 years of computing. From the perspective of a C developer, I don’t really see why you wouldn’t pick Zig once it’s mature; it’s such an obvious choice, in my opinion.

I know that a ton of people like to believe that β€˜C will never die,’ and they will provide the same argument that β€˜Many have tried, none have succeeded.’ This is true, but also, to my knowledge, I don’t think there ever was any language whose entire philosophy, tooling, and capacity were made to replace C. None have succeeded because nobody really tried; they might have advertised themselves as such, but that’s not the same.

Zig already provides a good experience for the developer than C, despite being still a very young language. The toolchain is better, the defaults are better, and basically all of the very error-prone patterns in C are safer to express in Zig already. Take the β€˜defer’ or β€˜errdefer,’ for example; that one feature right thereβ€”how many β€˜goto’ statements can it shave off in the Linux kernel while also improving the correctness and readability of the code base? For fun, I downloaded from GitHub the Linux kernel to count the result:

β”Œβ”€(~/workspace/temporary/linux)──────────────────────────────────────────────────────────────────────────────────(plgol@pollivies-MBP:s000)─┐
└─(10:50:42 on master ✹)──> sc goto | wc -l                                                                             130 ↡ ──(Sat,Jan20)β”€β”˜
  199715

That one feature alone can probably save 150k lines of code for free. This is just one silly example, but with comptime now, how many β€˜void*’ can we avoid?

β”Œβ”€(~/workspace/temporary/linux)──────────────────────────────────────────────────────────────────────────────────(plgol@pollivies-MBP:s000)─┐
└─(10:52:44 on master ✹)──> rg 'void\s*\*' | wc -l                                                                            ──(Sat,Jan20)β”€β”˜
  102424

The same thing now with β€˜optional’ in Zigβ€”how much more safety can we gain from replacing all checks against null in C?

β”Œβ”€(~/workspace/temporary/linux)──────────────────────────────────────────────────────────────────────────────────(plgol@pollivies-MBP:s000)─┐
└─(10:57:23 on master ✹)──> rg '\s*\(!\s*\w+\s*\)' | wc -l                                                                    ──(Sat,Jan20)β”€β”˜

  128116
β”Œβ”€(~/workspace/temporary/linux)──────────────────────────────────────────────────────────────────────────────────(plgol@pollivies-MBP:s000)─┐
└─(11:04:35 on master ✹)──> rg '\s*\(\s*\w+\s*!=\s*(NULL|0)\s*\)' | wc -l                                                     ──(Sat,Jan20)β”€β”˜

  9677

My point is that once Zig becomes mature and more people become aware of its existence and features, it will most certainly make its way into the Linux kernel. At the very least, as a toolchain, but more realistically, as an easy path to maintain/extend/rewrite modules of the kernel.

7 Likes
15

I think I get the gist… :slight_smile:

I believe two good ways to counter these arguments would be to:

  1. Show a small function in Godbolt, comparing the results of compiling the equivalent code in C and Zig.
  2. Write a small, non-trivial utility / program, that does something similar to a utility written in C, and compare source code size, object size, performance, etc. And then show off cross-compilation as a cherry on top. Something like wc?
1 Like
16

Try the same with Nim lang source, 1510k+ or so,
But, yeah, it’s a jump optimization in majority of the cases.
Same thing as likely/unlikely macros.
Btw, is there something similar in Zig?

17

Of course those numbers are kind of meaningless, at this point everything in the kernel is top notch C I’m sure of it, but I think the bigger picture is that, Zig can offer a lot of conveniences, by simplifying the pipeline of development, having only one tool necessary for the whole tool chain would simplify every aspect of the kernel development. Being extremely readable by construct, Zig would also greatly simplify the process of discovery, testing, and extension. Those numbers are just to show roughly show how many β€œerror prone idioms/constructs” could be avoided or simplified by using Zig. Which I’m sure every kernel developer would be happy to see, their job is already complex enough, they will most certainly appreciate, the simplicity and convenience of a language like Zig.

1 Like
18

23 posts were split to a new topic: C goto vs Zig defer / errdefer / break

19

23 posts were split to a new topic:

thanx! it was worth it.

2 Likes