August 27, 2019
On Monday, 26 August 2019 at 21:48:45 UTC, IGotD- wrote:
> On Monday, 26 August 2019 at 16:24:30 UTC, Paulo Pinto wrote:
>>
>
> There is a lot of Rust click bait in this forum and some "look Rust can do this and that, we must have it too". I think that D should follow its own path and should not trying to ape Rust in every fashion.

I know, it's annoying. But a while ago it was Go and before that C++ (among other things). Every few years (or even every year) D is chasing after a new "must have" feature. And usually it's done, before one could possibly know if feature X will work for Go or Rust. I'd say relax a little bit and do your own thing, and maybe later you can see what features you could incorporate (that's what C++ does, I think). This "must have" mentality does a lot of damage to D, old bugs and shortcomings are neglected, there are new half-baked features, an outsider only sees a mess and insiders think "Ah, WTF!" fearing their code might break, because D now has to work with feature X. D will never learn.
August 27, 2019
On Tuesday, 27 August 2019 at 08:08:34 UTC, Walter Bright wrote:
> On 8/26/2019 4:00 AM, IGotD- wrote:
>> The speaker is right about one thing and that is that a systems programming language must not have a runtime dependency, or the runtime is completely OS independent. With this definition this includes C, C++, D (-betterC only) and Rust. As far as I know Go is runtime dependent and does not qualify for this definition.
>
> C++ requires a runtime library that supports exception handling. DasBetterC does not need anything that C doesn't have.

That's why you always disable exceptions as well as RTTI in embedded C++ programming and the runtime dependency is gone. It's a bit of shame because exception could be useful there as well.

The problem with exceptions is that it allocates dynamic memory which makes it unusable for some use cases (fragmentation, time, locking). However, this proposal from Herb Sutter

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf

is highly interesting from that point of view. Do you think this proposal would fit D?
August 27, 2019
On Mon, 2019-08-26 at 10:55 +0000, Dibyendu Majumdar via Digitalmars-d wrote: […]
> Personally I think neither Rust nor D can replace C.
> C is a high level assembler. A replacement needs to be a better
> high level assembler rather than a language that has many
> abstractions.
> The particular quality of C is that you can mentally see how your
> code translates to machine code. Languages with lot of
> scaffolding destroy this property.

But isn't that at the core of problem? C is a fairly good portable assembler and so there are no controls, and no support for ideas such as RAII unless the programmer implements it themselves. Use C and all the things such as buffer overflow are programmer problems.

If systems programmers want to escape from problems of portable assembly language programs such as buffer overrun, then they need to eschew C and portable assemblers and create a new language for systems programming. Whether Rust, Go, or DasBetterC are it is highly unlikely if the language people want is a superset of C.

I worry that the whole project of putting all the problems of C into Rust to make is a C superset ruins Rust and fails to make Rust a replacement for C.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



August 27, 2019
On Mon, 2019-08-26 at 11:00 +0000, IGotD- via Digitalmars-d wrote: […]
> 
> These are typically, intrusive lists, structures that points to each others (circular references), custom allocators. "Impossible" was a little bit the wrong word that I used. Difficult would be the word or "not worth it". Some of the algorithms can be done but those I've seen require a huge amount of boiler plate for something C would just need a few lines. Circular references is something Rust cannot deal with, unless you explicitly use pointers or RC objects. RC objects are not always welcome in systems programming and raw pointers requires you to do your own memory management so Rust loses its point. I just think the way you program Rust doesn't fit systems programming and it is not worth the extra hazzle. The amount of unsafe hatches you would open in Rust would contradict its grand "safe" selling point.

But circular data structures requires pointers in C, so to claim implementing such things in Rust using Rust pointers is a failing of Rust is a bit unfair. Also std::collections::LinkedList seems to do most of the work needed.

It is the case that the Rust split of crate_X for the Rust facing, and crate_X_sys for the C facing creates apparent infrastructure issues, but it does allow for properly constraining all the unsafe stuff into properly tested small chinks.

Writing library/application code using a Rust with a Rust facing wrapper based over the unsafe C facing wrapper makes things much, much easier that writing C code with all the manual RAII rubbish required because C has no support for RAII.

[…]
> The speaker is right about one thing and that is that a systems programming language must not have a runtime dependency, or the runtime is completely OS independent. With this definition this includes C, C++, D (-betterC only) and Rust. As far as I know Go is runtime dependent and does not qualify for this definition.

I suspect this also rules out C as a systems programming language since there is a C runtime system which is OS specific, along with the C library. :-)

But yes D and Go rule themselves out for any situation that cannot admit a GC initialisation, though I suspect fear of GC is over-prevalent in far too much of systems programming.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



