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!

On 5/24/20 4:08 AM, Dibyendu Majumdar wrote:
> On Sunday, 24 May 2020 at 11:01:58 UTC, Les De Ridder wrote:
>>
>> C++ and D(asBetterC) are viable replacements in my experience. C++
>> explicitly has design goals like 'Leave no room for a lower level
>> language' and the zero-overhead principle. These generally apply to
>> DasBetterC too.
>>
>> Many would also argue that Rust and some newer languages like Zig fit
>> the bill too.
> 
> Well the jury is still out on these. Until we see a real OS written in Rust or D or Zig - he proof is not in claims but in the doing.

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.

Ali

On Sunday, 24 May 2020 at 11:08:42 UTC, Dibyendu Majumdar wrote:
> On Sunday, 24 May 2020 at 11:01:58 UTC, Les De Ridder wrote:
>>
>> C++ and D(asBetterC) are viable replacements in my experience. C++
>> explicitly has design goals like 'Leave no room for a lower level
>> language' and the zero-overhead principle. These generally apply to
>> DasBetterC too.
>>
>> Many would also argue that Rust and some newer languages like Zig fit
>> the bill too.
>
> Well the jury is still out on these. Until we see a real OS written in Rust or D or Zig - he proof is not in claims but in the doing.

The improvements that Microsoft has been doing to .NET out of their Midori and .NET Native experience, alongside their recent announcement at BUILD 2020 for first class support for Rust on Windows, alongside Amazon, Oracle, Apple and Google's ongoing adoption on their OS and cloud platforms, kind of prove the point for me.

I occasionally still come over here due to the community, and less so about D.

On 5/22/20 8:28 AM, Chris wrote:> On Friday, 22 May 2020 at 15:27:13 UTC, Chris wrote:
>
> Just in case, I'd like to have an answer to this:
>
> Is there an update of the companies that use D? How many really use it,
> do the companies listed still use D (what about sociomantic?) and what
> do they use it for? Facebook is listed, I remember Andrei did some stuff
> (including a script like program), are they still using it actively?

Unless the users are as excited as I am to present at conferences how they benefit from D, nobody can answer those questions. Open source does not work that way. Even if one asked Sociomantic or Facebook, they are not obliged to give answers.

Ali

On Monday, 25 May 2020 at 08:25:30 UTC, Chris wrote:
> On Saturday, 23 May 2020 at 16:01:22 UTC, Mike Parker wrote:
>> On Saturday, 23 May 2020 at 14:33:02 UTC, Chris wrote:
>>
>>>
>>> Deleting criticism is certainly not the right approach and will come back to bite you. Sometimes it's easier to just do the dishes than to come up with ever new excuses why you can't do the dishes. Why not write a new clean version of D?
>>
>> Again, we aren't deleting criticism. If we were, 90% of your posts would have hit the bin by now. I repeat myself: criticism is welcome, the denigration of community members is not.
>
> 90%? Where's the proof? You shouldn't make exact statements like that based on an estimate.

Dont feed the troll.

On Monday, 25 May 2020 at 09:00:03 UTC, Ali Çehreli wrote:

> Unless the users are as excited as I am to present at conferences how they benefit from D, nobody can answer those questions. Open source does not work that way. Even if one asked Sociomantic or Facebook, they are not obliged to give answers.
>
> Ali

Fair enough, but I think it would make sense to contact those companies. I'm sure Facebook would be willing to give you an answer like "We are still using it actively." However, if you list Facebook on your homepage and _if_ it's only because Andrei once wrote some stuff (because he actually worked there), that looks a bit weird, exaggerated, not optimal. Imagine somebody finds out that your claims are inflated, they might get very angry.

By the way, you're probably one of the people to ask this question. Are there annual financial reports of the D Language Foundation? How the money was spent etc.?

On Monday, 25 May 2020 at 08:48:33 UTC, Ali Çehreli wrote:
> On 5/24/20 4:08 AM, Dibyendu Majumdar wrote:

