91–100 of 235 posts
That's really great news and ensures long term viability of the D language and associated eco system.
Remember gcc once had a Java compiler...
Earlier quoted context omitted.
I don't view it's counterpart to be C++ these days; dlang is a GC'd language, so it's actually probably fairer to compare it to Go instead.
It is a clear alternative to C++. The GC is optional.
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 Rust contributors are not Mozilla employees. Losing people to work on Rust full-time would be a setback, but we're not really reliant on it; we'd evolve more slowly.
While I like D and use it for scientific work, wwo "omissions" leave me a bitter taste. Nothrow and Pure are not part of the type signature of functions and consequently the compiler has limited inference about these. However I will keep using it unless something better comes up. C++/C# are not an option for me since I found D.
Actually they are. Take a look at this example:
void main() {
int delegate(int) @safe nothrow @nogc pure f;
//This looks like something bad is happening, but the delegate literal
//actually has the proper attributes inferred so it Just Works
f = delegate(int) { return 0; };
int delegate(int) g;
f = g; //Fails, as it should
}Earlier quoted context omitted.
D seems like a more useful Rust, or is that completely wrong?
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.
GC + range checks provide memory safety to most programs without the kind of extra work you need in Rust. This is a big reason why they are so common in industry.
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.
Earlier quoted context omitted.
It is a clear alternative to C++. The GC is optional.
Is it? Last time I checked a few years ago there were huge caveats to allocation Objects on the stack (I forget what they were) so unless something's drastically changed this doesn't seem like an honest assessment.
The built-in `scope` syntax is deprecated (though making a comeback recently as more stuff gets implemented around it), but you can also do a library type fairly easily, just slightly heavier in syntax (you need to prepare the memory and construct the object in two separate lines) or prep work (write a struct which does both).
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.
"open source", no matter the capitalization, means what the OSI has defined. Unreal Engine is neither Open Source nor open source. It is simply proprietary. To say otherwise is a practice known as "open washing" that companies use to appear community friendly when in fact they are not.
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.
Perhaps that's the reason why both Rust and Go managed to gain so much traction and goodwill, because they actually offer entirely different takes on programming. D, on the other hand, tried to fix problems that existed only due to the lack of work developing C++ beyond the 98 standard. Once the C++11 standardization process took off, D was pushed away into irrelevance.
Earlier quoted context omitted.
D seems like a more useful Rust, or is that completely wrong?
Just more pragmatic, I'd say. D isn't a "big agenda language" (to steal a line from Jonathan Blow). It's extremely multi-paradigm (some might argue to a fault). I think that's why you find people saying D is like C++ or D is like C# or D is like Go or D is like Rust. You get a little taste of everything using D. Want function programming and purity? Check. Want C style/low abstraction code? Check. Want extreme C++ me…
That's a major problem, and not a feature.
One of C++'s main drawbacks is its size and arcane features, to the point that the language is known for being impossible to master. If all D brings to the table is an agenda to pick off C++'s complexity and drive it up even further then I fail to see what problems that will solve while it creates many others.