Live data from Hacker News

Better C – A subset of D Programming Language

dlang.org

91–100 of 360 posts

Re: Better C – A subset of D Programming Language

#91
post #15
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.

Mine is Zig.

Andrew needs to radically change his stance on Tabs for the language to be taken seriously. White space must be ignored, and Andrew should overlook his personal bias and cater to the ‘preserve white space’ crowd. Because formatting and readability matter - a lot.

Re: Better C – A subset of D Programming Language

#92

Walter here - AMA!

Would it make sense to spin "Better C" off into a separate language? It would for example help to create an ecosystem of 3rd party libraries not dependent on gc.

No. D already has image problems with D1 and D2 (as in people crop up on the forum asking about it a decade after the switch), making D better C a separate language probably wouldn't be a great idea

Re: Better C – A subset of D Programming Language

#93
post #83
post #80

Earlier quoted context omitted.

There have been many, many "Fixed C"'s. That's the problem. This isn't a technology issue, it's a social one.

I'm actually curious. until now I came across new language that sells themselves as c replacement but with a lot and lot of new features, usually "here is a new language it does a lot more than C but still compatible with it". examples in top of my head: - adding object oriented feature like built-in constructor/destructor while only default values are needed as week as a defer statement. - weird template, while I ca…

There's no such thing as a hygienic macro system if you mean textual macros.

Also array type is the single biggest thing required to fix C. How many bugs in big C projects are caused by bad indexing and overruns.

On top of, "oh no free features".

Re: Better C – A subset of D Programming Language

#94

Earlier quoted context omitted.

Another reason for C/C++ is that they are very permissive with implicit lossy conversions. If you specified explicit type, chances are the compiler helpfully made a lossy conversion for you.

Sutter made that point under Maintainability and robustness . Like Sutter's answer, this point doesn't answer the complaint. People on the anti- auto side say it seriously harms readability, as locals' types are no longer clear at a glance. They aren't asking for a list of reasons why some people favour auto , they're asking for an answer to their readability problem. Perhaps IDEs could infer types and display them a…

Herb didn't say it well enough. It's a tradeoff between correctness and readability. If it wasn't for C++'s weak type system you wouldn't be required to make this tradeoff and could improve readability while still staying correct.

Re: Better C – A subset of D Programming Language

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

I’ve always liked the idea of Ada, but never had a place to use it. Though someone on HN pointed out that NVidia was using Spark for secure code sections. Quite interesting! Personally while D seems a great tool, I really keep running into situations where a language that lives on top of C/C++ is useful. So I’ve been trying out Nim for those use case, using the ARC GC which appears to work well for embedded. It’s det…

Most likely me, or not.

In any case here are the latest news on the subject,

"GTC 2020: Exterminating Buffer Overflows and Other Embarrassing Vulnerabilities with SPARK Ada on Tegra"

https://developer.nvidia.com/gtc/2020/video/s21122-vid

Another well know project that is now adopting Ada/SPARK is GenodeOS, https://genode.org/about/road-map

Re: Better C – A subset of D Programming Language

#96
post #24
post #3

One thing that really annoyed me about D is that its documentation lists basically every function with an 'auto' return type. Auto should be completely banned from documentation, it's a complete hindrance. It's the single biggest contributor to why I stopped using D for personal projects - I was so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it and looking…

The use of Auto is requires in some places because the standard library returns types that cannot be named in the context of the calling function. This happens for example with algortihms that return a custom Range implementation that is declared within the scope of the function implementing the algorithm. I am not sure what to make of this pattern. At least the documentation should be more explicit about these Volde…

Is Range a kind of interface? If yes, then wouldn't that be the appropriate return type?

edit: Looking at other answers, I think Range is probably not an interface like they exist in Java, but rather a pattern of behavior per templates in C++. Concepts are supposed to solve this problem in C++, but I don't know how well they actually do.

Re: Better C – A subset of D Programming Language

#97
post #93
post #83

Earlier quoted context omitted.

I'm actually curious. until now I came across new language that sells themselves as c replacement but with a lot and lot of new features, usually "here is a new language it does a lot more than C but still compatible with it". examples in top of my head: - adding object oriented feature like built-in constructor/destructor while only default values are needed as week as a defer statement. - weird template, while I ca…

There's no such thing as a hygienic macro system if you mean textual macros. Also array type is the single biggest thing required to fix C. How many bugs in big C projects are caused by bad indexing and overruns. On top of, "oh no free features".

I am hoping that at least Microsoft's Checked C doesn't die like so many other attempts.

Re: Better C – A subset of D Programming Language

#98
post #76
post #3

One thing that really annoyed me about D is that its documentation lists basically every function with an 'auto' return type. Auto should be completely banned from documentation, it's a complete hindrance. It's the single biggest contributor to why I stopped using D for personal projects - I was so tired of having to hunt down what functions are going to return, sometimes having to resort to just using it and looking…

Vim vs emacs, auto inference vs explicit, I don't think it will ever end. :)

Aren't there any type synthesizers which modify your code based on inferenced types?

Re: Better C – A subset of D Programming Language

#99
post #26
post #15

Earlier quoted context omitted.

Mine is Zig.

Zig is still very experimental though, the language isn’t stable yet

Definitely. However I will say that Zig does so many things right already that I struggle to code in more mature languages without thinking "I wish I was writing Zig right now" all the time.

Re: Better C – A subset of D Programming Language

#100
post #96
post #24

Earlier quoted context omitted.

The use of Auto is requires in some places because the standard library returns types that cannot be named in the context of the calling function. This happens for example with algortihms that return a custom Range implementation that is declared within the scope of the function implementing the algorithm. I am not sure what to make of this pattern. At least the documentation should be more explicit about these Volde…

Is Range a kind of interface? If yes, then wouldn't that be the appropriate return type? edit: Looking at other answers, I think Range is probably not an interface like they exist in Java, but rather a pattern of behavior per templates in C++. Concepts are supposed to solve this problem in C++, but I don't know how well they actually do.

A Range is something that implements one or more interfaces depending on its properties and guarantees. So in order to name a Range that way you'd first have to create interfaces for all possible guarantees. That doesn't sound practical. It's analogous to C++ containers implementing common concepts without deriving from corresponding interfaces.

See also https://tour.dlang.org/tour/en/basics/ranges

Post reply on HN