Hacker News Reader

Comment by wyatwerp | Hacker News Reader

Are you describing the D language? https://dlang.org C-like syntax and execution speed with high-level scripting-language-like conveniences, close to Lisp-level ability to generate code at compile time, an active user-base (https://forum.dlang.org) that continuously strives to get the language improved. Its (thread-local) memory heap is GC'd by default. They also have an LLVM back-end if that is pertinent. Recently, it even became another supported front-end in GCC, alongside Go, Ada, etc.

View on HN

D is a weird one, because it has been lurking around for at least a decade and a half without really picking up the kind of steam and hype that later entrants have. I remember dabbling with D for game development way back in high school, as a friendlier alternative to C++.

I think that part of the reason it didn't pick up is because it was made during an era when talking about the problems of C++ was brushed aside with "learn to program kiddo".

I suspect we are at least partially still in that era.

Well, Standard ML is a weird one too in that sense (lurking around for a couple of decades without picking up steam (outside academia?)). Languages having type inference and modules designed into them seems to have a good chance to live long.

D excluded itself from being C/C++ killer by having a GC. I know they've backtracked on that, and the -betterC subset of D looks interesting, but it's a bit late for that.

Only to the GC hating crowd.

Unreal and UWP/COM developers are perfectly fine with writing C++ code with a GC around.

If GC & runtime is on the table, then there are many nicer languages you can use (Go, D, Swift, Kotlin). I assume that the C and C++ users who haven't switched yet are largely the "GC-hating" crowd that can't.

COM and other refcounted ones get a pass. But I'm surprised that Unreal gets away with a mark-and-sweep GC. Perhaps because it's only required for UObjects, and the rest of the codebase can still easily avoid using the GC? You can even cause use-after-free bugs on UObjects, if you want to.

Isn't Swift also refcounted?

Reference counting is a GC algorithm, as per CS curriculum.

Try to broaden your horizons.. I work in telecoms only one step away from a FPGA, a 1ms pause would be a critical bug report..

My horizons are already broaden.

https://atlas.cern/discover/detector/trigger-daq

You can also try to broaden yours.

https://www.ptc.com/en/products/developer-tools/perc

Will this work for you? I guess most likely not, and you really cannot afford any kind of delay, where even a C++ virtual call would be considered a bug, given the 1ms delay.

The point being that only a very tiny population has such requirements, just like barely anyone writes applications 100% fully in Assembly.

I'll look at your links but to answer to your question: yes virtual functions are not accepted in the code.

Success is often a matter of time. A good idea too early is the wrong idea kind of thinking.

What do you mean by:

> Its (thread-local) memory heap is GC'd by default.

What happens to objects that are allocated in one thread, and then have their reference passed to another thread?

The typical approach here as far as I'm aware is to use a deallocation queue - frees of an object that was allocated on another thread are freed by putting that object in the original thread's deallocation queue. When that thread gets an opportunity, it frees everything in its deallocation queue to reclaim that memory.

Manually, or automatically?

Do you mean "thread local passed to another thread by mistake"? There is an option to make data global instead. Unless it is a Unix pipeline kind of design, independent threads can populate their working set (from file/socket/whatever) into thread-local memory.

It depends on whether shared-memory is a design requirement or an implementation artifact (Erlang does just fine with a largely shared-nothing model).

It also depends on whether a program runs for a short time, or for a long time. If you are running for a short time, why not just avoid the GC entirely; "manage" memory manually by malloc-ing and never free-ing (free-ing too takes time, and doesn't make memory available to other processes anyway).

In D the GC heap is shared across registered threads, so it supports values allocated in one thread and passed to another. This particular passage from one thread to the other is guarded by a "shared" type constructor, so as to have a type system guarantee.

Reply on news.ycombinator.com