5 ms·

C++ was discussed as having too many undesirable characteristics. But that's exactly why I think a customized language for the kernel is an interesting idea. Y

• Koshkin 5y ago
  The desirable characteristics of C++ overweigh, by far, its "undesirable" ones (whatever those may be, and which by the way you can for the most part safely ignore, if you wish).
  • chaxor 5y ago
    I don't know anything about C++ really, but I have been interested in learning it several times. The biggest deterrent for me has been the huge number of languages that you have to know to learn c++ it seems. Every new version comes with so many different features and seemingly (by looking for example repos on git) different paradigms that it essentially feels like many different languages. This is probably one of the biggest reasons I may turn to rust over C++ - simply less features creep due to less time being around. Can you comment on how wrong I am about my feelings this way?
    • Koshkin 5y ago
      Yes, I understand, I would probably feel the same if I wanted to learn C++ all at once and for its own sake. Luckily, I have never had to do such a thing. Indeed, I may never learn C++ in its entirety, and I may even miss some "important" pieces, but I am OK with that. I am very comfortable using C++, and I still continue picking up pieces of wisdom here and there - as I go. My advice, learn by example, start with a small project and go from there.
    • kllrnohj 5y ago
      Learning/teaching C++ is definitely a sore spot about it. Many still teach C++98 which is... Bad. It'd be like still teaching Java 1.3. yeah the syntax is the same basic shape, but pretty much everything else is different. C++11 and newer are all largely one "category" in terms of recommendations. The CppCoreGuidelines is a good place to cover all that, but it's not a from-scratch introduction by any means
    • midjji 5y ago
      Not wrong, but its a feature, rather than a problem. C++(17+) template based metaprogramming far more powerful and generic than what you can do in eg rust. Converting eg a rust or go or python, or julia, etc library into c++ is pretty straightforward, just use appropriate overloads, and a few template tricks, and you can mostly copy the code directly. But copying between these, or from c++ is much harder. The solution is to learn one approach suitable for the problem you have right now, then widen over time. The many languages of c++ as you describe is less of a problem, the problem is that some approaches are deeply and fundamentally flawed, but still in common use.
• jcelerier 5y ago
  > C++ was discussed as having too many undesirable characteristics. C++ allowed the Serenity OS people to produce an entire OS with a GUI stack able to play Diablo and their own web browser in something like two years. It's depressing to think where we could be today in terms of OS if the Linux and GNU people weren't as insistent on their hate of C++
  • tayo42 5y ago
    Why is c++ necessary? Shouldn't any programing language be able to do the same things. Maybe with different amounts of code
    • Koshkin 5y ago
      Sure, as my prof once noted, "Why, with the assembler you just need to type more!"
      • microtherion 5y ago
        You must have had one of those progressive professors who did not consider assemblers "a waste of a valuable scientific computing instrument [...] to do clerical work": http://worrydream.com/dbx/ http://worrydream.com/dbx/
        • reasonabl_human 5y ago
          I love historical anecdotes like this. Goes to show that we should always be questioning our status quo and thinking bigger.
    • josefx 5y ago
      Please write a JavaScript program that will not deploy to your production system if you accidentally pass a string to any function that expects an integer.
      • cprecioso 5y ago
