5 ms·
Are you describing the D language? https://dlang.org https://dlang.org C-like syntax and execution speed with high-level scripting-language-like conveniences, c
by wyatwerp 7y ago
Are you describing the D language?
https://dlang.org 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 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.
- thrower123 7y agoD 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++.
- adamnemecek 7y agoI 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".
- catach 7y agoI suspect we are at least partially still in that era.
- wyatwerp 7y agoWell, 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.
- pornel 7y agoD 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.
- pjmlp 7y agoOnly to the GC hating crowd. Unreal and UWP/COM developers are perfectly fine with writing C++ code with a GC around.
- pornel 7y agoIf 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.
- renox 7y agoTry to broaden your horizons.. I work in telecoms only one step away from a FPGA, a 1ms pause would be a critical bug report..
- pjmlp 7y agoMy horizons are already broaden. https://atlas.cern/discover/detector/trigger-daq https://atlas.cern/discover/detector/trigger-daq You can also try to broaden yours. https://www.ptc.com/en/products/developer-tools/perc 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.
- agumonkey 7y agoSuccess is often a matter of time. A good idea too early is the wrong idea kind of thinking.
- amelius 7y agoWhat 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?
- bitwalker 7y agoThe 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.
- pcwalton 7y agoManually, or automatically?
- wyatwerp 7y agoDo 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).
- p0nce 7y agoIn 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.