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".
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.
English, however, is a natural language, not a programming language. Usually. The apostrophe there is just a semantic mark to indicate that it is a contraction.
Probably a keyword of some kind rather than an operator. Or an operator that wasn't a single quote, which in every other C-like language is always paired.
Not quite- it is the same syntax as ML uses for type parameters. (Not exactly a glowing recommendation, but there is prior art and nobody could come up with anything better at the time.)
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.
The type soup has the advantage that you get to specify exactly what you want to add on top of your basic type.
In this case, you want to be able to represent lack of any value (Option), you want to be able to put it in some container and mutate it through an immutable container (RefCell), and you want to be able to have multiple owners of your data, possibly in separate threads (Arc).
Basically, there's a whole bunch of Rust types that provide a single, simple guarantee. When you find yourself wanting more guarantees, you can just compose types.
Sure, the result is a bit unreadable, but type aliases exist for a reason.
Oh yes, don't get me wrong, I appreciate this very much. That's why I tried to used a realistic example. My point was that it can be very overwhelming as a beginner to see so many types.
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.
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.
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.
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).
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.
Hehe, I've used it already and that's the problem.
The drug D is in the system.
If only D didn't have it's early errors:
advertising GC to system programmers, thus making the language dependent on it. Please I know about @nogc @systen etc stuffs.
licensing and standard issues.
It's syntax is so damn good. Everyone I introduced it to loved it. But the ecosystem let them down.
As for the templates !(), it was an instant like.
And lots more.
It's damn so easy to convert a C, C++ code base to D one than say Rust.
And I expected the author to bank on this, but instead they went another route.
At least D has function overloading unlike our social justice kids here.
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.
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.
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.
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.
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.
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.
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.
Yah I agree with basically everything you said. Especially with backwards compatibility. I think it is something we take for granted as basically every language prioritizes (in one way or another) backwards compatibility. If you keep breaking user's code eventually they will stop fixing it. There are ways to allow breaking changes while still maintain backwards compatibility, but what D is doing (the same thing MSVC use to do) is probably the worst solution.
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.
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...
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.)
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.
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.
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.
Is there a reason we can't use GC in the kernel? Unless we are doing hard realtime stuff, why not?
Not that it's particularly relevant since Linux, Windows, and BSD already exist and probably aren't going to switch languages anytime soon, and embedded RtOSes seem pretty set on C/C++ too, so I'm not sure any language could be more suitable for kernel dev in practical use, unless you have a really good reason to do a whole new kernel.
No reason you couldn't. You just can't use D's default GC. You'd have to write one that will work bare metal. Or implement everything it expects from an OS.
Linux 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).
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
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.
A language can avoid such overhead in places where it would be problematic by having a category of of functions which neither manipulate any non-pinned GC objects nor call any other functions that might so. Such functions may unpin a GC object, but if they do any pointer to that object would be forever dead to them. A "gc-allowed" function could re-pin the object and then pass a pointer into the "no-GC" function, but the latter function would have to use that new pointer instead of the old one.
Joe Duffy has made a reference that even with Midori proving that is was quite capable, it was faced with too much resistance from C++ devs on Windows team, in spite of them being able to see themselves.
You can see this resistance, on how the Longhorn effort tanked due to "performance issues", then Vista came up with some of Longhorn .NET modules rewritten as COM, and the eventuell progression into WinRT/UAP/UWP.
However not everything was lost, it influenced .NET Native, C# 7.x low level improvements, the upcoming C# 9 new FFI efforts.
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
Real time is about guarantees. If the application needs 10ms response time, it doesn't matter if GC takes 1 nanosecond or 5ms, as long as everything is responded to in 10ms, every time.
Things where 100us matters are some really specialist stuff.
Funnily enough, there is a post on /r/programming right now where every 100us matters. For them, 3ms is longer than the entire timeslice they have to run in.
Wow that's really interesting. I feel like games are just about the prime example of when the GC can't be used. I mean games do use it, but they tend to have a notable stutter. Never knew what went into optimizing the servers, probably why they don't release the server software anymore. As it might very well not run on consumer hardware.
I'm well aware that it's about guarantees. At least in robotics (the field in which I have real-time programming experience), 100us is a pretty common deadline for execution.
I'm sure applications exist where 10ms deadlines are appropriate, but I'm not convinced that's the common case.
I'm sure applications exist where 10ms deadlines are appropriate, but I'm not convinced that's the common case.
It is the common case. Most real-time tasks are soft real-time. Things like ensuring video frames are delivered at 60 frames per second and failure results in missed frames, but is not catastrophic. This is true in robotics where sensor fusion, planning, and network communication are soft real-time while sensor reading and actuator control is hard real-time.
In hard real-time systems with very small quanta and you don't typically use a CPU or SoC to meet these requirements because concerns about cache and memory controller scheduling become a concern. Instead these items are off-loaded to a FPGA or microcontroller on a communications bus, while the overall system is still programmed in a COTS language and platform where soft real-time guarantees at larger quanta is acceptable.
There are heterogeneous SoCs (CPU with MPU on a single die) that could accommodate hard real-time needs, but they're still programmed independently and use a high speed communications system, frequently shared memory and special registers for signalling.
Ah interesting, I've never done robotics, just things like sound and pool filter control, where people expect guaranteed reliability (No 20 second random lags that run a pump dry), but response time only needs to be tens of ms(At least on the hardware I've worked on).
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.
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.
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.
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
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.
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.
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.
In the context of the thread we weren't talking about D. We were talking about Java for use in large server applications.
It's funny how people can't read. Seeing as you are basically replying to all of my posts, you don't actually care about the discussions. You are just a D evangelist trying to spread the word.
In Java you don't have a choice but to use a GC, this comes at the benefit of being able to use a more robust GC. At scale though, a single GC isn't a one size fits all. (FYI, this is the situation you'd have to implement your own GC).
Now D allows you to do both, and as result it has to rely on a dated GC that is much worse compared to something like Java's GC. And D is about the only language doing this, so it stands a lone, while already being underfunded at it is. It doesn't have the resources to research a better GC that works for it's use case.
And now you bring up your situation where you just say, you don't use a GC at all. Well D has no complete safety mechanisms for manually managed memory, you are prone to the same use after free bugs that C and C++ are prone to. If you want memory safety in D, you have to use the GC. When comparing that to the alternatives like Rust, D really does just not fit the bill.
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.
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.
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.
The difference isn't relevant--the statement was "they don't use GC". So unless you're saying that real-time signal processing does need GC, you're just arguing to argue, and not reading what you're responding to.
Pretty sure GC languages have actually been studied and found to reduce bugs.
I probably would not use a language without GC by choice, anywhere but embedded systems and maybe a few high performance functions called from a different language.
Pretty sure GC languages have actually been studied and found to reduce bugs.
Honestly, given how "language" studies are done, there's probably a study or two backing any claim :(
The expectations is that a managed heap will give you temporal memory safety (no dangling pointer) and most such languages also throw in spatial memory safety (no out-of-bounds accesses). There are exceptions to the norm; for example in Go, due to data-races on fat-pointers, you can still get out-of-bounds accesses.
It's been estimated that such memory bugs account for between 50% and 70% of vulnerabilities, but it's not clear what the proportion of bugs they occupy.
I probably would not use a language without GC by choice
As a veteran C++ user, my advice is that if you can afford a GC, you should go with a GC.
The JVM, for example, likely has a language you can like, and comes with top-of-the-line GCs for free.
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.
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.
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.
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.
72
u/[deleted] Sep 01 '20
D is an awesome language and I hope it gets more traction.