Hacker News Reader

You also need to take history into account

- 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)

Missteps are fine if it’s possible to make a compelling pitch to a pragmatist in pain. But was there ever such a pitch? Not that I recall.

Check the year when David announced D support in GCC - https://forum.dlang.org/post/c3mnst$2htg$1@digitaldaemon.com . So yes, you might be right about non-free compiler until 2004.

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?

I acknowledged that in my comment. My point is it takes a lot of work to undo the damage to people's perception and that time you lose from doing so gets your community that much further behind.

> GC - you can build entire application _without_ GC. Nobody forces you to do that.

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?

It is not necessary to opt-out of the GC. Just don't use it.

If the @nogc attribute is used, the compiler will tell you where the gc is used.

My hot take: when D intends to compete with C++, having an opt-out GC is a deadly disadvantage.

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 whole GC thing is a non-issue to a pragmatic programmer. D's GC is not going to pop out and smite your program. It's just one of many methods of dealing with memory that D provides.

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.

Btw. the "Chasm" idea is from the book "Crossing the Chasm: Marketing and Selling Disruptive Products to Mainstream Customers" by Geoffrey A. Moore

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.

D has a borrow checker, too.

For anybody interested: https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...

You really aren't the best language salesman on earth ;). And that's great!

You're right, I'm born to be a nerd, not a salesman.

Besides the "pragmatist in pain" route to mainstream there's also the "benefits for free" route.

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 supports function pointers and array pointers, and always has.

But not in a C-compatible way, right? IIRC, you can't just take a good size C file, put a tiny bit of D in it and compile it with the D compiler, can you? Happy to be corrected.

Yes, it's semantically C-compatible. They're close enough that converting C code to D code manually is straightforward. But it isn't necessary to do that, you can simply import C code into D code:

    // D code

    import mycstuff; // loads mycstuff.c
    int main() {
        int* p = mycfunction(); // call C function
        return *(p + 1);  // pointer arithmetic
    }

Translating small syntax differences like that are easy to do by machine if you have to.

>Rust was far from perfect when it started seeing adoption by pragmatists

Isn't Rust still a niche programming language? When compared to C, C++, C#, Javascript, Java, Python?

It certainly is and if alone because the corpus of all Rust software is minuscule compared to that of other mainstream languages.

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.

I think Rust will remain a niche language because its main benefits compared to its learning curve are high.

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.

Except Microsoft recently decided, even being a C++ powerhouse, that all Azure systems programming that would have been done in C++ in the past, will be done in Rust from now on.

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.

What learning curve? Between the borrow checker, copilot, and gpt it’s not really hard to know when to use &.

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.

Not everyone works in gpt and copilot. Not only using &, but annotating 'a and 'b and 'c all the call stack and when refactoring, redo it again.

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.

The problem is you're probably well above the median developer in terms of talent. Now imagine all the enterprise devs that do boring Java and C# and only got into software because of the pay not because of any passion for it, and imagine how easy it would be for them to learn Rust.

Lmao Ty I’ll put that on my resume if I ever apply for a dev job.

I have not yet tried copilot with Rust, but when GPT-4 came out I made many experiments with Rust, Python and Java to see what it can do.

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...

>I think Rust will remain a niche language because its main benefits compared to its learning curve are high.

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.

In Rust you have to annotate all lifetimes, when refactoring them, do it again all the way up and down the call stack.

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.

That's the thing. You still have to think about lifetimes when you refactor C++ code too. I have accidentally introduced segfaults refactoring my own C++ code, that is for certain.

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.

