Live data from Hacker News

D Language accepted for inclusion in GCC

gcc.gnu.org

121–130 of 235 posts

Re: D Language accepted for inclusion in GCC

#121
post #90
post #74

This is basically the work of one tireless man; Iain Buclaw. Many thanks to him for putting in so much time and energy into this. It took 6 years from first submission to get it in. Here are the slides from his 2017 DConf talk about the work that went into making this happen: http://dconf.org/2017/talks/buclaw.pdf

Slowly but steadily. Given the fact that D has not managed to die when it had so many chances to, I tell that D has better chance at mass adoption as "a better C++" than the current wave of Swift/Rust/Go that rely on "life support" from a corporate donor.

I don't think that's true. Despite their corporate life support and relatively young ages, Go, Rust and Swift are all in the top 25 most active languages on Github (https://gist.github.com/alysonla/e14c01ec7a0d2823e7317f7b58b...) and D is not (and never has been).

The masses have had a long time to adopt D and I wouldn't get my hopes up simply because it's not dead yet.

Re: D Language accepted for inclusion in GCC

#122
post #107

Earlier quoted context omitted.

If I'm not mistaken, Rust is being sold as a better C, not C++. Go is being marketed as a higher level language than C and Rust focused on developing network-aware concurrent applications to fill specific server needs. I may be wrong, but I'm not really sure that they target C++ or aim to replace it, unlike D. Perhaps that's the reason why both Rust and Go managed to gain so much traction and goodwill, because they a…

> I'm not really sure that they target C++ or aim to replace it, unlike D. The evolution of both Go's and Rust's strategies as "replacement" languages is actually pretty interesting. While Go's official marketing no longer calls it a systems language, the use of that phrase when Go was originally released does indicate that that they envisioned Go to be a "better C" in a sense (perhaps specifically in the sense of be…

I would like to contact Go's "official marketing" department and tell them they have done a horrible job at marketing, because most of the lauding for go comes from developers I know that love getting work done with it!

In any case, I will +1 you on coming from python and ruby, and add another major bucket go developers come from is node js.

Re: D Language accepted for inclusion in GCC

#123
post #70
post #6

Earlier quoted context omitted.

My guess is that is also why. gcc wants to be assured there are sufficient maintainers. If a crew has been maintaining out-tree-support with a good track record, that demonstrates maintainability.

Is this what happened to gcj, lack of maintainers? I always thought it was a shame support for it lapsed, a to native java compiler would be awefully nice to have.

Could be. I don't know the specifics. I do know that the bar is pretty high, in general, before gcc will commit. I think that simply goes with the territory with such a large project where a lot of people depend on it to just work.

For example, an acquaintance plays (at least used to) a large role in the AVR (8 bit) back-end. He went to a gcc summit to lobby for avr-gcc being upgraded to a support tier where functional (not performance) regressions would be release show-stoppers. His argument: Over a million downloads per month. It took that much to get the gcc steering committee to even consider it. gcc is a big project, they can't afford to make commitments lightly.

Re: D Language accepted for inclusion in GCC

#124

Earlier quoted context omitted.

D is like Go if Go had actually been a "systems" programming language. Rust is difficult to compare to other stuff.

To me, D's compile-time features like templates, code generation, etc. are some of its most important features. Lacking those and exceptions and many other useful bits, Go cannot compare to D. (I finally can claim experience on both languages after having coded Go for about a month.)

I think the point is that D targets the same set of scenarios as Go, but it's better at it for all the reasons that you've listed.

Re: D Language accepted for inclusion in GCC

#125
post #55
post #19

Earlier quoted context omitted.

They are very different languages. Rust was designed to be GC-free and memory safe. D, on the other hand, has GC and is memory unsafe by default.

D being @system by default has already been discussed as a design error, but making @safe be the default would be a breaking change. So it is up to the community if they want to accept such change. I should note that they still need some help cleaning the standard library and compiler corner cases in regard to @safe.

Could there be a compiler flag to flip the default to @safe,so it doesn't have to be added to each file?

Re: D Language accepted for inclusion in GCC

#126

I have read many posts saying D was better than C++ as a language but there were no libraries for use case X. Now this may help popularise the language.

D seems like a more useful Rust, or is that completely wrong?

I think D is more evolutionary than Rust. Rust tries to radically change the way programmers reason about their code. D is much more conventional in that regard, but accumulates all the power features from other languages on top of a "C++ fast" core and with a syntax that's familiar to someone coming from C++ (or Java and C#, for that matter).

Re: D Language accepted for inclusion in GCC

#127
post #65

Earlier quoted context omitted.

I think they meant lower case "open source" (as in the source is open (anyone can read/compile it)). There are plenty of software that are open source but not freely distributable, such as Unreal Engine.

The first time I said that on HN somewhere else I got quite a flak. I don't know when OSI's definition became mainstream. The first time I heard open source, it meant the same as what you said. Nowadays you have to use a different term for that. Collins still has the old definition "free to use or modify". Merriam-Webster and Oxford has since included "redistribution" in the definition. The term "shared source" is no…

"Shared source" seems to originate from Microsoft, from the time period before it embraced OSS proper. At least the first time I've seen it in any context was the "shared source CLI", which was released under the look-but-do-not-touch license as a reference implementation to back the ECMA CLI and C# standards.

https://en.wikipedia.org/wiki/Shared_Source_Common_Language_...

That said, it's a surprisingly good term, because it's so accurate - the source is shared with you, but there isn't much you can do with it other than look at it.

Re: D Language accepted for inclusion in GCC

#128
post #90
post #74

This is basically the work of one tireless man; Iain Buclaw. Many thanks to him for putting in so much time and energy into this. It took 6 years from first submission to get it in. Here are the slides from his 2017 DConf talk about the work that went into making this happen: http://dconf.org/2017/talks/buclaw.pdf

Slowly but steadily. Given the fact that D has not managed to die when it had so many chances to, I tell that D has better chance at mass adoption as "a better C++" than the current wave of Swift/Rust/Go that rely on "life support" from a corporate donor.

Most people I know have not heard of D, but have definitely heard of Go, Swift and (less often, but still frequently) Rust. If in 16 years D has not achieved mass adoption, what is different now, when there are more competitors that offer better features?

Re: D Language accepted for inclusion in GCC

#129
Is there a D IDE with good code completion and refactoring support? Last time I tried it, all that I've seen were pretty bad at it - handling the simple stuff fine, but breaking down on more complicated stuff, metaprogramming especially (kinda like most C++ IDEs did 8 years ago or so).

Re: D Language accepted for inclusion in GCC

#130
post #55

Earlier quoted context omitted.

D being @system by default has already been discussed as a design error, but making @safe be the default would be a breaking change. So it is up to the community if they want to accept such change. I should note that they still need some help cleaning the standard library and compiler corner cases in regard to @safe.

Could there be a compiler flag to flip the default to @safe,so it doesn't have to be added to each file?

It could eventually be an option I guess, but it would require anyway to recompile all code.

As always in such cases, to validate binary libraries, they need some kind of metadata to indicate they are safe libraries (aka they only use of @safe or @thrusted code).

.NET does this with MSIL metadata, Modula-3 does it directly on the module definition section, for example.

Post reply on HN