Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

D Programming Language

dlang.org

Post reply on HN
Print view View original

231–240 of 278 posts

Re: D Programming Language

#231

Post by pjmlp »

tmtvl wrote: post #136
nurettin wrote: post #92

Earlier quoted context omitted.

> block scoped opt-out with cowboy-style manual memory management Is this a Walter Bright alt? I've seen him use the cowboy programmer term a few times on the forum before.

The term 'Cowboy coder' has been around for some time. Everybody's favourite unreliable source of knowledge has issues dating back to 2011: https://en.wikipedia.org/wiki/Cowboy_coding >

This was already a thing in Usenet days, an example from 1998

https://groups.google.com/g/comp.lang.lisp/c/tfzX3Sq96Xk/m/0...

Re: D Programming Language

#232

Post by p0nce »

arcadia_leak wrote: post #123
999900000999 wrote: post #116

Earlier quoted context omitted.

What problem is D solving ?

One good case for it that I see is a viable basis for cross-platform desktop apps. Today, cross-platform desktop GUI apps are either just a snapshot of the website contained inside Electron, or a C/C++ code base with manual memory management. D can serve as a nice middle ground in that space.

Exactly what some of us are doing with D.

Re: D Programming Language

#234

Post by tgv »

fooker wrote: post #183
tgv wrote: post #119

Earlier quoted context omitted.

How does Rust (or C++) treat array indices as resources? And won't that defy the reason to use indices over pointers?

Here's how it works in some C++ libraries. struct resource { resource(ctx *c, ...) {index = c->store(...); ...;} size_t index; ctx *c; ~resource() {c->free(index);} // copy constructor+op creates new handle // move constructor+op copies the handle, maybe zeroes the current one }; With this you can rely on RAII, smart pointers, upcoming lifetime checks and annotations, etc. The core idea is that you treat objects of c…

But if I'm not mistaken, this is just handling index allocation, release and avoiding dangling manually. The programmer is still responsible, right? And I don't think Rust can do better for indices, since indices are normal, "eternal" values.

Re: D Programming Language

#235

Post by rafaelmn »

pjmlp wrote: post #230
rafaelmn wrote: post #193

Earlier quoted context omitted.

Ironically those optimizations came from .NET avoiding GC and introducing primitives to avoid it better. And .NET is moving heavily into the AoT/pre-compilation direction for optimization reasons as well (source generators, AoT). If you look at the change logs for the past few versions of the framework from perf perspective the most significant moves are : introduce new primitives to avoid allocating, move more logic…

So what, that is exactly the point. A programming language having a GC doesn't mean every single allocation needs to be on the heap. C# is finally at the sweet spot languages like Oberon, Modula-3 and Eiffel were on the late 90's, and unfortunely were overshadowed by Java's adoption. Go and Swift (RC is a GC algorithm) are there as well. D could be there as well on the mainstream, if there was a bit more steering int…

The point is that if you need performance you need to drop below tracing GC, and depending on your use-case, if that's the majority of your code it makes sense to use a language that's built for that kind of programming (zero cost abstractions). Writing C# that doesn't allocate is like wearing a straightjacket and the language doesn't help you much with manual memory management. Linters kind of make it more manageable but it's still a PITA. It's better than Java for sure in that regard, and it's excellent that you have the option for hot paths.

Re: D Programming Language

#236

Post by avadodin »

abcd_f wrote: post #118
jibal wrote: post #104

Earlier quoted context omitted.

Walter's a regular on HN. > This very post is probably his too, under an alt :) The probability of that is virtually zero. Walter is a principled person, has better things to do, and his writing style is vastly different from the OP's.

This very post is probably his too, under an alt :)

I was hoping to see one of his posts here. If he's going to post under an alt, he should advertise it so that I can know which posts I should be taking extra ironically.

Re: D Programming Language

#237

Post by pjmlp »

rafaelmn wrote: post #235
pjmlp wrote: post #230

Earlier quoted context omitted.

So what, that is exactly the point. A programming language having a GC doesn't mean every single allocation needs to be on the heap. C# is finally at the sweet spot languages like Oberon, Modula-3 and Eiffel were on the late 90's, and unfortunely were overshadowed by Java's adoption. Go and Swift (RC is a GC algorithm) are there as well. D could be there as well on the mainstream, if there was a bit more steering int…

The point is that if you need performance you need to drop below tracing GC, and depending on your use-case, if that's the majority of your code it makes sense to use a language that's built for that kind of programming (zero cost abstractions). Writing C# that doesn't allocate is like wearing a straightjacket and the language doesn't help you much with manual memory management. Linters kind of make it more manageabl…

I rather have the productivity of a GC (regardless of which kind), manual allocations on system/unsafe code blocks, and value types, than going back to bare bones C style programming, unless there are constraints in place that leave no other option.

Note that even Rust's success, has triggered managed languages designers to research how far they can integrate linear, affine, effects, dependent types into their existing type systems, as how to combine the best of both worlds.

To the point that even Rust circles now there are those speaking about an higher level Rust that is supposed be more approachable.

Re: D Programming Language

#238

Post by thezipcreator »

pjmlp wrote: post #227
ibgeek wrote: post #213

Earlier quoted context omitted.

I used to think of D as the same category as C# and Java, but I realized that it has two important differences. (I am much more experienced with Java/JVM than C#/.Net, so this may not all apply.) 1. Very load overhead calling of native libraries. Wrapping native libraries from Java using JNI requires quite a bit of complex code, configuring the build system, and the overhead of the calls. So, most projects only use l…

1. Java nowadays has Panama 2. Java and C# can also generate native binaries, just like Go, no need for VM. 3. C++ nowadays has concepts, modules and compile time execution This wasn't true in 2010, but D has let them catch up with missing features.

what are you referring to regarding Java? I'm aware C# has AOT (and il2cpp for Unity projects) but I don't recall hearing about any sort of Java native binary that isn't just shipping a VM and java bytecode (ignoring the short-lived GNU java compiler).

Re: D Programming Language

#239

Post by thezipcreator »

Cloudef wrote: post #212
arcadia_leak wrote: post #132

Earlier quoted context omitted.

> D/C#/Java are valid options I'm never picking D This is perfectly fair. > D was in the perfect spot to fill if it did not make the GC decision I just find it hard to believe that the GC is the one big wart that pushed everyone away from the language. To me, the GC combined with the full power of a systems language are the killer features that made me stick to D. The language is not perfect and has bad parts too, bu…

Its not the GC, its that D has no direction. Its kitchen sink of features and the optionality just fragments the ecosystem (betterC, gc) etc, making reusing code hard.

this is the main issue I think with D, yeah.

regarding kitchen-sink-ness it's at least nowhere near as bad as C++, but that bar is basically below the ground anyway so it's not much to write home about.

Re: D Programming Language

#240

Post by thezipcreator »

pjmlp wrote: post #228
debugnik wrote: post #205

Earlier quoted context omitted.

C# wouldn't be a problem for Unity if they hadn't mapped most engine abstractions to class hierarchies with reflection-based dispatch instead of value-type handles and the seldom interface, and had dropped the Boehm GC. .NET has actually got a lot of features to avoid allocations on the hot paths.

The problem is called Mono, and Unity's refusal to pay for an update.

instead they made (or funded? not exactly sure) il2cpp which is a batshit compiler that compiles IL to C++ for better performance, I guess.

sidenote, I wonder how many other low-level to high-level compilers exist out there. can't be many.

Post reply on HN