Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Better C – A subset of D Programming Language

dlang.org

Post reply on HN
Print view View original

61–70 of 360 posts

Re: Better C – A subset of D Programming Language

#61

Post by WalterBright »

yvdriess wrote: post #55
WalterBright wrote: post #4

Walter here - AMA!

A compiler related question: A often recurring C idiom is passing a pointer to a struct as function argument where passing the plain struct by copy would do. A big reason is the good old 'passing by pointer is faster', which I thought to be no longer relevant with modern optimizing compilers. Of course I found out the hard way that even on modern compilers object copies are not elided on call. I had performance sensi…

> Can it guarantee that (immutable) argument copies will be elided in certain circumstances?

No, but it's an interesting idea I never thought of. By the way, passing by 'ref' works handily and avoids icky pointer passing, while being efficient. I recommend as a "best practices" coding style using 'ref' parameters instead of pointers where possible.

Re: Better C – A subset of D Programming Language

#62

Post by arunc »

WalterBright wrote: post #4

Walter here - AMA!

Hi Walter, I have two questions:

1. Why do functions need to be annotated with @safe and nothrow in betterC? Why not make them default? I understand making it default for non-betterC might break some code.

2. string type was uniform and awesome until it was treated as Unicode. Any plans to fix this and remove auto decoding? That would be awesome.

Edit: three questions to two. I had another question about using threads in betterC. But looks like we can't use D threads as they are runtime dependent.

Re: Better C – A subset of D Programming Language

#63

Post by pjmlp »

kreco wrote: post #45

It's interesting how this works: - enumerate everything C is doing bad. - presents fixes with a full bag of unnecessary features that no c programmer wants. I wonder why there is no "Fixed C".

That is why they are now persona non-grata on Apple, Google and Microsoft platforms.

So on Apple platforms they will eventually have to deal with C++ and Swift no matter what.

On Microsoft platforms, they complain about C support and get shown the door to C++.

And on Google platforms, given the years of ignoring security advices, starting with Android 11, hardware memory tagging is a required feature, with the kernel randomly attaching GWP-ASan to processes, while on ChromeOS Linux gets to run on a hypervisor sandbox.

Re: Better C – A subset of D Programming Language

#64

Post by neutronicus »

skohan wrote: post #34
sgt wrote: post #14

D is pretty exciting. Seems like a perfect choice for those of us looking for an alternative systems programming language and are not completely convinced we'll be happy in Rust.

Yeah I think "better C" is a space which has a really good reason to exist and I'm always interested to see new entrants. IMO describing Rust as a "C replacement" is slightly off the mark because Rust's value proposition is very different from C. Rust is about giving you the best possible performance in a safe-by-default language. C is about giving you maximal control over memory, with a very thin layer of abstractio…

Rust is essentially C++ with auto-generated Move Constructors, and compiler errors on use-after-move, at the cost of preventing library developers from providing function overloads that eat temporaries as an optimization.

So, yeah, really not a C replacement at all imo

Re: Better C – A subset of D Programming Language

#65

Post by pjmlp »

skocznymroczny wrote: post #23
dgellow wrote: post #8

Earlier quoted context omitted.

Do you know of use of “BetterC” in real-life (i.e: for non-pet projects)? It would be interesting to hear about some real use cases.

BetterC is interesting because it allows you to compile D to WASM. Unfortunately D runtime and GC haven't been ported to WASM yet so they are not fully supported.

It was recently discussed in the forums, it should be coming, the actual situation has delayed the development.

Re: Better C – A subset of D Programming Language

#66

Post by dgellow »

WalterBright wrote: post #37
skohan wrote: post #34

Earlier quoted context omitted.

Yeah I think "better C" is a space which has a really good reason to exist and I'm always interested to see new entrants. IMO describing Rust as a "C replacement" is slightly off the mark because Rust's value proposition is very different from C. Rust is about giving you the best possible performance in a safe-by-default language. C is about giving you maximal control over memory, with a very thin layer of abstractio…

D also now supports Ownership/Borrowing (experimental) on a per-function basis, meaning it can be added incrementally to an existing program.

For reference, the blog article on borrowing/ownership from 2019: https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...

Re: Better C – A subset of D Programming Language

#67

Post by logicchains »

drfuchs wrote: post #43
logicchains wrote: post #32

Earlier quoted context omitted.

Are you aware of anyone with large projects in Zig? I'm curious how fast it compiles, given in my view faster compilation is one of the biggest advantages of D over C++ and Rust, due to it having a lightweight compiler, DMD. Zig seems to still use LLVM, like Rust, which is relatively slow.

In his live-stream three days ago, Andrew Kelley showed the beginnings of Zig directly generating debug-mode executables, very quickly. And that’s before incremental compilation and linking. This guy is amazing. https://www.twitch.tv/videos/602715503 [edit: at 10:20]

Ah, that's awesome! Really cool to see a new language taking compile-time so seriously.

Re: Better C – A subset of D Programming Language

#68

Post by pjmlp »

augustk wrote: post #47
kqr wrote: post #35

This is a great idea. I maintain that Ada is a better "better C" than any of the alternatives I've looked into, but it has an obvious big hurdle: while it has approximately the same use cases as C, it is completely different in terms of looks and handling. One of the strong points of D is that it still seems very much like C. Very good call to emphasise this.

For me Oberon is the better C. https://www.miasap.se/obnc/oberon-report.html

On the Oberon linage that place belongs to Active Oberon.

http://cas.inf.ethz.ch/news/2

Only Active Oberon exposes non traced references, RAAI and a couple of other low level features that made it more complex to do systems programming in Oberon and Oberon-2, let alone Oberon-07.

Re: Better C – A subset of D Programming Language

#69

Post by asdkjh345fd »

neutronicus wrote: post #52
asdkjh345fd wrote: post #49

Earlier quoted context omitted.

>With highly generic functions, it's often not possible to know what they'll return without knowing what you'll call them with. Of course it is. Map's type is "(a -> b) -> [a] -> [b]". D just absolutely and completely failed here, despite this being a solved problem 40 years ago.

It doesn't have to be specialized to []

Of course not. But it still has a type.

Functor f => (a -> b) -> f a -> f b

Re: Better C – A subset of D Programming Language

#70

Post by asdkjh345fd »

jcelerier wrote: post #57
asdkjh345fd wrote: post #49

Earlier quoted context omitted.

>With highly generic functions, it's often not possible to know what they'll return without knowing what you'll call them with. Of course it is. Map's type is "(a -> b) -> [a] -> [b]". D just absolutely and completely failed here, despite this being a solved problem 40 years ago.

no ? there are plenty of maps which don't return something which looks like [a] -> [b].

So? They still have a type, it doesn't have to be "screw you figure it out yourself".

Functor f => (a -> b) -> f a -> f b

Post reply on HN