>> 
>> Well the jury is still out on these. Until we see a real OS written in Rust or D or Zig - he proof is not in claims but in the doing.
>
> It would be wasteful to write an OS to prove the claims. Unless there is a technical impossibility, then it's doable.
>

Of course that would be silly. My assumption is that someone will write an OS in one of these languages because of security concerns. I think Google is looking at using Rust in Fuchsia. Fuchsia is interesting because the kernel was initially in C, but now I believe mostly it is in C++ to gain additional type safety.

https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master/docs/project/policy/programming_languages.md

> 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.
>

Well there are several things to consider.

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.

Secondly a real world OS that is used can tell us if truly the resulting OS was more secure than say Linux which is written in C. Right now there are theoretical claims that the OS will be more secure.

In case of Rust there is an additional question - can development scale? Rust is particularly hard programming language in my view. Writing simple linked list or tree structure is not a trivial task in Rust. So can it scale to thousands of developers?

Finally performance impact of safe code. One of the reasons why folks use unsafe practices is that it is most performant.

I am not suggesting that D cannot be used to write an OS, but it remains to be seen whether an OS written in D or Rust is actually more secure in the real world.

On Monday, 25 May 2020 at 11:33:21 UTC, Dibyendu Majumdar wrote:
> On Monday, 25 May 2020 at 08:48:33 UTC, Ali Çehreli wrote:
>> On 5/24/20 4:08 AM, Dibyendu Majumdar wrote:
>
>>> 
>>> Well the jury is still out on these. Until we see a real OS written in Rust or D or Zig - he proof is not in claims but in the doing.
>>
>> It would be wasteful to write an OS to prove the claims. Unless there is a technical impossibility, then it's doable.
>>
>
> Of course that would be silly. My assumption is that someone will write an OS in one of these languages because of security concerns. I think Google is looking at using Rust in Fuchsia. Fuchsia is interesting because the kernel was initially in C, but now I believe mostly it is in C++ to gain additional type safety.
>
> https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master/docs/project/policy/programming_languages.md
>
>> 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.
>>
>
> Well there are several things to consider.
>
> 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.
>
> Secondly a real world OS that is used can tell us if truly the resulting OS was more secure than say Linux which is written in C. Right now there are theoretical claims that the OS will be more secure.


That one is easy, IBM i and IBM z/OS are written in a mix of Assembly and PL/S. Modern versions now also include C++, but it wasn't there during their first 20 years.

Unisys ClearCase MCP, written in NEWP, an almost safe systems programming language, 10 years older than C, the OS doesn't do Assembly, all CPU low level features are exposed as compiler intrisics.

Was one of the first OSes to introduce the concept of unsafe code already during the 60's, any executable or library with unsafe code is tainted and requires admin being signed off by the admin for execution.

Unisys still keeps it around and sells it to governments and business that need three letter agency security level access for data processing.

Common to all of them, C is only used on the POSIX containers.

On Sunday, 24 May 2020 at 06:08:42 UTC, H. S. Teoh wrote:
> On Sat, May 23, 2020 at 09:05:47PM -0700, Walter Bright via Digitalmars-d wrote:
>> [...]
>
> On Sat, May 23, 2020 at 09:15:18PM -0700, Walter Bright via Digitalmars-d wrote:
>> [...]
>
> [...]

I totally agree with this. I am teaching low-level courses like assembly language and operating systems and I have to tell you most of the students (even top students) have a lot of problems implementing data structures correctly in C. Almost all of them make mistakes with regards to null-terminated strings, arrays and pointers. That is mostly because they are focused on implementing the actual algorithm/solution and they do not care about the rest of the details. If a veteran programmer sometimes accidentally introduces a buffer overflow bug, imagine how it is for a young programmer that is eager to focus on interesting problems and doesn't care about boring stuff like making sure the length of the array is correct.

We are talking about students that will get hired in 1-2 years and most likely it will take a while before they actually understand the importance of paying attention to this sort of issues; in the mean time they will recklessly introduce vulnerabilities all over the place. Having an automatic method of verification is the best solution to this sort of problem. Languages have evolved enough so that we should not concern ourselves with such low-level details.

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.