> That's the thing. You still have to think about lifetimes when you refactor C++ code too. I have accidentally introduced segfaults refactoring my own C++ code, that is for certain

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`.

This is a really good point and I agree that this is challenge for Rust. The counterpoint I have to offer is that the learning curve is reasonable flat when you are coming from C/C++ and that that is a significant enough target group to pull Rust trough until its new ideas become mainstream. I still remember when object oriented programming came around and that many programmers found it quite alien. A notion that is hardly conceivable today. I hope that it will be similar with Rust.

Why go through all the trouble when you can do this: https://www.hylo-lang.org/ and not spend a second thinking of lifetimes? No, copies will not be issued unless necessary.

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.

I think in the grand scheme of things, it probably is. But it seems to have a momentum behind it that I can't quite see in, say, D or F#. Rust's popularity ratings in Stack Overflow's annual survey are pretty impressive https://survey.stackoverflow.co/2023/#section-admired-and-de...

For JavaScript there's been a sharp increase in the amount of tooling that is written (or rewritten) in Rust: Turbopack, SWC, Vite's upcoming rewrite of roll-up. It doesn't seem like it is competing with JavaScript for writing web applications, but the tooling is definitely seeing more adoption of Rust.

In general Rust is great for writing developer tooling. You need low latency, high throughput, low memory footprint while being stable enough that it doesn’t crash much. Projects like Turbopack, Ruff (Python linter), Biome have all had some success and may continue to.

If you read about diffusion of innovation, there is the classical example that cure for scurvy was known way before being adopted: thttps://web.archive.org/web/20151022041843/http://www.idlewo...

A well written and absolutely gripping & interesting tale, also discussed here at the time (including by the blog author) https://news.ycombinator.com/item?id=1174912 and re-posted many times without as much ( https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... ).

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. }

[1] https://www.youtube.com/watch?v=1yCeFmn_e2c

> 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".

And introduces a straight jacket that avoids valid patterns from being used and makes binding C++ a hell.

Like I said, it doesn’t need to appeal to everyone to succeed, just a critical mass. Binding Rust to C++ isn’t easy, but the value proposition is strong enough that Firefox and Chromium (early days) projects use Rust in their massive C++ codebases.

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.

It can appeal niches with critical mass. Then it will not "mainstream". It will be something else.

I’m defining mainstream language as one that will continue to be actively developed 10 years from now, will have a thriving ecosystem of libraries and will be easy to hire developers for. If you have these three, you can start a new code base in that language today without worrying that you’ll be left with legacy software in a few years that’ll need to be rewritten.

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.

> I’m defining mainstream language as one that will continue to be actively developed 10 years from now.

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.

or you could simply be supported by a billion revenue company that pays your bill if you code "their custom version of C". No need to do social analytics. D could totally be that language but it was never driven by big enough companies and had a specific early years history which obscured it pretty well from pragmatists crowd.

> never driven by big enough companies

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.

Those days D2 was probably not ready to be adopted in prod anyway and Andrei worked as a research scientist on a specific problem so I don't think he was on "that" level of corporate influence. He then left FB to work fully on D.

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.

Andrei Alexandrescu went back to C++ and is working at NVidia CUDA nowadays.

He's the Vice President of the D Language Foundation, although he's not contributing as he used to.

It's safe to say his salary is high enough that Rob Pike would have done the same thing. Important to note that he left his D leadership position years before moving to NVidia and he's still involved with the language.

Facebook didn't hire a dozen people to develop the compiler and ecosystem.

> Many projects were written in D.

What's your source on this?

Internal document at Meta written to explain why Meta only officially supported 3 languages at the time for server side development - Hack, C++ and Python. Rust is supported as well now, bringing the total number to 4 (https://engineering.fb.com/2022/07/27/developer-tools/progra...). The post explained why D was used at one point, but the use was phased out.

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.

Hmm, yeah, I never saw any internal stuff (I'm just a random person on the internet), but my impression from public info is they had a few isolated individuals experiment with it on small projects but the company never formally adopted it or supported it for anything serious.

Rust is loved and has momentum. I'm not sure it's universally adopted by pragmatists, partly because it requires replacing pip, Maven, node, yum, or whatnot with cargo.

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.

No, you're mistaking the point about pragmatists. It's not necessary for every pragmatist to adopt it for every project in order to succeed, just a critical mass of them.

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.

D has been around for 20+ years now.

It has, but it wasn't adopted by the pragmatists in that time.

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.

>Meanwhile Rust managed to appeal to the pragmatists

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.