• kllrnohj 5y ago
  Let's say you wanted to do that but also stay in the C family. It's going to be a lot easier to take C++ and just ban all the stuff you don't like (such as via lint rules) than to make a new language. In the former case you continue to benefit from all the ecosystem compiler & tooling improvements (ide support, static analysis, etc...). In the latter case you're on your own. Which is no small burden here. I'm not necessarily advocating that Linux should switch to C++, just that there's probably not a good reason to invest in a new C/C++ hybrid language at this point in time. Not when C++11 is honestly pretty good, but also Rust, Zig, or even D's betterC all already exist.
  • tialaramex 5y ago
    C++ has implicit allocation and Linus doesn't like that, for good reason. While it's amusing to imagine trying to "ban all the stuff you don't like" when that means core language features, it is not a realistic plan. In Rust, allocation lives in a library, alloc, and so the Rust for Linux project did all the work to offer alloc (it's full of useful stuff and it isn't like the Linux kernel can't allocate memory) but without implicit allocation. If you use Rust to write say a Linux command line program, you can write greeting += " and welcome traveller"; ... and of course implicitly this is an allocation, 'cos it's not like this greeting variable just magically already has enough space to append a string. But in Rust for Linux, you can't do that, the implicitly allocating += operator is not provided on this type in their alloc library. If you want to say "Allocate more space for the greeting" you can do that of course, just as you can today in C but you must do so explicitly and so when you try to add 16GB of extra string space because you're an idiot, the API you had to explicitly call gives you an error and that's your problem. However the most critical reason Linux doesn't have C++ is that C++ proponents didn't do the work. Now, that will probably be because "reform the entire language to suit Linus" wasn't a viable plan, but the fact is that Linus can't accept patches that nobody writes, so even if you're sure C++ would be viable without drastic changes, you didn't write the patchset that does it. Likewise if people don't send Linus patches to do C11 it probably won't happen.
    • kllrnohj 5y ago
      > C++ has implicit allocation Ah, but see, it doesn't. Linus was wrong about many things in his rant. This being one of them. Now the standard library does indeed have things that do implicit allocations, such as std::string. But these, like with Rust, are distinct from the language & replaceable. Would it be effort to make a kernel-safe std:: replacement? Yes. Would it be a lot of work? Not really. And it's the kind of thing Linux has been doing for decades with C anyway. It's not like they use a standard libc implementation (much less a rich libc implementation like glibc), for example. And it's something game devs have been doing with C++ for decades without any issues, too. So for this one you don't even have to ban anything. Just don't pass a standard library implementation to the compiler. It doesn't come with one, after all. You have to add it. So you could just... Not do that. As for nobody did the work... That's true. But Linus also pretty much nuked the entire concept of using C++, regardless of the what or how. Time seems to have changed his mindset on some of those things, hence his reaction to Rust, which largely makes all this moot. But we shouldn't confuse short term politics with technical issues, either.
• xroche 5y ago
  > C++ was discussed as having too many undesirable characteristics. I tend to agree, as a C++ developer. There are many core issues in the language that haven't been resolved and that are unacceptable for kernel code. My personal pet peeve: C++ is unable to reallocate a new[] region. This makes basically all structures (vector, hashmap, trees...) unusable for large data handling.
  • pjmlp 5y ago
    Google (C++17 subset in Zircon), Apple (IO Kit drivers with Embedded C++) and Microsoft (since Vista), ARM (mbed) IBM (C++ as PL/S replacement) think otherwise.
  • kllrnohj 5y ago
    Of those structures only vector benefits from realloc anyway. And if you really want it, it's not terribly hard to write. You can static assert that the template type is trivially movable which would make it safe to realloc. But this is assuming you have a malloc implementation that does something other than implement realloc as just malloc+memcpy+free. Which not many do, not unless the allocation is so large as to be in its own dedicated mmap or similar. That aside, sure would be great if you elaborated on these unsuitable, unresolved for kernel language issues? Exceptions and rtti are the only two I'm aware of and both have had off switches for decades.
    • xroche 5y ago
      > And if you really want it, it's not terribly hard to write Sure, but basically it means rewriting all structures that rely on a bucket of stuff. By the way maps often use a large bucket, and rehash in-place can be preferable. > Which not many do, not unless the allocation is so large as to be in its own dedicated mmap Do you know a modern operating system that does not have a mremap equivalent ? On Linux you pretty much use it as soon as you reach large blocks.
      • kllrnohj 5y ago
        > By the way maps often use a large bucket, and rehash in-place can be preferable. std::unordered_map (what I'm guessing you meant by a hashmap) uses a linked list for the nodes. There's no movement in the first place to worry about being realloc'd. > Do you know a modern operating system that does not have a mremap equivalent ? You have to be very large before most mallocs will put you on a dedicated mmap that can even be mremap'd at all. If you're working with stonking huge data inline in a std:: vector... Yeah just make a container for that usage, not really an issue. There's tons of examples out there, typically to add SSO but doing realloc would be the same basic thing.