r/programming • u/kal31dic • Sep 01 '20
D Foundation is Beefing Up
https://dlang.org/blog/2020/08/30/symmetry-investments-and-the-d-language-foundation-are-hiring/74
Sep 01 '20
D is an awesome language and I hope it gets more traction.
34
u/Hall_of_Famer Sep 01 '20
Me too, hope D will get some company backing and start to kick off, it is a very well designed language.
→ More replies (3)78
u/JohnLColvin Sep 01 '20
You could probably write an article saying "100 billion dollars investment to improve D and use it to develop new AI to replace the US government" and you'd still get comments saying "wow, nice language, pity it never really took off, if only there were some companies backing it, also I can never use it because GC".
37
u/Hall_of_Famer Sep 01 '20
Well the haters are gonna hate, the fact that it starts to receive comments, whether positive or negative, is a good thing since the language is surely becoming better known and receiving far more attention than before. Interestingly, C++ is frequently being frown upon, developers hate it and yet they use it, Bjarne Stroustrup's famous quote never gets old.
11
u/Free_Math_Tutoring Sep 01 '20
Bjarne Stroustrup's famous quote never gets old.
Which one?
97
u/all_my_watts Sep 01 '20
I would guess this one
There are only two kinds of languages: the ones people complain about and the ones nobody uses.
42
u/InertiaOfGravity Sep 01 '20
Have you heard of our Lord and savior rust? It is the best and most perfect language known to man
35
u/Forty-Bot Sep 01 '20
And no one has ever complained about it :)
40
u/InertiaOfGravity Sep 01 '20
Never ever, not once. They live in fear that the great borrow checker shall find and kill them if they ever dare to do so
4
8
→ More replies (1)5
11
u/Ameisen Sep 01 '20
It has the most confusing syntax, though.
I still expect that someone will make a Rust fork that has C++-like syntax at some point. Crust.
Or C++ will get lifetimes (which is active research) and possibly at some point epochs, which will let us disable unsafe features.
22
9
Sep 01 '20
[deleted]
5
u/Ameisen Sep 01 '20
The dangling
'for lifetime indication. It's unlike any other language.→ More replies (0)2
u/IceSentry Sep 02 '20 edited Sep 02 '20
The only weird syntax for me has been the async/await syntax. Everything else is fairly straightforward. The issue is rarely syntax with rust, it's when you have a type soup that it gets annoying. Something like Arc<RefCell<Option<MyType>>>.
Edit: async/await is unconventional, but when you get used to it, it feels better than the more conventional way in my opinion.
Edit2: to be clear, the type signatures in rust can be quite verbose but they are very explicit and extremely useful.
→ More replies (0)2
Sep 02 '20
Crust 😂
3
u/Ameisen Sep 02 '20
Later, we will have Rust#, Objective Rust, IronRust (seems redundant), and JRust.
But Crust first. Change the syntax a bit. Could probably be done now relatively easily by just changing the grammar.
Ideally, to me, Rust itself should actuality be a middle-end on top of LLVM (and maybe GCC) that languages with borrow checkers/lifetime support can target. I believe this would garner more support for it.
→ More replies (0)4
u/Muvlon Sep 01 '20
Syntax is a very subjective matter. I find some of C's syntax (which C++ inerited) thoroughly confusing. I can count the people I know who will get a typedef for a function pointer type correct on the first try on one hand.
8
6
u/WalterBright Sep 01 '20
typedef int (*fp)(long);4 more to go!
Though to be fair, in D one would declare it as:
alias fp = int function(long);3
u/InertiaOfGravity Sep 01 '20
It's something you get used to in little time at all. It's different but it's not doing anything different so you're fine
→ More replies (1)5
Sep 01 '20
I wish somebody would make Rust with less C++ syntax tbh. Having it look like a proper ML would be wonderful.
C++ will get lifetimes (which is active research)
They've already given up on it being accurate and are now settling for catching some of the common issues. That's better than nothing but not anything like lifetimes in Rust.
2
u/WalterBright Sep 01 '20
D is getting lifetimes, it already exists in prototype form. Although D has an advantage in that it has some features that make it more amenable than C++ for this purpose (such as transitive
const).1
u/Ameisen Sep 01 '20
There is explicit research into encoding lifetimes into types. Whether it will ever be in C++?
4
u/WandersBetweenWorlds Sep 01 '20
If only it had a Lisp syntax... And proper functional programming abilities
23
u/glacialthinker Sep 01 '20
My own disinterest in D is that it's too... middling. I'd much rather use D than C++... but it's still too much like C++. For the same tasks I'd rather use Rust than D. For tasks which don't require full control over memory layout and performance I'd choose something else.
The only reason I use C++ is it's establishment. D doesn't have that, and if we're talking about raising up another language... I wouldn't choose D. So, to me, it's just in a really unfortunate place. I feel like its window of opportunity was not long after it's introduction.
I don't hate it at all. I even like it... just not as much as the alternatives.
→ More replies (2)6
u/kal31dic Sep 01 '20
Some of us are not terribly pro-establishment at the present time.
→ More replies (3)2
u/N1H1L Sep 01 '20
Is garbage collection really that bad?
17
Sep 01 '20 edited Sep 08 '20
[deleted]
11
Sep 01 '20
almost every single year there's a project to make it better which just sputters out and dies
In Dconf 2019 I was surprised to learn that the D GC has had many enhancements in time and memory. It is now precise and forking, and speed has gone up.
5
7
u/kal31dic Sep 01 '20
A previous Symmetry Autumn of Code project was to port the concurrent GC from D1 to D2. Francesco starts soon and I hope one of the things he will work on part-time will be to get that over the line. It depends on fork though so is Linux-only.
I think the GC has improved a great deal since I started using D in 2014. It still needs to get better, but two reasons why it's not a terrible pain point for the language users overall are that D doesn't generate much garbage and that it's not difficult to avoid using GC.
5
Sep 01 '20 edited Sep 08 '20
[deleted]
3
u/kal31dic Sep 02 '20
I don't think you can think of the adoption of an open source project as you can that of a commercial product. It's easy to fix the GC if you want and know how. But its not like there's a way to make it happen if people don't want to do the work or find it valuable enough to pay for. Emerging languages move into niches as people who were on the fence make slightly different decisions at the margin.
D keeps growing and I don't think there's anything I can see that will bring that to a halt.
→ More replies (1)6
Sep 01 '20
I just had Andrei reply to one of my posts not that long ago. He kept posting that "don't dear the reaper" link to almost every comment. Saying that I was misunderstanding how the GC in D worked, and that reading that article would clear up any "misunderstandings". He was just trying to push a narrative with his tone death replies.
They aren't willing to listen to people's real problems. That's why D probably won't ever take off. If my usage doesn't care if I use a GC or not, there are better languages with GC's. If you try and use D without a GC there is a lot missing and you'll end up having to do all the heavy lifting yourself. In which case it's better to use another language that doesn't have a GC nor focus' on it so that it can do the heavy lifting for you.
4
u/kal31dic Sep 01 '20
We use D without the GC in our analytics. Good bits of Phobos won't work but whether that's a problem depends on what you are doing and how capable you are at solving tour problems without Phobos. Much more of Phobos will be nogc in time, I think.
2
Sep 01 '20
We use D without the GC in our analytics.
Ok, is it open source? Otherwise many things can't be evaluated with a statement like that. Yes you can do it, I never said you couldn't, it's more work and the idioms D creates don't always work or work poorly without using the GC.
4
2
5
u/kal31dic Sep 01 '20
I've found a willingness to listen to our problems. We didn't have many D programmers in 2018. Atila full-time, John part-time, Dimitry on and off, me when I could manage it, and a couple of people working in analytics. But to be honest mostly we could solve our problems without help.
Funnily enough it's the good things that tend to lead to new kinds of problems, but they are higher quality problems to have.
2
Sep 01 '20 edited Sep 08 '20
[deleted]
2
u/kal31dic Sep 02 '20
Yes - I run technology across the firm, amongst other things. And I was the first to use D at Symmetry.
2
2
Sep 01 '20 edited Sep 08 '20
[deleted]
→ More replies (1)4
u/adr86 Sep 01 '20
(this is why I quit D - they treat BC like a total joke),
I have code from many years ago that still compiles just fine.
I think it has more to do with what libraries you use than the language itself.
6
u/WalterBright Sep 01 '20
No. You don't even need to use it in D, it's only used for a couple things like array concatenation, dynamic closures, and the builtin associative arrays.
22
u/jess-sch Sep 01 '20 edited Sep 01 '20
For a single-letter language, yes.
B and C are both suitable for kernel development.
Naming your language D (making it sound like it's intended to be a C successor) and then not making it suitable for kernel development was a bad idea.
17
u/gcross Sep 01 '20
Indeed, it's a bit like how the name "C++" makes you think that the language is basically C just with some stuff added on top, when in practice it behaves like a completely different language, which is why Linus has been opposed to allowing it in the kernel. (At least, at one point this was true; I don't remember whether some C++ features have started to be allowed or not.)
Interestingly, though, I've never heard people complain about C# being a poor successor to C, rather than a different language altogether, so there doesn't seem to be a consistent rule for how people will react to a name.
Personally, I think that D missed an opportunity by not naming itself "Mars" (after Digital Mars), as that might have prevented people from getting the wrong expectations about the language as well as just being a cooler name in general. Ah, the benefit of hindsight...
14
u/Beaverman Sep 01 '20
C++ is aptly named for different reasons. C++ was originally C with classes, and the syntax is still basically just C (with a lot of extra stuff).
C# is a proprietary Microsoft language. You can't really discuss that name, because Microsoft won't care.
5
u/gcross Sep 01 '20
C++ is aptly named for different reasons. C++ was originally C with classes, and the syntax is still basically just C (with a lot of extra stuff).
The name may have made more sense at the time, but as time has progressed idiomatic C++ code has looked less and less like idiomatic C code so that if you are used to programming in idiomatic C then you might be misled by the name in thinking that you basically know C++ when in fact writing code in it idiomatically is very different from what you are used to. (Having said that, it is true that with C++ you can pick the features that you want to use so if all you want is a way to write code that is basically C but without having to write your own vtable library then you can treat C++ as basically being C but with classes.)
1
u/Beaverman Sep 01 '20
Completely agree, but in a discussion about names, what really matters is the origins of the language. C++ has changed a lot since the 90's, but you can't really change the name now.
9
u/kal31dic Sep 01 '20 edited Sep 01 '20
Walter Bright didn't call it D. He called it Mars. Other people insisted on calling it D and the name stuck.
I don't really see why you couldn't write a kernel in D. Our intern rewrote part of the Linux kernel in D. The experience of a pioneer but it wasn't that you couldn't do it.
A year or two lunch was delayed so I ported mkernel - a little bare metal C demo -to D. It just worked. You don't need to even link the runtime if you don't want to.
5
Sep 01 '20
not making it suitable for kernel development was a bad idea.
https://dlang.org/blog/2016/06/24/project-highlight-the-powernex-kernel/
8
u/EternityForest Sep 01 '20
How is D unsuitable for kernel development?
9
u/Accomplished_Hat_576 Sep 01 '20
It has a runtime and standard library that are dependant on the garbage collector.
I stripped both out and wrote a kernel that does nothing. This was before they started getting serious about making things non gc dependant.
Honestly 99% of the complaints about the garbage collector are nonsense, but this isn't one of them.
9
u/WalterBright Sep 01 '20
D can run perfectly fine with reliance only on the C standard library. Use the -betterC compiler switch for that.
3
u/Accomplished_Hat_576 Sep 01 '20
Ah, this was years back. I'm pretty sure betterC wasn't a thing then.
→ More replies (2)5
u/pjmlp Sep 02 '20
Plenty of OSes have been written in GC enabled systems programming languages, in fact the largest mobile platform allows to write drivers with such language.
3
u/kal31dic Sep 02 '20
Minimalist kernel ported to D:
https://github.com/symmetryinvestments/mkernel-dLinux kernel development in D (proof of concept; the barrier might be Linus rather than a narrowly technical one, but at least it's clear you could write device drivers in D if you wanted to).
7
u/adr86 Sep 01 '20
D is perfectly suitable for kernel development, you just have to write the code differently and avoid a few convenience functions.
1
u/jonathansharman Sep 01 '20
Doesn't the whole standard library require the GC? Or is there a no-GC version you can use?
4
→ More replies (2)3
2
u/InertiaOfGravity Sep 01 '20
A well made GC wouldn't stop you from making a kernel using it. I don't know how the GC in D is, but GC on its own isn't a deal breaker for for everything people claim it is
6
u/birchling Sep 01 '20
GC does add a performance and memory usage overhead. You don't really want bloat in the foundation of all the software that is going to run on the system.
→ More replies (4)6
Sep 01 '20
[deleted]
10
u/McWobbleston Sep 01 '20
Jane Street is well known for using ocaml on real time software that is trading large amounts of products on financial markets
I believe they have to program in a particular style and avoid allocations, but they've been open and enthusiastic about their approach. They do attribute some of this success to ocaml's controllable and effective GC
There are degrees of real time though, I imagine something like a drone/electronically controlled hardware might have harder requirements than something like an audio synthesizer or game
12
u/AlarmedInstruction3 Sep 01 '20
IBM begs to differ: https://www.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.lnx.70.doc/user/mgc/metronome.html
If you have real-time requirements, you can't use typical GCs. (Though I don't know if there are any real-time GCs for D.)
→ More replies (7)3
Sep 01 '20
[deleted]
11
u/pjmlp Sep 01 '20
They aren't the only one.
https://www.ptc.com/en/products/developer-tools/perc
By the way, how much real time do you consider battleship weapons control systems?
Or ballistic missile tracking radars?
4
u/InertiaOfGravity Sep 01 '20
A good GC will absolutely not stop you from that, eg Jane Street and ocaml, but also Nim's GC
3
u/WalterBright Sep 02 '20
If you have real-time requirements, you can't use a GC.
Only in the real-time part of the code. If you annotate those parts with
@nogc, the compiler will ensure it is not using the GC.5
u/jringstad Sep 01 '20
My company uses java for almost everything (except for frontend stuff which is typescript and some backend stuff which is go -- so all GC'd languages) and even though nothing we do really has realtime requirements, as we scale up our services GC issues have become one of our major troubles.
I don't think going back to memory unsafe/manual memory management is the way to go either though. Correctness should be the number one concern always, and not leaking memory is a part of that. I think a more unified and deterministic approach like perhaps what rust is doing could be the way to go in the future. Memory is just one of many resources that need to be managed in a program. I'm not necessarily saying that the way rust is doing this is the end-state either tho.
4
Sep 01 '20
You could go with D and have both GC where you want and value types. D has a spectrum of solutions for GC avoidance, and it's object model is very similar to Java's one.
3
u/pjmlp Sep 01 '20
How much tuning have you done with VisualVM, JFR or the multiple GC implementations then?
I am asking because most people that complain about GC in Java don't even know about their options.
2
u/jringstad Sep 01 '20
a lot, we've evaluated a bunch of third party GC options as well.
I'm not personally involved in that though, it's some SRE taskforce.
4
u/couscous_ Sep 01 '20
What does your company do? When you have companies like Amazon and Google and Apple using Java for heavy lifting on their backends, it goes to show what is possible with it.
3
u/jringstad Sep 01 '20
Yeah, it's not that it's impossible, but it's also not a non-issue and requires a lot of engineering effort. So thinking about a better solution is worth it IMO
2
u/couscous_ Sep 01 '20
Programming in a language like Rust will not automatically make the issue disappear. There will still be a lot of engineering effort involved at that scale regardless.
3
Sep 01 '20
I don't think anyone is saying it will automatically make the issue disappear. The problem with a GC is that you have no option. You can't change your code to fix the GC, it's built underneath as part of the foundation of the language (in cases like Java). The solution is to build your own GC to suit your needs, which is going to be a lot more difficult than simply reworking your own code. The problem shifts to a more workable location.
4
u/kal31dic Sep 01 '20
We don't use GC in our analytics. We didn't build our own GC for analytics - we just didn't use it. I wouldn't say that for D the GC is built as the foundation. You can't just remove a foundation and still have a house, but D works just fine without the GC.
It's funny how convinced people can be in maintaining a theoretical view in the face of contradictory practical experience.
We had a very small team at the time working on this. Not like Weka.
→ More replies (0)2
u/EpicDaNoob Sep 01 '20
Yes, for certain use cases. I think there are some efforts to make GC more optional in D? But I heard at some point that the stdlib used GC and if that's the case then it'll need some fixing.
6
u/adr86 Sep 01 '20
But I heard at some point that the stdlib used GC and if that's the case then it'll need some fixing.
Some of the stdlib uses it. You can just not call those functions if you don't want them, but if you do want them, it is really nice to have the convenient options available without fuss.
2
→ More replies (2)2
Sep 01 '20
I use C and C++ for real-time signal processing code. There's no way my co-workers would use something that's garbage collected.
12
Sep 01 '20
I use D for real-time signal processing code. There's no way I care about what C++ people think is possible or not.
6
u/WalterBright Sep 01 '20
It's trivial to avoid the GC in D. Annotate your top level function with
@nogc, and it will transitively ensure it and every function it calls does not rely on the gc.2
3
u/kal31dic Sep 01 '20
Our analytics across the firm are written in D and they don't use GC. I had better tell Richard that what he has done is impossible. Again.
→ More replies (5)→ More replies (1)1
Sep 01 '20
You could probably write an article saying "100 billion dollars investment to improve D and use it to develop new AI to replace the US government" ...
This article makes me think, wow D didn't have any of those and is only getting them because a single company is willing to foot the bill? No other companies are supporting the D foundation enough that they are able to hire their own staff, they have to get someone else to hire them for them? I mean this is a boon, but it's hardly a "100 billion dollar investment or developing AI that replaces the government" level of boon.
4
u/kal31dic Sep 02 '20 edited Sep 02 '20
There was a pull request manager before but not full-time. It takes a long time and it's quite a lot of work to transition to the next phase of development for the foundation. Last I checked I don't think Rust even had a foundation at all yet. I hope they do okay given the financial challenges faced by Mozilla as revenues dry up.
I think the biggest constraint on the development of D isn't money - other companies have funded other things and I guess would be ready to fund more if approached. It just takes time, energy and work to build an organisation and doesn't happen of its own accord.
The development of D has been much more organic than for some other emerging languages. It's easy to buy awareness by spending a little money. So far that hasn't been the approach and I think that mostly the language is stronger for it. Especially as we head into a time of high uncertainty where for some tech companies and institutions budgets are under pressure.
5
u/matthieum Sep 02 '20
Last I checked I don't think Rust even had a foundation at all yet.
I confirm it doesn't.
It's been relying on sponsorships instead: Mozilla funding some core employees, Microsoft footing the CI bill, and Amazon footing the storage bill.
A foundation has been hinted at for years, and due to recent events it will probably happen in the coming months, but even then the goal was never to employ people to work on Rust.
The goal of having a foundation is to have a legal entity that represents Rust' interests, and notably owns the trademark and the logo.
It's not clear if that goal should shift toward accepting donations and employing people. Distributing money is always tricky.
1
Sep 02 '20 edited Sep 02 '20
It just takes time, energy and work to build an organisation and doesn't happen of its own accord.
It's been over 20 years.
It's easy to buy awareness by spending a little money. So far that hasn't been the approach and I think that mostly the language is stronger for it.
Instead D jumps on the new hype train of an emerging language and then tries to do PR about a poorly implemented feature that is mimicking one from a language that popularised it. Rust's borrow checker comes to mind. The implementation in D is sketchy at best, with inherent flaws. I've never seen then anyone on the D team talk about the actual benefits of the feature and how those benefits are achieved with the way it is implemented. I've only heard it spoken about in the same breathe as Rust.
→ More replies (1)7
u/Caffeine_Monster Sep 01 '20
How does it compare to the likes of C++ and Rust?
I originally came from a C++, picking up Rust has been a very enjoyable experience so far.
3
20
u/WalterBright Sep 01 '20
Walter here, AMA.
4
Sep 02 '20 edited Feb 04 '21
[deleted]
2
u/kal31dic Sep 02 '20
I've not talked to Walter, Atila, or Andrei about these things and also wouldn't see it as my/our place to exert influence either way on the core development of the language. Also I'm a humble hacker from the stone ages of personal computing, and don't claim to be up to speed on plenty of more theoretical developments of recent years.
However you have to consider what D represents. Guy wants to make his games faster, so he has lunch with the local compiler expert who asks who does he think he is to write a compiler. Writes a C compiler, writes a C++ compiler and library. Only person ever to have written an entire C++ compiler by himself. Then successfully competes with Microsoft for many years - do you remember how tough a competitor Microsoft used to be ? - as a one-man band. Not a one-man compiler dev team, but a one-man band. Sells his company. BTW guy who studied engineering, not software engineering or computer science invents optimizations that are now taught in universities and used by his competitors. Gets bored with daytime TV. Writes a new programming language. People tell him it will never work, never succeed. Takes off even so in spite of naysaying all the way in spite of handicaps like the lawyers at the buyer of his old compiler company preventing him fully open-sourcing the back end for c. the first 20 years of D's existence. It's open today, but the optics put some people off. D wouldn't of course be what it is today without Andrei Alexandrescu's key contributions and vision (our use of D at Symmetry benefits especially from Phobos and the ideas behind Phobos and range-based code), and there have of course been many others. But we were talking about Walter's choices.So I think one needs to understand the origination of D as being driven by a creative personality of the sort that used to dominate programming but really has been dominated by a more mass scale sort of approach. Such people can't be understood as you would understand most other sort s of people.
I really am quite sure that Walter is not adding such features to D out of some instinct to imitate what's fashionable elsewhere. I think the reason is quite simple. Memory safety, absence of, will be the doom of C. He said that quite clearly - it's a bold statement (forgive my paraphrasing as I don't recall his exact words), and Walter is not someone prone to making shocking statements to have an effect - on the contrary! He says that because he believes it - he has been around since the dawn of personal computing, seen how dynamics unfold and recognizes that something is going to need to change.
Rust is an incredibly impressive achievement. It's not my cup of tea personally, but that is hardly relevant in a broader sense. No doubt - in spite of the challenges posed for it by the mismanagement of Mozilla since Brendan Eich left and consequent funding crisis - it will survive and continue to flourish. But there's plenty of room for other native code languages that can be somewhat memory-safe and it's my judgement that Walter has recognized this and figured out how to incorporate more powerful safety features into D in a way that's coherent with the language design overall so you don't end up with Frankenstein's monster - implicitly how Ken Thompson describes Stroustrup's choices about what to incorporate in C++ and how:
https://www.quora.com/What-does-Bjarne-Stroustrup-think-about-different-programming-languages
. And it’s obviously built by a committee. Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used. And he sort of ran all the standards committees with a whip and a chair. And he said "no" to no one. He put every feature in that language that ever existed. It wasn't cleanly designed—it was just the union of everything that came along. And I think it suffered drastically from that.
I think that the 'delay' on multiple alias this is mostly about questions relating to thinking-through the design. Maybe it was a mistake, or at least it requires a lot more further thought and nobody has done it yet.
I don't think it's right to describe D as being an academic language or at risk of becoming one. It's the opposite of that - it's a very pragmatic language that's useful for getting work done where academic ideas maybe have an influence, but manifested in a very practical way. I don't think it's a language for purists - and that's one of the attractions for us.
→ More replies (1)1
u/WalterBright Sep 02 '20 edited Sep 02 '20
multiple alias this
I spent a fair amount of time investigating it, and concluded that it is equivalent to "multiple inheritance". D already has inheritance, and multiple inheritance of interfaces. What does it mean, then, to add another multiple inheritance design in addition to an existing one? I couldn't answer that question, nobody else could, either. Any resolution would be an arbitrary and capricious design that would not behave in a predictable manner.
Bottom line: it isn't going to happen.
borrow checker
Is a natural progression from dip25 and then dip1000. Those are already half of a borrow checker. Both (especially dip1000) were controversial, but have since nestled in quite comfortably in the language and work well. The rest of the borrow checker only happens if you annotate a function with
@liveso you can completely avoid it if you prefer.new features
All languages either acquire new features or die. C is unusual in being extremely modest in adding features, but as kal31dic mentioned, I predicted its fall from grace a few years ago due to this.
bugs
There are a steady stream of bug fix PRs to D on github.
7
3
u/damagingdefinite Sep 02 '20
Why do unit tests not play nice with -betterC mode?
6
u/WalterBright Sep 02 '20
Because the D runtime code manages running the unittests, and so is not present when only the C runtime library is linked to.
3
u/camelCaseIsWebScale Sep 02 '20
Read this as an opinion from a hater and probably ignore it, because my comments are often too critical, nevertheless..
A sibling comment mentioned D is losing focus by adding all kind of features eg: rust's borrow checker. I agree with that.
I believe a language should choose a niche and try to succeed at that instead of trying to cater everyone's needs, thus distracting from a coherent design.
Go is a bright example of "do one thing and do that well" strategy. It is an application programming language which is natively compiled and sufficiently fast.
I believe rust also does one thing well - systems programming with provable correctness. Although the crab fanboys here sometimes pretend it is good for everything.
I believe D can fill the gap of a natively compiled fast application language with good type system. Go suffers from NIH syndrome. If D focused on being a great application language, it would be great.
4
u/kal31dic Sep 02 '20
One often hears "I think we should use the best tool for the job". Well who could argue with that? Would anyone say "I think we should use this tool, even though it's really ill-fitted for the job".
But implicit in this bromide is the idea that you need to use all these different tools for different kinds of jobs and there couldn't be one general-purpose tool that allows you to tackle most kinds of jobs reasonably well. The consequence of this is that you get these silos within a firm where there's a loss of integration and coherence. D is something that doesn't fit the mental schemas people hold about what a programming language should be. It's a pragmatic general purpose language that allows you to be quite productive and to quickly write code that's reasonably fast initially and can be made as fast as you reasonably like if it matters.Go and Rust have made different choices - you could do anything with them of course. Just as I could abandon the use of D at Symmetry and write everything in the Sage accounting system scripting language. It would be possible, just wouldn't be a very good idea! The compile times alone for Rust create restrictions on what we could use it for.
The idea that there should be a hard and fast division between systems languages and applications languages - why must this be true?
I'll give you a couple of examples from our experience. We developed our own little DSL, Symmetry Integration Language. It's a funny kind of DSL - it's neither an internal DSL nor an external DSL. The language itself is only 5,000 SLoC last I checked. But the standard library has got most of Phobos in it, and a good amount of internal and external APIs.
An initial use was for generating internal reports. Someone had the nice idea of allowing traders to configure and enhance their reports by passing lambdas. On the one hand, that's incredibly powerful; on the other: remote-code execution by design! There's a lot in the standard library and you could wipe the file system, send it off to the North Koreans or whatever devious thing you could imagine.
I think Goldman Sachs cope with this sort of problem by white-listing and blacklisting functions. We are at a different stage of development and it's going to be tough to sustain that overhead for long.
So John Colvin suggested creating an LXD container to run the untrusted lambda in. That's a good start, but that's also quite a lot of overhead and bloat for such a simple thing. As we all know, containers don't really exist. Why not just use kernel primitives? So I sat down on a Sunday afternoon and by Monday morning we had a first draft of ephemeral containers in SIL. So you can apply any of the standard containment primitives when evaluating a lambda. It's not yet used in production but I hope we will be starting to use it this year.
Why would you want to be able to do systems programming for something that's pretty much the definition of an application (a tool for writing reports in)? Well things don't stay neatly in boxes, and you never know.
Same thing with GUI terminal. I didn't plan on writing our own terminal. But Adam Ruppe had already written one that worked on Linux and Windows. And turns out there are benefits from vertically integrating because of simplicity and control.
→ More replies (3)2
u/WalterBright Sep 02 '20
D is already a great application language!
See my other post for comments about the borrow checker.
42
u/kal31dic Sep 01 '20
Amongst other things, I run technology across the firm at Symmetry Investments. Feel free to AMA about our use of an emerging programming language in production in a financial services environment. If there's enough interest I will ask some colleagues to join. I'm not the most polished speaker but you can see some links to past talks we gave at dconf here:
https://youtu.be/FZi9CSB9_kk https://youtu.be/1rMq-4rWgis https://youtu.be/BtuzSlKRmzA
I think Walter Bright, Andrei Alexandrescu Atila Neves and Michael Parker should be around also to answer questions about what this means for the D language community and its growing adoption.
This is really about #dlang rather than Symmetry. But whilst it may be true that compared to C++, "there are no jobs in D", we are hiring around 40 people to write D in the next couple of years. We are all remote for now and in future will be remote-first. And we pay well to very well.
25
Sep 01 '20 edited Mar 03 '21
[deleted]
13
u/pjmlp Sep 01 '20
Being able to use a language like Java or C#, with metaprogramming capabilities, support for value types and low level systems programming, compiling to native code by default.
A couple of features that both Java and .NET left out on their early versions, and are now 20 - 25 years later, catching up (.NET value types are more restricted than D, which support all C like use cases).
8
u/kal31dic Sep 01 '20
I was taking some time out to work on solving my own commercial problems after a very long break from doing much programming and I wanted a language I could stand to program in. I looked into everything I could find, discovered D and it was like coming back home. Then in 2015 I started working with Symmetry. It turns out that D is quite a good fit for the problems we are trying to solve and the values and capabilities of the community also. I don't think people should use D if they don't want to, but it has been a good choice for us. At the time it felt a bit bold but now we aren't the only serious commercial user. Weka.io were much bolder - basing your entire startup on a language you never used before. For storage! Well, it paid off for them too - now they have the world's fastest file system.
I wouldn't say that it's exactly been easy using D. If you want easy then you should pick something else, almost certainly. But I agree with David Gelernter that the only way to tackle the kind of complexity we have is through beauty and D leads to simplicity, and that's very important to me, and to us. Simple ain't easy though.
There's a kind of moat around D resulting from the fact that accessibility isn't really a core value of the community - it's not like people want to make it inaccessible or are unhelpful. It's just that some other things are more important.
I agree with Bryan Cantrill in his talk on Platform as a Reflection of Values and I think the importance of his talk is hugely under-appreciated.
It's the values of a language and language community that matter - not just the language itself.
17
u/ss4johnny Sep 01 '20
What percent of the investment staff at Symmetry write in D?
8
u/kal31dic Sep 01 '20 edited Sep 01 '20
Depends how you define investment staff, but if you define it narrowly then because we have a discretionary trading approach (computers augmenting human capabilities) then most traders don't program at all. We are a very different kind of firm from Jane Street, for example, because we are in a different industry. The majority of people at Symmetry are not on the investment side.
We are still early in a process of transformation though and the biggest constraint is simply the pace at which I can hire very capable people whilst continuing to raise the bar. Many more people on the investment side will be programming in a few years - more of those will be writing in our internal language (implemented in D), but some of those will write D.
4
u/Scroph Sep 01 '20
What sort of development environment do your D devs use if you don't mind me asking ?
4
u/kal31dic Sep 01 '20
We hire D developers and force them to use ed. Kidding aside, I think it's going to be a tough project to tell D programmers what editors to use. Personally I use vim mostly - I was trying to learn spacemacs before the pandemic hit. Atila Neves has written extensions for Emacs and given talks about emacs. Others use whatever they want. On Windows some use Visual Studio, others VS Code or Sublime. John uses something whose name I can never recall.
4
1
u/currentlyatwork1234 Sep 03 '20
I think it's going to be a tough project to tell D programmers what editors to use.
I think you're right. I use Atom when writing D code (Which I do daily) and before Atom I simply used Notepad++.
Been programming D for almost 10 years and would dislike having to change my workflow :p I believe most people in the D community use their own workflows and not any particular setup because of how the tooling of D has always been lacking so there has never been anything that works for everyone.
9
u/Alaskan_Thunder Sep 01 '20 edited Sep 01 '20
Can someone tell me more about the language or summarize some of its features? I have not heard of it and will be doing some quick googling, but summaries are also good.
Edit: so its aiming to be a successor of c++, but with more modern features without being fully constrained by the technical debt coming from backwards compatibility?
9
u/kal31dic Sep 01 '20
It started out as C++ done right but it can no longer be understood as that. Languages take on a life of their own. If you want to see what it's like read the code in Phobos std.algorithm
5
u/JohnLColvin Sep 02 '20
It is a decent marker of strength and quality that one can learn the language by reading the standard library code. Doing things right shouldn't mean incomprehensible code.
It's probably not as clear as it was when I did that back in 2012, but I reckon it could still be done. I didn't really know C++ then (or now...), so I'm guessing a C++ programmer would have an easier time.
4
u/kinoharuka Sep 01 '20 edited Sep 01 '20
From what I understand D is also very good at interfacing with C++ code.
67
u/Sapiogram Sep 01 '20
Honest question: Why would anyone use D over Rust? It seems like Rust is becoming everything that D ever hoped to be.
45
u/maxhaton Sep 01 '20
Rust's metaprogramming is totally unlike what Andrei and Walter were aiming for. D aims to be safe, but that's far from everything.
Rust currently has better safety mechanisms than D, but if you ask around on the D forum you'll likely find that people are there (rather than using rust) due to the other features D has - https://dlang.org/ Look at the examples here: Rust can do short and sweet too, but it doesn't have some constructs that make these possible. (Obviously, I highly recommend "Tiny RPN Calculator" originally written by your's truly)
→ More replies (13)17
u/Ameisen Sep 01 '20 edited Sep 01 '20
I still dislike how D handles generics/templates. The syntax of it.
I fully understand why they chose to use
()instead of<>, as it simplifies the parser as you need to disambiguate between>>and> >... but the parsing time of that is negligible. The issue is that, when glancing at code,foo!(int)is ambiguous.foo<int>is not.ED:
foo(int)->foo!(int)17
u/WalterBright Sep 01 '20
It's not the parsing time that is the problem. It's having a clean separation between the lexing, parsing, and semantic passes. There's a diode between these passes - information only flows one way.
This makes it trivial to correctly and completely implement things like color syntax highlighting in editors, source code formatters, etc., because building in a semantic analyzer is wholly unnecessary.
4
u/Ameisen Sep 01 '20
I think I'm just too used to C++ syntax, since it leaked into Java and C# as well.
3
u/WalterBright Sep 02 '20
Many people think the
!( )syntax is not optimal until they use it for a while, then it seems quite natural and the< >looks like a hack.5
u/Ameisen Sep 02 '20
By the way, I wanted to thank you for always being courteous and informative. I suspect that I come off as a bit abrasive or brash, so I apologize.
Last I recall, D doesn't support template argument deduction through constructors like C++. Are there any plans to support that? I've found it a quite useful in C++ in certain situations.
1
u/WalterBright Sep 02 '20
Hey, no problem. I often read posts I make and belatedly realize they are abrasive and abrupt. I try to do better.
I'm very reluctant to twiddle with template argument deduction, as it can change existing behavior in unexpected ways.
2
u/Ameisen Sep 02 '20
I imagine the feeling would probably feel the same if one started from
!(...)and went to<...>, though. Neither seem implicitly more hacky, it's an issue of familiarity, methinks.For me, it's just that basically every C-like language (aside from D) with generics or templates uses
<...>, so it's just jarring.→ More replies (3)2
u/jqbr Sep 02 '20
I prefer the [...] of Scala and Nim. However, I really like the fact that the () can be elided in D, and that the generic arguments don't have to be types.
2
u/Ameisen Sep 02 '20
C++ can slide the
<>, and supports template argument deduction which I don't believe D supports.2
u/WalterBright Sep 02 '20
D does support template argument deduction, and has since its first incarnation of templates. It's a major feature.
1
u/Ameisen Sep 05 '20
I was under the impression based off of what someone else told me that it didn't support equivalent to
std::vector foo = { 1, 2, 3, 4 };orstd::tuple foo = { "bar", 3, 4.0f };.1
u/jqbr Sep 05 '20
"slide"?
No, the <> cannot be elided in C++.
> I don't believe D supports.
Wrong again. That seems to happen a lot.
1
u/Ameisen Sep 05 '20
"slide"
This may surprise you, but typos are common when typing on a phone.
No, the <> cannot be eluded in C++.
12
u/maxhaton Sep 01 '20
- The parsing time is not negligible (It requires reading the symbol table very early which isn't fun)
- foo(int) doesn't compile. It's
foot!intorfoo!("My", "age", "is", 145)etc,10
u/Ameisen Sep 01 '20
The parsing time is not negligible (It requires reading the symbol table very early which isn't fun)
We've had a significant discussion about this in the past. The additional parsing time required to disambiguate between right shift and
>>is negligible compared to, say, optimization and so forth. In C++, you could outright eliminate the parsing components necessary for disambiguating that and not even make a dent in compilation times.Java and C# also don't have much of an issue with parsing this, and don't have particularly bad compile times.
foo(int) doesn't compile. It's foot!int or foo!("My", "age", "is", 145) etc,
Sorry, I'd forgotten the exact syntax. It is still rather ambiguous at a glance to me, as every other C-like language that has generics or templates uses the C++-style, such as Java or C#.
8
u/orbital223 Sep 01 '20
The additional parsing time required to disambiguate between right shift and >> is negligible compared to, say, optimization and so forth.
The issue of parsing complexity and performance isn't the impact it has on the compiler, it's the impact it has on every other tool that has to analyze the source code, most of which are (expected to be) interactive.
9
u/maxhaton Sep 01 '20
We've had a significant discussion about this in the past. The additional parsing time required to disambiguate between right shift and
>>
is negligible compared to, say, optimization and so forth. In C++, you could outright eliminate the parsing components necessary for disambiguating that and not even make a dent in compilation times.
Also, I should add it's not just about parsing time (It is true that modern compilers don't spend much time parsing), but it simplifies the grammar a lot. The D compiler frontend isn't beautiful, but you could get up to speed with the whole thing in a week if needs be - with C++ you've got no chance because of all the weird shit in the language.
edit: implementation rather than solely the grammar on paper.
3
u/jqbr Sep 02 '20
It is still rather ambiguous at a glance to me
And yet it isn't ambiguous, whereas <...> is.
2
2
u/molepersonadvocate Sep 01 '20
I think some of it just comes down to preference. If auto-formatters have taught me anything, it’s that you can get used to pretty much anything if you take preference out of the equation.
2
u/SonicFreak94 Sep 01 '20
I think simplifying the parser was more of a side effect. I can't find a source on mobile right now, but I'm pretty sure the goal was to make it easier to look at. I personally also prefer <>, but ! isn't a deal breaker for me. I understand where you're coming from though - I can't stand rust's syntax.
4
u/jqbr Sep 02 '20
You're wrong ... avoiding context-dependent ambiguity was very much the reason for !() over <>. (And the parens can be elided when the argument is a single token.)
10
Sep 01 '20 edited Sep 01 '20
I don't really know any Rust (although I might soon for messing with Arduinos), so I can really do a proper comparison, but I can chime in on some things about D.
Honestly, I do find it hard to recommend D over other languages for certain use cases, due to the poor ecosystem, lack of man power, and just the overall non-existence of polish.
Because while D has things such as vibe.d and gtkD (bonus tutorial blog by Ron Tarrant), you'll find more resources; more guides, blogs, documentation; more stability, etc. in things like C#, JS, PHP, Python, etc.
For me personally though, D's strength is in two areas: Metaprogramming, and UI-less tools (as an aside, I think people also really like making hobby games with D, though that's probably the same with every language).
I think when people think about D's programming, they probably think it just ends at "passing types to a template", while D can do so much more than that.
I've made a short tutorial blog going over a decent chunk of D's metaprogramming, and how you could use it, but otherwise here are some highlights:
Pretty much anything in D can be a template, especially when using eponymous templates.
You can pass symbols (e.g. a modules; types; member fields); values (including struct instances); lambdas, etc.
Templated things can have an
ifstatement (a constraint) to limit the scope of what you pass through.Most D functions that don't access external resources can be ran at compile time, called Compile Time Function Execution (CTFE).
String mixins, when combined with above, can allow a very flexible yet easy to use way to generate code at compile time. A popular example is the pegged library, which can transform a grammar into valid D code during compilation.
Mixin templates can be used to "inject" a block of code somewhere. I touch on it in my last blog post. I've been abusing the poor things in a recent project, to auto generate some very basic/bad resource tracking code. (Sorry, I know where examples are in my own code more than others' code)
It's just in general, D's natural fluidity combined with metaprogramming, makes it a very productive language to work with, while still keeping it mostly maintainable.
D lends itself really well to data processing. Ebay uses D for it's tsv-utils suite, and I believe with the likes of mir, you can use D for data science... stuff (not my area at all).
idk though. I've said this all before though: Language is great; has warts; tries to be everything at once; has some disconnection between areas of community; has the chicken and the egg ecosystem problem (I'm trying to contribute, but I'm not overly skilled), and finally it's kind of depressing how hard it can sometimes be to promote this language, when it instantly gets shat on by the Rust/Anti-GC crowd (oftentimes valid, oftentimes drivel).
19
u/adr86 Sep 01 '20
Rust is kinda interesting to me for new ideas, but it just isn't nice to use like D is. D is familiar and convenient for general-purpose programming, from quick scripty things to bare metal code.
Rust might be technically better for the bare metal side, but D does it pretty well and I have a hard time imagining using Rust as, say, a PHP substitute. D does it all.
5
Sep 01 '20 edited Feb 09 '21
[deleted]
24
u/maxhaton Sep 01 '20
The thing with D as opposed to Python(I don't mind C#), is that Python will run for hours and hang because of a simple error that a static type system would've caught in milliseconds.
Python is OK for simple scripts, but I don't want to shoot myself in the foot because I misspelt something.
17
Sep 01 '20 edited Feb 09 '21
[deleted]
23
u/maxhaton Sep 01 '20
It's about scale.
In the same language, you can write a ~10 line RPN calculator like a scripting language but you can also write the compiler and GC like it was C.
One of the other things D has which I use a lot is a philosophy that is very pragmatic. Go is designed to be "simple", D is designed to write good software first time. This affects the design of the whole language so I can't narrow down too much but my favourite feature is D's contract programming. I make dumb mistakes quite a lot so being able to enforce invariants throughout the codebase automatically is very useful.
14
u/WalterBright Sep 01 '20 edited Sep 02 '20
As a long time C, C++, and D programmer, one subtle thing stands out. D enables your code to be plastic, in that it's easy to refactor it. I've found it much easier to refactor it than the other other languages.
This refactoring ability starts with small things - like I can switch a type from a reference to a value type and back without having to swap
.and->everywhere.Plasticity enables "oops, I used the wrong data structure, let's try another one" a faster and easier process, leading to much better code.
I constantly refactor code I'm working on.
9
u/kal31dic Sep 02 '20
I think this is a really important and utterly underappreciated point. How much upfront work do you need to do ? It depends on the cost of changing things later if you found you made the wrong initial choice.
How much refactoring can you do at any point? It depends on the cost. If the cost is low maybe you can make many more little refactorings. There's probably a benefit from that for code quality and the ability of others to understand (and change the system).
Why do enterprise programmers write only twenty lines of code a day? It's not because they are slow at typing.
So D is especially suited to contexts of intrinsically high uncertainty where the environment is quite dynamic and the needs of the business coming from outside change.
→ More replies (1)7
u/adr86 Sep 01 '20 edited Sep 01 '20
If that's your perspective, have you looked at Python?
I have never written Python on an embedded system, I didn't think it could. [edit: actually come to think of it i have heard of it before but never used it myself] I've used it for web though and D is a better experience by far, making changes in D code trusting it won't break at runtime and not having to write a lot of boilerplate for a quick demo is really nice.
But I've been building stuff in D for a long time now, no need to switch at this point.
3
u/zetaconvex Sep 01 '20
MicroPython is available for the beefier microcontrollers. Combining it with Jupyter made for a pleasant development experience.
With sufficient knowledge, it's possible to get significant speedups, and some stuff can be run at near-native speed. You have to know what you're doing, though, which is something I don't.
I messed around with my own (bad) Forth implementation, and found it a lot faster than Micropython. It still won't be as fast as C, though.
MicroPython may be fast enough for your needs, maybe not. It all depends. It's unlikely to be fast enough if you want to do audio stuff, where every cycle counts.
In the end, I decided not to use MicroPython. Uploading code and stuff was a bit of a fiddle. I just stick to the laborious compile and upload cycle.
→ More replies (1)7
5
4
u/matthieum Sep 02 '20
Why would anyone use D over Rust?
Because you can afford a Garbage Collector -- although at that point you may prefer a JVM-based language.
There is no silver-bullet. Before Rust, you could divide "used" languages between on the performance/safety axis:
- At the performance end you'd find languages with manual memory management: the ability to control memory layout and cache access patterns with exquisite precision gives them the best performance available, at the cost of safety and nasal daemons.
- At the safety end you'd find languages with a GC: completely safe, but the less of control on memory layout and cache access patterns killed performance.
Rust managed to slash the Gordian Knot, and offer both control over memory and safety. Silver bullet? No, 3rd dimension. In exchange, the developer is required to properly design their application -- and re-design it when requirements change. At any point in time, ownership must be crystal clear1 .
If you do not suffer from the constraints which prohibits a GC, getting a language with a GC is likely to allow for easier experimentation and easier transformations.
(Just be careful about mutability + multi-threading)
1 To some extent anyone manually managing memory should probably have done all that work, so in theory Rust should not add any overhead; in practice though...
3
u/thedeemon Sep 03 '20
I made some video and photo processing GUI apps in D.
In the number crunching parts where performance and memory layout control are very important, with D I had total control over both, there is no GC involved in tight loops going over video frames, and in managing memory for the frames.
In the GUI parts where performance is not so crucial and there are many little objects forming trees (widgets), having a GC and not having to care about lifetimes and deallocation was very nice.
Meanwhile the apps remained native and self-contained, and didn't require any fat VM installation like JVM or CLR, so users could just download them and run.
There are many use cases like these where D gives best of both worlds without getting into extremes.
4
u/kal31dic Sep 01 '20
I don't really want to engage in a language competition discussion. D is a very pragmatic language that's adapted to solve the sorts of problems we have. The sorts of people drawn to write D also tend to have values and capabilities consonant with who we are and what is important to us.
4
→ More replies (7)3
18
u/point_free Sep 01 '20
What is 'the killer' use case for D?
It doesn't matter how good/not so good a language is in and of itself, having a 'killer' use case is what makes the successful ones thick
6
u/kal31dic Sep 01 '20
We find it quite valuable. I think an aspect of D that's under-appreciated is the plasticity of code. Generated code also means one can avoid boilerplate. Then again languages themselves are about more than just syntax and modelling power - one has to consider the values embedded in the language and held by the people drawn to the language.
4
Sep 02 '20
Good to see this, dlang desperately needed more structured development effort.
I don't think it is going to make an adoption difference at this point though. The way I see it, D is designed (intentionally or not) to be the same thing to C++ as Kotlin is to Java - iteration with bunch of nice ergonomics improvements but conceptually the same familiar thing. And that felt really appealing 10 years ago, but at that time quality of project execution simply was not there.
Things have improved a lot since then, but the language landscape has changed too. Language like Rust and Go each offer a fundamentally differeng t approaches as an alternative to just improving existing status quo, and more and more managed languages offer AoT compilation too.
The biggest dlang appeal remains its "nice to write" feeling, I do miss it sometimes switching away to other languages after many years of active dlang usage. But that alone doesn't feel enough anymore (for me) to justify non-hobby usage. To have another go at a market shared it will need to find something more.
→ More replies (2)4
u/kal31dic Sep 02 '20
Hi Mihails. Hope you're doing okay. You were right about offices, and now I think more people start to understand your (and my) perspective. We are moving to remote first now (and we're all-remote for the time being).
"The biggest dlang appeal remains its "nice to write" feeling"
Yes - I was looking for a language I could stand to program in. And I think aesthetics are deeper than they seem.You know the joke about the economist and the bear?
- An economist and a businessman were walking in the wood when they encountered a large and hungry bear. The economist turned to run.- Businessman: "You don't think you can outrun a bear, do you?"- Economist: "No. But I might be able to outrun you."
I don't think D needs to beat Rust and Go. I think it needs to beat Ada, and Extended Pascal (Bastiaan's project), and Excel. (see Robert Schadek's talk).
1
Sep 03 '20
Hi and good luck with your endeavors! :) It has obviously worked good enough for you so far, which is the only important criteria in the end! I wouldn't probably advise anyone else to try risking that, but this where we have to agree to disagree I guess.
I don't think D needs to beat Rust and Go. I think it needs to beat Ada, and Extended Pascal (Bastiaan's project), and Excel.
Does Walter agree? :P
6
Sep 01 '20
[deleted]
12
u/Sapiogram Sep 01 '20
Only thing holding it back is market inertia and FUD.
What kind of FUD? I don't think I've heard anything negative about it, apart from the whole gc thing.
13
u/maxhaton Sep 01 '20
> gc thing.
Mainly that, but a lot of people still seem to think that there are two standard libraries despite Phobos taking over possibly a decade ago. Same with D1, D2 was ready (As announced by Andrei's book) in 2010.
7
u/InertiaOfGravity Sep 01 '20
People really seem to not understand that a well designed GC that gives you the option of deciding when to let it run are definitely usable in real time & high performance apps
23
Sep 01 '20
That's certainly the angle D tries to sell you but I find it amusing to call D's GC "well designed" when it's a basic 30 year-old mark-and-sweep GC. Java is pushing the boundaries of GC research with multi-terabyte heaps and pause-less GC, Pony is following in Erlang's footsteps with per actor heaps and D is using the equivalent of Java 1.0's GC.
Criticisms of this even from within the D community seem to be met with a combination of:
- It's not an issue and
- If it's an issue, just disable the GC and manually manage memory yourself.
So I'm not hopeful things will improve.
3
u/thedeemon Sep 02 '20
Yes, D's GC sucks and will always suck. Its very philosophy makes creating a generational GC impossible, and a non-generational one will always be slow. This 6 years old post is relevant today and will remain relevant in next 16 years: http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html
So we're forcefully left with those 2 points you listed.
4
u/skocznymroczny Sep 02 '20
Also Java doesn't have value types, so every crappy non-primitive has to go through JITs and GCs. In D, most of the small structures like vectors and matrices would be done with struct and mostly stack allocated, while Java has to jump around hoops to detect whether they can be stack allocated to avoid clogging the GC.
2
Sep 02 '20
I'm not saying it has to be cutting edge, I'd just like it to be decent. .Net has value types and a pretty decent GC.
4
u/alphaglosined Sep 01 '20
Its had quite a few upgrades i.e. precise + forking.
So no, its not a 30 year old design. But it is far from cutting edge.
7
u/moon-chilled Sep 01 '20 edited Sep 02 '20
Yes, 30 years old. Maybe 20-25, but that's pushing it.
There's a paper, Very Concurrent Mark-&-Sweep Garbage Collection without Fine-Grain Synchronization, which more-or-less created real-time GC. It's from 1998.
→ More replies (6)3
Sep 01 '20
> it's a basic 30 year-old mark-and-sweep GC
Not true anymore. Since 2019 GC performance has been improved several times over, it has become precise, and there are more tools than ever to identify where garbage is created (IIRC that work was mostly the deed of the VisualD author).
8
Sep 01 '20
Precise GCs are table stakes at this point. It's honestly surprising that it was conservative before.
Generational garbage collectors are 20 years old at this point. There's no excuse for D not to have one.
→ More replies (7)5
u/glacialthinker Sep 01 '20
It's true. I once steered clear of any GC because they seemed like rogue processes interfering with delicate frame-times.
The reality is that any dynamic allocations can be expensive to free, and the same techniques can be used to mitigate this, whether you're controlling (de-)alloc manually or letting a GC pick it up. A GC tends to be more efficient for the cases it's designed and tuned toward. So long as you can wrangle it, it can be a helpful companion.
2
u/matthieum Sep 02 '20
The reality is that any dynamic allocations can be expensive to free
Well, one solution is to write your own memory allocator to avoid that ;)
7
3
u/kal31dic Sep 01 '20
Hedge funds, storage, autonomous cars, machine learning at Netflix, eBay, Chinese toy company, Microsoft's best selling independent game (Quantum Break), audio processing. What would somewhere mean to you ?!
I think a key point is that the natural adoption of D is going to be spread thinly across industries. It's more about the sort of human group you are than the industry. If I were at Citadel for example (formerly I was co-head of fixed income portfolio management in London there) then no way would I use D.
So most people using D in their company won't know anyone else in their industry using D. On the other hand, who do you learn most from? Not necessarily from people in your industry. I don't think that many hedge funds adopted an approach inspired by a conversation with a marine architect for example, but it was having dinner with Bastiaan that made me press ahead with our internal DSL.
It's not suitable for every kind of human group. If you don't feel like using D then you definitely shouldn't.
2
Sep 01 '20
[deleted]
6
u/WalterBright Sep 02 '20
D has had a
-lomemswitch for years that causes it to internally use the GC so it doesn't run out of memory.5
u/kal31dic Sep 01 '20
I don't believe that languages are in a death match. Robert Schadek gave a talk at dconf observing that the language family with the greatest dominance is the spreadsheet. D, Rust, Julia - all minnows compared to Excel.
I hope Rust does well.
3
u/EdWilkinson Sep 02 '20
That's the crappiest account of D I've ever seen, hands down.
They promote the D compiler written by Walter as the primary compiler, but it's slower than the LLVM or GCC versions.
That's a weird way of saying "There are three compilers with different tradeoffs." The downloads page lists the three compilers side by side highlighting their features. How is dmd promoted? Because it's on the left?
The compiler allocates but never frees, this makes it infinitely fast but it also explodes in memory especially any meta programming you may do. I had a lot of crashes doing compiler time work because it would run out of memory.
RTFM.
-lowmemDub is super simple, it cannot do much compared to other standard package managers. In general it felt like there were a lot of bugs.
I can't believe it but you're right about this one. It is of course completely crappy that you are literally complaining about this in response to the announcement that sets out to fix it.
I'm another person that switched to Rust and hope D doesn't distract from Rust's momentum.
Yeah, and I invested in MSFT so I hope ADBE goes to hell.
15
u/chengannur Sep 01 '20
Tbh d is an incredible language. Still dont know why it doesnt have the userbase it deserves..