The D Programming Language
dlang.org
dlang.org
- Adoption of any technology is by a normal distribution.
- The segments are early adopters, pragmatists, late adopters and laggards.
- If you want a technology to become mainstream, you need to make the pragmatists adopt it.
- This is rational behaviour and there's no use trying to convince the pragmatists otherwise. They will choose "predictably disappointing" over "excellent and unproven" every time.
- Technology is merely a tool to them. They don't care if it's fun or not, as long as it gets the job done.
- Mainstream success is impossible without getting the pragmatists on board. Until then you have a curiosity used only be early adopters.
- How to cross the chasm? He recommends finding a pragmatist in pain and solving their problems. Gradually convert pragmatists one by one.
I don't think D was ever able to articulate to the pragmatists why they should adopt D over C++ or other languages. Fixing a few warts with C++ wasn't enough.
Meanwhile Rust managed to appeal to the pragmatists by saying "we know you use C and C++ because of the performance despite the issues with it. Why don't you try a language with the same performance, which also fixes some of the issues (buffer overflows above all) at compile time".
Rust was far from perfect when it started seeing adoption by pragmatists, and it remains far from perfect today. But perfection isn't the goal, nor is a "fun" language for early adopters. What matters is solving a problem that pragmatists face and then convincing them to give you a shot. In practice this is a bar that is high enough that most languages never cross it.
Not sure that's true. One of the first adopters of D in production was Facebook, because one of the engineers (Andrei Alexandrescu) worked there and evangelised it heavily internally. Many projects were written in D. But eventually the cost of maintaining support for one more language in production didn't make sense. D didn't solve problems that C++ (another supported language at Facebook) didn't. The D code was rewritten. It's not that Big Tech didn't adopt it. It's that it didn't show enough value in time.
What's your source on this?
I no longer have access, but if a Meta employee is reading this, I'm referring to a post that called Alexandrescu a "whirlwind of energy" in terms of how he personally encouraged and enabled teams to adopt D for projects.
When you read about D and why it is not popular, one thing to keep in mind, is that there was D1 for a long time and then came D2 and this process was not as smooth as it could be. The dev progress was and stays slow but steady. D is in a better place today than it was 3 years ago for example.
D has two problems: it doesn't have enough "new" stuff to appeal to the "early adopters" - Rust has sum types + pattern matching, type classes and the borrow checker and, as you've said, it couldn't convince enough "pragmatists" to switch.
You really aren't the best language salesman on earth ;). And that's great!
Cargo is great if you're starting from nothing, but it's not very pragmatic to ignore all your existing code and experience and form another ecosystem within your organization. There's probably a limit to how many code ecosystems you want in your org, even in large and well-funded ones.
In Rust's case, enough large, medium and small companies have adopted it that it continue to be a thing a decade from now. Google alone has a large vested interest in ensuring the continued development and ecosystem health of Rust, because it uses it for critical components in Android. Android isn't going away, nor will they rewrite their Bluetooth stack (https://android.googlesource.com/platform/packages/modules/B...) and Binder (WIP - https://lore.kernel.org/rust-for-linux/20231101-rust-binder-...) again in some other language. Now extend the same argument to the projects within AWS, Microsoft, Meta and others that depend on Rust and can't rewrite their Rust projects without a massive investment.
The point isn't that all new code at the pragmatists must be written in the new language. A few critical projects are, adoption within the pragmatists continues to grow with time. This allows a new company thinking of adopting Rust to easily answer the question - "Will it be around in 10 years? Will the ecosystem still be thriving? Will it be easy to hire for this?" It's a likely "yes" to all 3, because so many pragmatists are invested in making it so (https://foundation.rust-lang.org/static/publications/annual-... - See "Member Overview"). All of these companies are literally paying tens or hundreds of thousands per year to help the ecosystem flourish.
It's hard to tell if the early adopters adopted it either
- It doesn't show up at all in the 2023 stack overflow survey (nor in the previous two years) - https://survey.stackoverflow.co/2023/#technology-most-popula...
- It doesn't show up in questions asked on Stackoverflow since 2008 - https://insights.stackoverflow.com/trends?tags=kotlin%2Crust...
- Nor on Google insights - https://trends.google.com/trends/explore?date=2012-07-31%202...
But maybe there is a different data set that shows early adopters adopting D. But for me, I would say a language has been adopted by early adopters when it reaches 1% of all developers in a reasonably large survey. Given that, it's entirely fair for a company making a language decision now to ask if D will still be around in 10 years.
C++20 is a very different language than C, but it got to mainstream because at the beginning it was "C with classes". Typescript is similar.
Every company has a bunch of "early adopter" engineers. The easiest way for them to introduce something new at their company is by claiming that the transition will be seamless and free.
D partially tries this path with its C compatibility. But it's a rare C codebase that doesn't use function pointers or array pointer syntax. I don't think D had any choice but to abandon those, but it made this path a lot harder.
P.S. there's a third route: piggyback along with a market transition. That's how Java & Javascript & Perl went mainstream.
// D code
import mycstuff; // loads mycstuff.c
int main() {
int* p = mycfunction(); // call C function
return *(p + 1); // pointer arithmetic
}Isn't Rust still a niche programming language? When compared to C, C++, C#, Javascript, Java, Python?
With Rust being in the kernel of both the most mainstream operating systems and it gaining traction in the embedded world it would require a catastrophe of gigantic dimensions to bring that tanker off course from becoming mainstream.
It will take time of course, but that is no difference from other contemporary mainstream languages. I remember that Guido van Rossum being asked what he'd consider Python's breakthrough and he answered that it had none, that it just grew slowly and steadily over a long time. Now, things have been set in motion for Rust, we will see where it leads.
Also, Modern C++ is reasonably safe for most uses, almost safe, and things like Hylo language are IMHO just a better model than Rust-borrow-everything, which is basically viral at the API level and hard to manage compared to mutable value semantics.
I’ve been rewriting my python personal project in rust the past month and it’s going much quicker than I expected. And with Dioxus I’ll be able to distribute a full multi platform gui app at 10mb vs python + JS and all the fun that comes with that.
I do not have extensive Rust experience, but the times I tried it got on my way. My background is C++ (20 years using, 14 years working on it). They say that best practices in C++ are in Rust, but I think it is not that similar sometimes even from my mindset when thinking in C++. It is just quite a bit more ceremony in real life IMHO what I saw.
My conclusion back then was that Rust was by far the worst and that it is mostly because GPT-4 just didn't get the borrow checker. Coming from C/C++ and being a bit of the opinion that the people complaining about Rust's steep learning curve are often a bit overdramatic, it convinced me that they might actually have a point. If even the LLM doesn't get it...
This is bound to 10 million dollar engineering effort, alongside one million more as donation to the Rust Foundation.
The issue with Modern C++, is that we are already in a Post-Modern C++ phase, and plenty of people keep writing classical C with Classes instead.
Honestly? I simply don't think the learning curve of Rust is worth mentioning, or at least it is in my opinion on the same level as C++'s. Or putting it this way: using C or C++ does not mean that you are free of managing the objects' lifetimes.
Since it does not have exceptions, same for propagating Result type up and down. Both go viral. The compiler is strict.
Of course you have to think about lifetimes in C++ but it is more flexible.
That said, Rust pattern matching and traits are nice.
Rust is stricter and the learning curve is steeper overall IMHO.
I really think a borrow checker is not the way to go for safety. Hylo language model is what I would choose first above everything else.
You still have to do all the hard work thinking about lifetimes even in C++, things like whether lifetime A will surpass lifetime B and all that jazz. It's just not spelled out.
As long as you work a bit defensive and do not use references or raw pointers and use smart pointers and values (span and string_view are NOT values, they have reference semantics), things should be ok lifetime-wise.
It is just that we just want to go, sometimes, a tiny bit faster and fall into the temptation of returning a reference or similar and we mess it up when refactoring. But if you take into account the 80/20 rule, then sticking to safe practices should be the default most of the time and leave a pointer or a reference for an inner loop or something performance-critical in a very controlled environment is the wise choice.
In my experience, sticking to these practices make things work very well in practice. I rarely see a segfault in my code when coding C++. I also use `.at()` systematically, btw. And I am very conservative when using `string_view` and `span`.
Or why not keep exploring this idea as well? More research-oriented than the first one right now, though, so take it with a grain of salt: https://vale.dev/ Look at "generational references".
I find the first solution for Hylo as the correct mainstream one and the one in Vale as promising, though not sure where it will lead or if it can keep up to its promises.
Both remove from you a high cognitive overload and keep memory safety intact without a GC.
Particularly striking was how concurrent innovations like copper tools, steam boats, and milk pasteurization derailed only partially developed scurvy theory. One wonders if this story partly inspired Woody Allen's joke in _Sleeper_ about steak being found to be good for you.[1] { Probably more the constant thrashing about of recommendations that has infected nutrition science since forever, though. }
- non-free compiler
- GC (when Java, C#, etc already ate into that C++ segment
- competing standard libraries
These have been solved in different ways but diseminating that knowledge and changing people's gut feels is hard. Its then made more difficult by competitors coming out before overcoming this (e.g. Rust)
GC - you can build entire application _without_ GC. Nobody forces you to do that.
Competing standard libraries are thing in the past after the Tango project has been abandoned.
So really, what are you talking about?
This is a gross misrepresentation. With D you must opt-out and be cognizant of libs they may or may not require GC.
> Competing standard libraries are thing in the past after the Tango project has been abandoned.
We are discussing why D failed adoption where the history and past are INCREDIBLY important factors.
So really, what are you talking about?
If the @nogc attribute is used, the compiler will tell you where the gc is used.
It is difficult to prove to the performance-oriented people that GC'ed languages can be performant, and years of JVM stop-the-world GC didn't help to improve the reputation of GCs either.
Even though D has @nogc, non-D programmers would probably have serious reservations as to whether the ecosystem is split between GCed and GCless, and how much that split would affect them and their project.
IMO, Rust did it quite right in this regard by making GC opt-in (with rust-gc) - although borrow checking is an imperfect way of doing safe memory management (eg. cyclic references), the fact that it attempts to be a "safer C++ at no runtime cost" certainly has pulled some people over.
The "serious reservations" is simply unfamiliarity.
The GC has uses where it shines. Allocating data structures that last the lifetime of the program instance. Enabling data allocation during Compile Time Function Execution. Scripting programs.
Borrow checking has its costs, too. Some data structures won't work with it. Sometimes to conform to it means allocating an extra copy. Some code has to be marked as unsafe.
D has a borrow checker, too. It's opt-in, though.
And introduces a straight jacket that avoids valid patterns from being used and makes binding C++ a hell.
But who knows how well a language that prioritises interop with C++ will fare? I guess we’ll find out Carbon 1.0 shows up in 2025. Similarly Zig with its fantastic C interop.
This definition of mainstream is more useful than “almost all devs know the language”, which is something that only applies to Python and JavaScript anyway.
By this definition, you probably don’t want to start a new codebase in COBOL, Perl, Objective-C or other languages that are trending downwards in usage. But you can use languages that have reached that critical mass like Rust and Go, even if every single developer might not know them.
I’m basing what I say on what languages developers said they knew in the 2023 StackOverflow survey (https://survey.stackoverflow.co/2023/#technology-most-popula...). You definitely would call Java and C# mainstream, and they’re used by 31% and 28% of developers respectively. Go and Rust are used by 13% of devs. Not in the same league, but they’ve both reached critical mass so they won’t disappear.
Well, then Haskell or D are mainstream... but I would not say they are.
I would say mainstream are: C#, Java, C++, C, Python, Javascript, SQL... but not Haskell or D.
I don't see that at all. I see it appeal to idealist.
At the end of the day I think it is more of an economic model rather than that distribution problem. You need a company to be the language power house.
``` func toUpperCase(s: string) <IMPLEMENTATION>
a = "hello world" echo toUpperCase(a) # HELLO WORLD echo a.toUpperCase # HELLO WORLD echo toUpperCase a # HELLO WORLD echo a.toUpperCase # HELLO WORLD ```
With the dot syntax, the first argument is the one indicated by the dot, and the rest of the arguments are in the parentheses. In nim, you can leave out the parentheses too, which makes `echo` statements cleaner.
It's a shame more mainstream languages don't have this feature.
I really like the option to "semantically scope" a function to its main subject, like in kotlin extension methods. But I fail to see why I'd ever want to have both options. Is it just a compatibility thing, to be able to call code written for conventional languages? Or from developers who don't like that approach?
let letters = word.chars().filter(|ch| ch.is_alphabetic());
let letters = word.chars().filter(is_alphabetic);
Yes, it would be great to have a way to turn a method into a function. That doesn't necessarily mean that they have to be unified---an explicit conversion is enough.
[1] https://doc.rust-lang.org/reference/expressions/call-expr.ht...
I've done a little langdev and I've found that UFCS interferes with stuff like field access (person.name) or things like interfaces. Let's say you have a person struct like { name: str } but then also a Label interface like Label { name: fn () -> str }.
It's kind of a broader problem of being able to extend things in any place you might imagine, like I'll implement a trait on this struct here, I'll implement a function on this struct here, etc. etc. and before you know it your code is extremely nonlocal. There are ways to temper this, e.g. Rust combats this a little by having to have traits in scope for them to apply, but that's annoying in its own way.
I'm just saying it's not a free lunch, I think anyway.
For the function-field interference, I'd probably just work it based on situation. And usually naming functions clearly as actions with verbs and fields/variables with nouns.
``` func toUpperCase(s: string) <IMPLEMENTATION>
a = "hello world"
echo toUpperCase(a)
# HELLO WORLD
echo a.toUpperCase
# HELLO WORLD
echo toUpperCase a
# HELLO WORLD
echo a.toUpperCase
# HELLO WORLD ```I’ve seen a lot of protest on HN and Reddit from people who feel the currently popular language is being “shoved down their throat”. But if you’re not open to that we would be writing C forever, let alone C++ or Java (which had their own hype cycles).
> The world is often unkind to new talent, new creations. The new needs friends.
Granted, there are definitely cases out there where Julia users have been overzealous and undersensitive when trying to convince others to come try out the language, but my experience with these people is that they're almost always coming at it from a place of just being excited about finding a language that works well for them and solved so many of their issues, and so they want to share that with others.
____
D is a cool language and it's a shame it seems to get ignored so much. I hope D people continue to work at it.
> ... because of how little they care about increasing the safety in the language (like Rust or Ada).
I think it's a bit harsh to compare Julia to Rust on that front. Julia has completely different design goals. Compared to Rust's borrow checker and C++'s move semantics, Julia's immutability-by-default (+ clever compiler optimizations) gives a good trade off between performance, safety and ease of use. While Rust goes for safety + performance, Julia goes for performance + ease of use (respectively dynamicity).
Nevertheless, I miss some features related to type driven development in Julia, which would improve safety:
- A newtype idiom
- Sum types
- Explicit, type-checked interfaces : I actually would prefer something like C++20 concepts (a blacklist approach) to Rust's trait (or typeclasses, a whitelist approach), because it would be a better fit for Julia's design goals.JIT doesn't happen in Python because the community rather rewrites code in C, than support projects like PyPy.
NVidia and Microsoft had to come into play to change this.
In julia, there is no separation between generic functions and fast functions, and no separation between user defined types and inline allocated structs.
This is not the case with Python, Smalltalk, Common Lisp, etc.
To actually take hold and stop people from relying on C libraries for everything in Python, the Python JIT is going to have to be as fast as C, and it's also going to need to have a CPython compatible ABI because people are not going to abandon all these pre-existing libraries overnight.
Python's semantics make both of those prospects incredibly dubious.
Smalltalk, Lisp and SELF were used to write complete graphical workstations, where a debugger code change or dynamic code load across the network could impact JIT decisions across the whole OS stack.
At the same time though, because Python has such a tremendously big ecosystem, all written in C, and targeting specifically the CPython interpreter ABI, even if you make a JIT compiler that is as fast as C, it'd also need to support the CPython interpreter ABI, otherwise it'd never catch on because the JIT compiled implementation of the language would have to start fresh with almost no ecosystem support.
The situation is even worse if we take the realistic view that such a JIT compiler will make some serious performance compromises relative to the existing C code everywhere in the ecosystem, and the fact that the CPython interpreter ABI is so entangled with the internal implementation details that it's impossible to support in a way that's even approaching being performant.
They are as much Python as they could be Tcl.
Ironically it sufficed to Microsoft and CUDA step in, followed by Facebook as well, Guido gets out of his Python retirement, and JIT, GIL-removal are suddenly issues that matter.
Me too.
Do you wish to suggest that Smalltalk implementations had "C performance" ?
Do you wish to suggest that some Smalltalk programs should still be a little faster than corresponding Ruby +YJIT programs ? (But then NodeJS.)
Do you wish to suggest that Ruby +YJIT programs should be faster than corresponding CPython programs ?
Calling out to C libraries doesn't count for CPython performance, that is C code, not Python, and any language with FFI can call into C libraries.
(Name dropping ancient language implementations was confusing to me, and I'm ancient.)
There's little reason to think these new JITs will fare any better.
I am also curious how Mojo will turn out, from the last LLVM developers conference talk, it is quite interesting after all.
At best it needs an AOT compiler, to accelerate final scripts, and that's where projects like Mojo start to become interesting
Julia still have a sucess story and is a lot bigger compared to D.
This was Rust for a decade. It was really annoying. But now we have a wonderful new language with tons of support that could legitimately challenge C++ some day. So I tend to agree.
If someone more experienced in D could offer any insights around why someone should prefer D over nim for a new application outside low level applications where gc is absolutely undesirable, I'd really appreciate that. I am not an expert in either.
Thats said, I am a huge fan of D and your work in general. Please keep creating awesome stuff!
See https://nim-lang.org/1.4.0/gc.html
Do you have a page that shows otherwise??
As for ARC/ORC specifically, you can read a small introduction in https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc..., but as a TLDR: ARC is something closer to RAII than a GC (destructors injected automatically at the end of scopes) with reference counting for reference types. You can switch between ARC/ORC when compiling, and destructors give a lot of control - https://nim-lang.org/docs/destructors.html.
In more words: You should be able to use Cosmopolitan libc: https://github.com/Yardanico/cosmonim
If something does not work for you, Yardanico is super duper helpful in all things Nim.
Nim also compiles to Javascript (nim js) and C++ for integration with legacy codebases, but that is probably more to the side of your interests.
While I have never seen it done and always meant to give it a try, compiling to C should allow one to also do things like write Linux kernel modules in Nim without any special support from the Linux team.
Much in Linux is contentious :-) which is why the module system is nice. A kernel module for C code requires no permission from Linux-core unless you need it distributed with the kernel (which, yes, might be required for "credibility" - but critically also might not). It may require many decls to access various kernel APIs, but those can be (semi-)automated or just done as-needed. So, Linux kernel policy is not so relevant (at best) which is what I meant by "no special support" (admittedly brief). Kernel coding is always a bit trickier, and you may need to build up some support code to make integration nice, though as well as decl generators (though none of that need be distributed "with Linux").
> Can one disable runtime in Nim completely -- no GC, no exceptions?
To answer your question, and as discussed elsewhere in this subthread, Nim has many options for memory management.. only stdlib seq/string really needs automatic methods. One can disable the runtime completely via os:standalone and statically check that no exceptions are raised with Nim's effect system (and there are also both setjmp & goto based exception impls which may/may not be workable in Linux/BSD kernel module settings).
As "proof more by example", a few people have written OS kernels in Nim recently[1,2] and there was another toy kernel long ago[3]. People have also written OS kernels in Go which "has a GC and runtime".[4] So, I acknowledge it's not quite the same example, but I also see no fundamental blockers for kernel modules.
[1] https://github.com/khaledh/axiom
[2] https://prosepoetrycode.potterpcs.net/2023/01/a-barebones-ke...
type Foo = object -> no GC, stack object, can use destructors type Foo = ptr object -> manual memory management type Foo = ref object -> "GC", refcounting to be exact.
One nice feature D has is you can:
import mycfile;
does the same in Nim.
From what I gather from the D docs (which I have only casually browsed through), the kind of adhoc ast construction that nim macros enable is not possible in D.
[1] https://www.nimprogrammingbook.com/book/nimprogramming_rouge...
[2] https://www.nimprogrammingbook.com/book/nimprogramming_rouge...
We have a wonderful conference every year in London. The last one was particularly nice - lots of people, everyone had a good time (especially myself).
(Once you have an internal D ecosystem, you start selecting for D developers, who then prefer to keep using D, and so it persists.)
Das C. ( D as C )
I remember Vectorflow for sparse neural networks.
https://youtu.be/V2YwTIIMEeU?si=To2DBlzz30XAUptN
https://dlang.org/blog/2022/02/19/how-i-taught-the-d-program...
Not one of the tech giants, but not a small company either: https://www.weka.io/
In this world, D was, while not a common choice, also not an unexpected one. The most common language for these sorts of products is C... but it's not the kind of C you'd find in books about the language. It's C that's heavily modded to remove or replace a bunch of stuff. D just happened to align well with what people running the project would've done to C anyways.
Also, in this context the existence of libraries doesn't matter, as almost everything is going to be written from scratch anyways. Nor does learning the language matter, since the internal infrastructure and learning how C was modified to fit the project goals would take the same time as learning another language.
To be honest, I really liked to work in that environment. Not because of any of D's features. I just hate being in the constant fear that I will not be allowed to do something that makes perfect sense, and instead coerced into idiotic workarounds that pretend to solve the problem. Which is what happens when you are required to use third-party libraries and they absolutely don't anticipate your use-case. It's the place where I was closest to being proud of what I was doing. Unlike most day jobs I had, where I felt like I need some extra time in the shower just to not feel dirty by writing code I knew full well should've never been written.
> Our backend is mostly implemented in OCaml with some D and C++.
Sadly never had the opportunity to try to use it.
1. Cloud - D is perfect for serverless if D improve its GC and standard library, language like go probably won't even exists in first place.
2. Mobile - in early day, mobile is slow and has low memory, If D has good tools and GUI framework, it will take off. Even today, it's difficult to crate app for mobile using D.
LLVM probably the last straw that D out of favor, before LLVM, crate product ready language is difficult, now, everyone is creating their own language...
For all the praise LLVM gets, already in the mid-70's compiler based frameworks were a thing, IBM PL.8 RISC project, and early 1980's Amsterdam Compiler Toolkit are two notable examples of similar stacks.
Go would still exist, because Google would never picked D for their cloud projects, and its adoption grew from Go creators working at Google. See how sucessfull Oberon and Limbo projects from the same authors were, before their Google days.
While C++, Java and .NET now have most of the features that D was known for when Andrei Alexandrescu published his Programming in D book, I still think the execution in D is better packaged, although yeah, wihtout the related ecosystem and IDE tooling, it is an hard sell.
Maybe "slow and steady" still will surprise us, like it took Rails to make Ruby known outside Japan, or maybe it is too late no matter what.
Future will tell.
LLVM has the core IR structure as an in memory structure and as a text format and as a binary format. The easy, lossless (modulo partial implementation of new features) conversion between the formats was a really big deal. I'd be interested to hear of prior art on it.
In particular, it means developers can diff the IR between passes and generally apply textbased tooling to it during debugging, and you can do things like link time optimisation really easily by combining separate files then running them through the optimiser.
LLVM is creaking a little under its age, and I don't think it's ideal that it's written in C++, but the flexible architecture is legitimately better than I've seen in other compilers. In particular, it has been a competitive edge over GCC.
Unfortunely when they killed the project, little was left on the Internet, and they have other projects with the same name.
https://en.wikipedia.org/wiki/Microsoft_Phoenix
https://devblogs.microsoft.com/cppblog/channel-9-video-andy-...
The paper "An overview of the PL.8 compiler" refers to how they implemented a multi-stage IL pipeline to write a mostly safe systems programming for IBM RISC project.
https://dl.acm.org/doi/10.1145/800230.806977
Unfortunely there isn't much publicly available, and IBM eventually pivoted the RISC efforts into AIX, thus abandoning this effort.
Amsterdam Compiler Toolkit used EM intermediate language as its bitcode format,
https://en.wikipedia.org/wiki/Amsterdam_Compiler_Kit
If you delve into ACM, IEEE, SIGPLAN and related stuff, there will be similar projects, LLVM ended up getting the spotlight thanks to Apple and Google's sponsorship, followed by others in the industry.
I still hope that GraalVM (nee MaximeVM at Sun Research Labs) will keep going, as it is yet another approach for compiler toolkits, with a safer language.
Can't CoreCLR be used for the same stuff?
For some workflows, it might be doable, for the whole package, what people use compiler frameworks for, CoreCLR still lacks many knobs.
project oberon, though in many ways related, is by wirth.
you were probably thinking of alef (the early csp language) on plan9 (the bell-labs' research unix successor).
limbo and its os/vm inferno were an attempt to commercialise those ideas amid the java craze.
So if we are being pedantic, Oberon-V,
https://www.research-collection.ethz.ch/bitstream/handle/20....
Inferno is Plan 9's successor, and Limbo embodies the ideas that Alef failed to deliver, replaced by a C based library instead.
Regardless if Inferno and Limbo were a way to fight against Java based OSes, they failed in the market.
thanks! i didn't know of this connection.
Rust is trying to solve the same problem of being both safe and as performant as C/C++. Although it came along later than D it seems to have been much more successful in gaining traction, most likely because it had the backing of Mozilla.
It might be the most comprehensive programming language ever.
EDIT: or any of mratsim sibling's fine choices. Nim is Choice and has many uncommon compile-time powers.
Alternatively you can use a `static:` code block to force compile time evaluation. Or tag a function {.compileTime.} or tag function inputs with `static` modifier.
It is possible to create a compiler or an assembler running fully in Nim macros as well:
- https://github.com/mratsim/constantine/blob/master/constanti... (all that file runs at compile-time)
You can also implement Continuation-Passing-Style transformation at compile-time: - https://github.com/nim-works/cps
Or a neural network DSL or for a self-contained example, einsum: - https://github.com/mratsim/Arraymancer/blob/master/src/array...
It's worth noting that nim async/await transformation is fully implemented as a library in macros.
Rust's sweet spot is on the OS layer, or bare metal workloads, where similarly to high integtry computing, no heap allocations are allowed, or only in very controlled scenarios.
Back in 2003 I loved the idea of D, even if I never used it. But then I also loved the idea of C++/CLR, so I would not put too much on my judgement. My opinion about D has changed far less: still have a soft spot for it, just not enough to make the jump
Rust hit 0.1 around the same time, and my attention ultimately turned to Rust when it hit 0.5, the version that cemented a concept of lifetime and borrow checker. The same thing happened for the same reason, that's the reason I built Chrono and other well-known libraries at the first place. But I think I sticked to Rust probably because it had a very crude but working package manager in the earliest release. (While it was initially named Cargo, it was renamed to rustpkg and then replaced with a new Cargo shortly before 1.0.) So I had some reason to continue working on my libraries, because people was actively looking for features provided in them while I haven't seen any such movement with D.
I still don't know whether Mozilla was crucial for observed differences between D and Rust. I do believe that Rust needed Mozilla to succeed, but that looks orthogonal to my anecdotes. My current guess is that Rust was the first major programming language that was entirely hosted by Github from the beginning. [2] That arguably made people much easier to search Rust libraries and collaborate on missing pieces. And that's probably what allowed Rust to evolve during multiple breaking changes before 1.0, and a timely introduction of the current Cargo also played a role. [3]
[1] Fun trivia: Some of my (in)famous Rust libraries are originated from those experiences!
[2] In comparison, Go switched from Google Code to Github in late 2014 (https://groups.google.com/g/golang-dev/c/sckirqOWepg/m/YmyT7...). D proudly hosted its own news group even back then I think.
[3] Of course it took a lot more time for Rust to become a language that can never go away. That point is generally thought to be an introduction of `async` in 2019, because I've been told multiple times that it was the last major requirement shared by many stakeholders.
Culture is first. If you have a safety culture, that supports and enhances safety technology, and the resulting software has better safety properties than you'd get even if your technology had been just as good without the culture. If you start with the technology instead a culture which isn't interested just undoes all your good work.
Look at C++ span. This is a slice type, roughly equivalent to Rust's [T]. As originally proposed it has good safety properties, its index operators are bounds checked and it provides safe but fast iteration. WG21 got hold of it, and std::span, the resulting standardized feature in C++ 20, doesn't have any bounds checks, destroying the safety properties. That's a product of a culture which doesn't value safety.
I always viewed D as a new language, which is kind of trying to offer the convenience of C# but as a native language. But sometimes I feel like it's drifting in a different direction. In a direction of nicer C++. I would prefer C/C++ support to be a thin abstraction layer for legacy code. But instead seems like there is more and more integration with C++.
Even language features in D like copy constructors are based on matching the behavior of C++. If I wanted to use C++, I would just use C++ instead of bothering with bridging C++/D code. I think that's one of the appealing things about languages likr Rust and Zig, is that they don't even try to appeal to C++ programmers. Let C++ programmers enjoy C++, but let everyone else move on.
Looking for a new maintainer post - https://github.com/gnunn1/tilix/issues/1700
Tilix is a great terminal which somehow balances ease of use whilst catering to power users as well. IMO that is.
Note: Not affliated to the project. Just love using Tilix.
https://dlang.org/articles/safed.html
But nothing like Ada SPARK provability stuff, I don't think.
well wish me luck for my university course, i've been reading a lot of programming language before coming to college and i thought i had everything prepared but turns out life can really throw a curveball at you
P.S if you have any guide on how i can approach this let me know :)
Thank you for this normal gpt like ver 3.5 or ver 4 (from bing) is really bad at coding with d so this Will help a lot
I am truly thankful and will continue to binge watch your vids
For the traffic D gets these days, it seems like hosting ti as static content on Netlify or somewhere would be viable for a low cost.
GC is particularly well-suited when using compile time function evaluation, which executed D code at compile time (i.e. adanced constant folding, where functions can be called).
Instead of calling it D, they should use a word to invoke some emotion, rebranding to "Destiny" would be a good start
Although, perhaps my decision to learn C# was a reaction to my desire to no longer be myopic…
The most important is search-ability (e.g. compare results when searching "c# gc" and "d gc"), but there are also subconscious impressions that you get from a name, whether you realize or not. For example, having an indistinct name makes your language feel indistinct.
I understand your C# comment was meant tongue-in-cheek but I think it shows how you're analyzing this rationally while marketing is dealing with irrational decisions that happen instantly at a subconscious and emotional level.
Marketing is important.
D and Go share this problem, but they also share the solution. You wanna search for "dlang gc".
C# was impossible to search for when it came out btw, and for a while after. That one was solved by search engines eventually rather than by the community.
I was lookg through the history of C on Wikipedia, then I somehow stumbled upon a table with all programming languages in the wiki.
Under the C language, I saw D lang. I first thought it was an old outdated language like B.
But when I looked up D lang, I saw they had a website up and running, I visited it and got quite shocked, the website was modern and had an impressive description.
Or is this an elaborate joke about how annoying it is/was to search for Rust game development topics on the web? (Because there's a game called "Rust" and a game called "Destiny" ... `is destiny better than rust for multiplayer games`)
It's a variant of C, even to the point of compiling C code. The downside to that is that C isn't exactly the hottest language among people under 50.
C,D,'E',F
Is there an E language? Maybe there is a rule that languages can only use consonants?
- Sublime Text
- vscode
- vim/nvim
- emacs
etc..
https://dlang.org/blog/2022/02/19/how-i-taught-the-d-program...