On Monday, 25 May 2020 at 13:04:42 UTC, IGotD- wrote:
> On Monday, 25 May 2020 at 11:33:21 UTC, Dibyendu Majumdar wrote:
>>
>> First is memory safety - I believe the only way to write OS in D or Rust is to use unsafe constructs in parts. Arguably this can be done in C++ too - mostly use smart pointers for example, and make restricted use of unsafe code.
>
> Memory management in OS development is special and differs a lot from writing normal applications. In C++, you usually don't use STL at all because it is usually configured for some other operating system and will not compile at all. Just including std::shared_ptr will include a lot of other things and compilation will fail. Second, there are hidden allocations in the STL containers and you don't want those when writing operating systems. With operating systems you want to control every allocation in order to minimize memory use and fragmentation. Linux is full of "smart pointers" ie. reference counting but they are done manually. Same would be in C++, reference counting is done manually. You want to minimize the increase/decrease of counters in such environment, something you might not care that much about in applications.
>
> There are other things that you avoid in C++, like std::function that has hidden allocations. Operating systems developers usually make a special library that is tailored for such development. Also forget about exceptions and RTTI.
>
> Right now C++ seems to be the best fit for operating system development. Extra safety like bounds checking in D is a good thing but the full feature set of C++ still out-competes D as you have to use betterC.
>
> The memory safety in for example Rust is just in the way when writing operating systems. You have to resort to so many tricks outside the safe language that it is more or less useless. Also Rust is a highly annoying language when it comes many classical data structures. D is in a middle spot here but lacks features like full polymorphism in betterC which still makes C++ a better choice.

Apparently people writing high integrity kernels in languages like Ada/SPARK don't find bounds checking a nuisance.

Which by the way, also applies to C and C++ written kernels via static analysis tooling validation like MISRA and AUTOSAR.

On Monday, 25 May 2020 at 14:20:39 UTC, Paulo Pinto wrote:
>
> Apparently people writing high integrity kernels in languages like Ada/SPARK don't find bounds checking a nuisance.
I looked at generated assembler if boundscheck=off did something and found that in few places that I looked it did nothing. Most array accesses happen in a foreach loop and compiler is smart enough to remove those checks. I haven't done thorough investigation but my guess is that array bounds checks are left in places where you should have checks even if you wrote that code in C.

On 5/25/2020 1:48 AM, Ali Çehreli wrote:
> It would be wasteful to write an OS to prove the claims. Unless there is a technical impossibility, then it's doable.
> 
> Let's do it the other way: What proof there is for the claim that those languages cannot be used for writing OSes? I know D enough to know that it can be used to manage a CPU, send electrical signals to all the I/O devices around it, etc.

I've written embedded systems with no operating system, and drivers for operating systems.

There's no technical reason why DasBetterC can't be used for this. In fact, it would shine at it.

On 5/25/2020 4:33 AM, Dibyendu Majumdar wrote:
> First is memory safety - I believe the only way to write OS in D or Rust is to use unsafe constructs in parts.

Rust is heavily reliant on unsafe library modules to get key things done. D relies on that, too (hence @safe and @system code), but Rust's more restrictive model needs more of it. @live will, too.

On Monday, 25 May 2020 at 20:30:51 UTC, welkam wrote:
> On Monday, 25 May 2020 at 14:20:39 UTC, Paulo Pinto wrote:
>>
>> Apparently people writing high integrity kernels in languages like Ada/SPARK don't find bounds checking a nuisance.
> I looked at generated assembler if boundscheck=off did something and found that in few places that I looked it did nothing. Most array accesses happen in a foreach loop and compiler is smart enough to remove those checks. I haven't done thorough investigation but my guess is that array bounds checks are left in places where you should have checks even if you wrote that code in C.

Indeed, bounds checking elision has been a thing for ages in everything else other than C / C++ / Objective-C, and mostly when it doesn't work, it is considered a compiler bug that needs to be eventually fixed.

On 5/25/2020 1:28 AM, Chris wrote:
> On Sunday, 24 May 2020 at 04:25:07 UTC, Walter Bright wrote:
>>
>> Joakim is welcome to return anytime he wants, and we've told him that.
> 
> So you forgive him? Great!

We didn't ask him to leave. We only required that he conform to the forum rules. Anyone is welcome here if they comport themselves in a professional manner.

On 5/25/2020 1:23 AM, Chris wrote:
> Secondly, again you do not answer a single question or address any of the issues raised. This pattern stared to emerge around 2017 I think. Instead of addressing issues raised the manner in which they are raised is more important. So an inconvenient comment / question is either labelled as "unprofessional" or "unspecific". In this way you don't need to address the issue. Hm, politicians do that when they have no substantial arguments, engineers shouldn't behave like that. So once again:

You're not getting a response as long as you keep asking questions in a rude manner.

On 5/23/2020 8:18 AM, Tony wrote:
> seem to visit the forum to solely to get perverse pleasure from degrading the language and those who work on it.

We expect professional decorum at all times toward all forum members.

On Mon, May 25, 2020 at 01:31:37PM -0700, Walter Bright via Digitalmars-d wrote: [...]
> DasBetterC
[...]

Everytime I see this, I can't help thinking it's faux-German for "*the* better C". :-P


T

-- 
The early bird gets the worm. Moral: ewww...

On 5/25/20 3:20 PM, H. S. Teoh wrote:
> On Mon, May 25, 2020 at 01:31:37PM -0700, Walter Bright via Digitalmars-d wrote:
> [...]
>> DasBetterC
> [...]
> 
> Everytime I see this, I can't help thinking it's faux-German for "*the*
> better C". :-P
> 
> 
> T
> 

Walter said he noticed the same thing a few days before his DConf 2018 presentation in Munich. :)

Ali