Earlier quoted context omitted.
How is D's memory safety without the GC? How does it guarantee you don't use-after-free, de-ref nulls, buffer overflow, etc?
Great question! The answer is a bit more than a simple reply can do, so: Pointers Gone Wild: Memory Safety and D http://dconf.org/2017/talks/bright.html
D Language accepted for inclusion in GCC
171–180 of 235 posts
Re: D Language accepted for inclusion in GCC
#172Earlier quoted context omitted.
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…
What's D's LINQ equivalent?
auto names = [ "Burke", "Connor", "Frank", "Everett", "Albert", "George", "Harris", "David"];
names.filter!(a => a.length == 5)
.array // convert from lazy range to array so we can sort
.sort!()
.map!(a => a.asUpperCase)
.joiner("\n")
.writeln;
Ranges enable lazy processing with efficient static dispatch against arbitrary types of ranges. Those individual algorithm functions are basically all template functions that return types tailored to match the input which allows the lazy evaluation to work. When writeln asks for the first element to print it asks joiner which asks map which asks asUpperCase and so on. The results are calculated upon request, not in advance, which helps you forgo a lot of memory allocations for storing temporary results.UFCS lets you call a function as if it were a member of the first parameter (i.e. fun(x, y) -> x.fun(y)). This lets you write it as if it were chain rather than a series of inside out function calls (i.e. `writeln(joiner(map!(a => asUpperCase(a)(sort!()(array(filter!(a => a.length == 5)(names)))), "\n"))`).
There is exactly two memory allocations in all of that. Once for the initial array and again prior to sorting because it's not reasonable to sort a lazy range. We could have reused the initial array by eagerly removing the items being filtered from it if we wanted.
Re: D Language accepted for inclusion in GCC
#173Is 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).
Code completion yes. (DCD provides this as a library). d-mode for emacs is nice, both of the plugins for vs-code I know work. There are plugins/extensions for (i think) xcode and (i know) Jetbrains's stuff (I don't use it so i can't really comment. Refactoring, no. Edit: There is also a D-specific IDE called coedit, which is pretty good AFAIK
Re: D Language accepted for inclusion in GCC
#174Earlier 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…
is that true? Old versions of Rust looked like Go, IMO.
Re: D Language accepted for inclusion in GCC
#175Earlier quoted context omitted.
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?
It's a big world out there. Would you ever imagine that D would be taking market share from... Extended Pascal? But there's a naval architect who designs great big ships with a 500k sloc codebase he is exploring porting to D. Web guys get the attention but enterprise users are a much bigger world than just that. If something is growing very quickly then saying it hasn't yet dethroned C, so it won't ever be significan…
From what I have seen of D, it provides a C++ without some of the cruft, but without trying to solve other issues with C++-like languages (for eg: usefulness of Algebraic Data Types). Why should someone choose D today over Go or Rust for any project? I have yet to see a convincing answer.
Re: D Language accepted for inclusion in GCC
#176Earlier quoted context omitted.
Code completion yes. (DCD provides this as a library). d-mode for emacs is nice, both of the plugins for vs-code I know work. There are plugins/extensions for (i think) xcode and (i know) Jetbrains's stuff (I don't use it so i can't really comment. Refactoring, no. Edit: There is also a D-specific IDE called coedit, which is pretty good AFAIK
Also a visual studio plugin
Re: D Language accepted for inclusion in GCC
#177Earlier quoted context omitted.
I don't think it's meaningful to put Swift, Rust and Go in a single bucket when comparing them. They're languages targeting different levels of abstraction, with very different approaches as a result. Some people refer to all of these as "better C++", but it's meant in very different and incomparable ways. For example, Rust is ostensibly a "better C++" in a sense that it retains the low-level, zero-overhead (no GC) e…
> D is arguably in the same bucket as Swift, and partly as Go. I don't think it's very useful to compare and contrast it against Rust. It is easy to claim how things "arguably" are, but without providing any justification that is not a very meaningful statement to make. D very much matches your definition of "low-level, zero-overhead (no GC) etc nature and powerful metaprogramming facilities" – the GC can be avoided…
If not, then I would posit that it's not correct to say that it matches my definition.
Re: D Language accepted for inclusion in GCC
#178Earlier quoted context omitted.
I will argue that Go is more of a better C than a better C++
Go is more a better Python. Even simpler syntax. Types and compiles to native (as they are all the fashion now). Rust is the best bet we have at a better C (and a better low-level C++). High level C++ competes with D and Go. Rust is a little too specifically targetted at the low level "systems" programming.
Re: D Language accepted for inclusion in GCC
#179Earlier quoted context omitted.
I don't think it's meaningful to put Swift, Rust and Go in a single bucket when comparing them. They're languages targeting different levels of abstraction, with very different approaches as a result. Some people refer to all of these as "better C++", but it's meant in very different and incomparable ways. For example, Rust is ostensibly a "better C++" in a sense that it retains the low-level, zero-overhead (no GC) e…
> Others are "something better than C++ for most apps you'd write in C++ today". As big C++ fan and language geek, I am pretty confident that if Java and .NET had taken the route of all other alternatives in the 90's (Oberon, Eiffel, Modula-3, Delphi,...), C and C++ would be less relevant today than they turned out to be. This because many people make use of them, just because they are the only languages they know ab…