August 27, 2019
On Tuesday, 27 August 2019 at 15:54:31 UTC, Russel Winder wrote:
> On Mon, 2019-08-26 at 10:55 +0000, Dibyendu Majumdar via Digitalmars-d wrote: […]
>> Personally I think neither Rust nor D can replace C.
>> C is a high level assembler. A replacement needs to be a better
>> high level assembler rather than a language that has many
>> abstractions.
>> The particular quality of C is that you can mentally see how your
>> code translates to machine code. Languages with lot of
>> scaffolding destroy this property.
>
> But isn't that at the core of problem? C is a fairly good portable assembler and so there are no controls, and no support for ideas such as RAII unless the programmer implements it themselves. Use C and all the things such as buffer overflow are programmer problems.
>
> If systems programmers want to escape from problems of portable assembly language programs such as buffer overrun, then they need to eschew C and portable assemblers and create a new language for systems programming. Whether Rust, Go, or DasBetterC are it is highly unlikely if the language people want is a superset of C.
>
> I worry that the whole project of putting all the problems of C into Rust to make is a C superset ruins Rust and fails to make Rust a replacement for C

Unless they are targeting PDP-11 class CPUs, like PICs, I doubt most C developers will understand how the auto-vectorizer and optimizer opportunities due to UB opportunities have decided to generate a specific set of Assembly code.

The portable Assembly myth of C is long gone in the age of multi-core, pipelined, out-of-order execution units, with NUMA, vector units and GPGPUs.

August 27, 2019
On Tue, 2019-08-27 at 16:07 +0000, Paulo Pinto via Digitalmars-d wrote: […]
> 
> The portable Assembly myth of C is long gone in the age of multi-core, pipelined, out-of-order execution units, with NUMA, vector units and GPGPUs.

There is the truth and there is the perception by the masses, which may be the same, but all too often are at odds.

My excuse is that I used C on PDP-11 and VAX-11, and then when new processors came along I moved on to other programming languages.

It is most interesting that imperative programming languages are inconsistent with modern processors, and yet everyone still thinks sequence is a valuable concept of a program.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



August 27, 2019
On Tuesday, 27 August 2019 at 15:54:31 UTC, Russel Winder wrote:
> On Mon, 2019-08-26 at 10:55 +0000, Dibyendu Majumdar via Digitalmars-d wrote: […]
>> Personally I think neither Rust nor D can replace C.
>> C is a high level assembler. A replacement needs to be a better
>> high level assembler rather than a language that has many
>> abstractions.
>> The particular quality of C is that you can mentally see how your
>> code translates to machine code. Languages with lot of
>> scaffolding destroy this property.
>
> But isn't that at the core of problem? C is a fairly good portable assembler and so there are no controls, and no support for ideas such as RAII unless the programmer implements it themselves. Use C and all the things such as buffer overflow are programmer problems.
>

I think that a better C would simply provide / reimplement some aspects of C so that the programmer has better hope of catching certain bugs, but not take away the essential quality of C being a high level assembler. If D could be stripped of many of its features then in the better C guise it would be close. The fact that Better C mode is an option is not ideal IMO as D is more likely to be viewed in its entirety.

Rust's problem is that it has gone to an extreme position to try to help, but in the process simple things are no longer simple, and looking at Rust code is not the same as looking at C code in terms of transparency.


August 28, 2019
On 2019-08-27 08:08:34 +0000, Walter Bright said:

> C++ requires a runtime library that supports exception handling. DasBetterC does not need anything that C doesn't have.

Is there a difference between BetterC and DasBetterC?

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

August 28, 2019
On Wednesday, 28 August 2019 at 06:01:22 UTC, Robert M. Münch wrote:
> On 2019-08-27 08:08:34 +0000, Walter Bright said:
>
>> C++ requires a runtime library that supports exception handling. DasBetterC does not need anything that C doesn't have.
>
> Is there a difference between BetterC and DasBetterC?

Das

joke aside, it's the same thing "D as better C"
August 28, 2019
On Wednesday, 28 August 2019 at 06:36:21 UTC, Patrick Schluter wrote:
> On Wednesday, 28 August 2019 at 06:01:22 UTC, Robert M. Münch wrote:
>> On 2019-08-27 08:08:34 +0000, Walter Bright said:
>>
>>> C++ requires a runtime library that supports exception handling. DasBetterC does not need anything that C doesn't have.
>>
>> Is there a difference between BetterC and DasBetterC?
>
> Das
>
> joke aside, it's the same thing "D as better C"

I read this always as "Das better C" too :D