Live data from Hacker News

D Language accepted for inclusion in GCC

gcc.gnu.org

201–210 of 235 posts

Re: D Language accepted for inclusion in GCC

#201
I am learning rust now, but D seems quite promising.

Rust guides you more toward certain approaches. That makes rust easier to learn, but it makes it harder to integrate with existing projects. On paper, rust could work great in a lot of environments, but I'm finding that it takes a bit more work to integrate with a real codebase. It can be done, and I feel like that's well supported, but it takes some real work to port the concepts of a C API into a good and safe rust API.

D might make that easier because it's an "everything" language, so there is likely a corresponding D equivalent of almost any existing API. Of course, you won't get the same level of safety or other benefits, but it could be a smoother path.

Re: D Language accepted for inclusion in GCC

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

Call me wrong if I misunderstood, but isn't reference counting also kind of GC?

Yes, but reference counting allows for deterministic destruction. This is a game changer to leverage the power of destructors.

Re: D Language accepted for inclusion in GCC

#203
post #170

Earlier quoted context omitted.

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.

Go has far more in common with Java than it does with python. Arcane APIs that are incredibly difficult to use correctly while having a very simple base language.

For my edification, could you give an example of such an API in Go?

Re: D Language accepted for inclusion in GCC

#204

Earlier quoted context omitted.

That's not how C++ templates work. You cannot deliver them as binaries. Templates are delivered as C++ include files (i.e. source code). When you use them, the compiler fills in the types you want and compiles the result. For example, there's the std::vector template. You can fill in any type that meets the specific requirements of the template and use it like std::vector or std::vector . However, you probably won't…

As mentioned before, C++ compatibility is not 100% yet. My comments are purely what works now; which by describing to D what is in a c/c++ .o file so you can link it in. In your .d file that describes the C/C++ you want to use, sometimes you will have to describe the template to D by creating D template of the C++ template. Also if your "library" is all templates, it's not a library, it's a framework that uses other…

> if your "library" is all templates, it's not a library

TIL STL is not a library.

Re: D Language accepted for inclusion in GCC

#205

Earlier quoted context omitted.

> D has not managed to die when it had so many chances to One interesting thing about D is that we don't have to answer to anybody, so nobody can kill D other than us. We just keep steadily pushing forward regardless.

Thanks for the hard work Walter. Random question: I heard D has something like C#'s LINQ. Is that true?

Sebastian Wilzbach compiled this comparison of LINQ and D range primitives:

https://github.com/wilzbach/linq

Re: D Language accepted for inclusion in GCC

#206
post #151
post #80

Earlier 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?

Sebastian Wilzbach compiled this comparison of LINQ and D range primitives:

https://github.com/wilzbach/linq

Re: D Language accepted for inclusion in GCC

#207
post #155

Human societies seem to evolve to fewer languages. Fewer languages help everyone communicate easier/better. Programming languages seem to go the opposite direction. Any speculation on why?

Humans started out with only one very limited language, then spread out to cover the world, and new languages flourished. As technology progressed and the world became smaller, having fewer languages (or at least, a few common languages) made more sense. With the advent of the internet, the world has become so small a single language might be the best option.

Programming started out with one very limited language (machine code), the spread out to cover the world, and new languages flourished. As technology progresses and the world becomes smaller, having fewer languages (or at least, a few common languages) will make more sense. With the advent of the singularity, the world will have become so small a single language might be the best option.=

Re: D Language accepted for inclusion in GCC

#208
post #44

Earlier quoted context omitted.

> D understands how C++ function names are "mangled" and the correct C++ function call/return sequence. How does it work in practice ? C++ name mangling is not standardized and so every compiler can implement its own scheme. So does it mean there is a list of D compatible c++ compiler somewhere ? I have the feeling that if you are using some exotic proprietary c++ compiler it won't work well.

> C++ name mangling is not standardized and so every compiler can implement its own scheme. That's right, and the D compiler deals with that by customizing the C++ mangling for every platform.

I am just curious what the actual list is, it is surely not possible to support every version of every compiler on every platform.

Re: D Language accepted for inclusion in GCC

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

Corporate donors are also very important.

It is usually only way some programmers are forced to adopt new programming languages, in spite they religious beliefs regarding how programming should be.

Notorious example, game developers moving from Assembly to C/Pascal and later from C to C++.

Or systems programmers being force to move into C++ instead staying with C (e.g. IO KIt and UMDF).

Re: D Language accepted for inclusion in GCC

#210

Earlier quoted context omitted.

And more of a spiritual successor than an actual one. You probably won't be writing kernels with it.

No as Go has a GC. It's just supposed to be a fast server-side language without very complicated code. Go is mostly successful due to Google and filling a niche (fast, simple, concurrent, all thrown into a fat statically linked binary I think).

> No as Go has a GC.

So what, so do Oberon, Modula-3 and many others including D.

Yet quite a few production OSes were even written with them, e.g. Native Oberon for the Ceres Workstation at ETHZ.

Post reply on HN