Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Why do you use Rust, when D is available?
147 points by crazypython 33 days ago | hide | past | favorite | 255 comments
D supports Ownership and Borrowing, just like Rust. DMD, D's reference compiler, can compile itself in less than 5 seconds, thanks to a fast frontend and fast backend. D is easy to metaprogram through traits and templates. You can make your own JIT in D with dynamicCompile.

I'd love to hear some reasons why so D and Rust can learn from each other.




Personally, at some point Rust was just clearly better and after a while - I lost interest in D. I don't have time to keep track of D catching up, when I'm so happy with Rust, and ecosystem is growing so fast. Maybe D got much better in last few years... but I kind of don't care anymore. It's hard enough to introduce a raising star like Rust to your coworkers and D just don't have traction anymore.

I've been following D since early 2000s. 2 decades. It took it a long time to get good: make it open source, make it community driven instead of one-man show, add some really important features and focus on important things (ownership, memory-safety), get the tools to be good.

It just missed the boat, and never really had a right niche for itself. It was kind Java/C++ mix, and it wasn't all that better to dethrone anyone in that space.

Rust swooped in and executed everything perfectly in a really short time. It's a C++-killer: same strengths, none of the weaknesses. Normal people don't want to touch C++ anymore. Only people that think that CVEs are "just fault of bad developers" (LOL) can still be considering C++ a good language to start new projects in. Industry really, really needed C-like language that was memory safe, and all-round good: both low and high level. And Rust quickly delivered that, borrowing all the great aspects of other languages and addressing a lot of problems.

D is great, and I like it far more than e.g. Go, but it was an ambitious project by one individual for a long time, while Go had a whole Google behind it. There's no shame that it didn't "took over the world". Rust would possibly not do so well if it wasn't for Mozilla support. The marketing, credibility and traction a big backing company like this gives a new language is probably the single bigger reason for different outcomes.


> It's a C++-killer: same strengths, none of the weaknesses

Not used Rust yet, used a lot of C++; isn't a weakness that it also is extremely slow in compiling? Not sure about others but to me that's a big weakness (if it still applies, but as far as I can find on Google it does).


From my experience building (not writing) relatively complex Rust applications like Alacritty, it's really not that bad. Building for release is definitely slower than C++, but development builds are almost always instant for me, as they're done incrementally.


Rust is much better at caching the intermediate results of compilation. First time compilation might take some time, recompilation will be faster though.


Most of the time, I let my IDE check the code with rls, rust-analyzer or cargo check which invokes the rust-compiler without doing the costly code generation part with LLVM, so it is usually fast enough checking huge projects while writing or at least when saving.


cargo doesn't do a terribly good job of caching dependencies.

Might be better than whatever C++ does though.


Currently C++ is still a better experience, because using binary dependencies is quite common, so you don't compile the whole world, rather just your own application.

Then most organizations have staging areas where you can share binaries across the company.

And the two package managers that have been growing community support, conan and vcpkg, support caching and distribution of binary dependencies.

No doubt cargo will eventually get something similar, it just isn't there today.


You can do this with a build script.


So goodbye declarative builds.


I thought I cared about declarativeness, turns out I don't.


Experience has taught me to always care about it, except when working on throw away hobby projects with teams of one, turns out not using it doesn't scale across organisations and makes for very unhappy DevOps teams.


Slow is relative. On my machine I can compile all of Chromium in ~15 minutes. I am one hugely impatient person when it comes to compile times, so I watch things closely.

But just like anything else given enough time, money and harddisk space anything is possible :)


I'm not sure what fast or slow is. I think on average I spend 1-10s compiling. Eg when I run my tests, or run a server. However that is during my normal workflow. Ie the thing I do 500x a day.

If I was to nuke my target directory _(the compile cache)_, it would take minutes. Not sure how many honestly, because when I do it, I rarely wait for it.

So the compiles are definitely slow, but for me it's only bad when dependencies are needing to be compiled. Which is rare.

If you don't cache your dependencies well, like in a poorly written CI pipeline, things will suck though. 20 minute builds at work (slow build machines) are common for us due to some poorly done caching.


> Rust would possibly not do so well if it wasn't for Mozilla support.

And especially Mozilla's intense passion for open-sourcing everything. I think it was a good catalyst to get it into the hands of as many people as possible.


> Normal people don't want to touch C++ anymore. Only people that think that CVEs are "just fault of bad developers" (LOL) can still be considering C++ a good language to start new projects in.

Deliberately inflammatory, and also false.

1. Rust has limited abstraction features to make it more approachable and implementable, but make it unable to express libraries that are easy in C++. This will not change soon, although Rust will accrete features at a steady rate. But the gap in feature sets will widen, not narrow with time.

2. The total number of people using Rust in production is easily less than the number who pick up C++ in any given week. It will be ten years before Rust is a mature industrial language, if it gets there. (It has made a good start in that direction, which is better than can be said for any other newish language.)

3. C++ and Rust will coexist for decades. The most ambitious work will continue to be done in C++, while Rust will be more than adequate for what might otherwise have been done in (the much less capable) C, Go, or Java.

4. D fizzled because it is too similar to C++, and therefore unnecessary. Rust found a ready audience in people intimidated by C++, frustrated with the limitations of C, Java, and Go, and ready to try something wholly new. Its designers have threaded the gap deftly, uniquely adopting C++'s greatest strength, the destructor (which it calls the "Drop trait"), and avoided weighing it down with garbage-collection. It has a bright future if it can multiply its adoption rate by two orders of magnitude.

As Stroustrup said, there are only two kinds of language: the ones people complain about, and the ones nobody uses.

With enough luck, by the time Rust is mature, it will have gained plenty to complain about. Rust will have got somewhere when you read more complaints about it than brags about having made it do something already done in a mature language.


I've been writing C++ professionally for 16 years. I'm doing it right now in fact, but snuck on to HN while a build is underway.

OP is right, unfortunately. C++ is a dying language. Mozilla, Microsoft and Google are all looking at Rust. Why? Because it's probably makes more sense to rewrite a buggy C++ component in Rust instead of updating it to use modern C++ (where admittedly, you have to go out of your way to get things wrong). The damage has been done.

I'm also concerned about our ability to hire in the future. C++ devs will either be too expensive, or just not there since it's not an attractive language any more.

I'm not a Rustafarian either, I've actually never used it but it would be negligent of me to not look at it. One concern I have with it is that the eco-system may be full of poor-quality ports of C/C++ libs, because that's how people work when they learn a new language.


C++ was a dying language in the 2000s. But they turned it around with C++11. Now it has iterative 3 yearly updates and it's getting pretty good.

It's far too premature to declare its death. The pace of development of C++ is decently fast and there's many stakeholders with millions of lines of C++ who are interested in C++ not dying. C++ is taught in universities around the world so the chance of C++ developers becoming expensive is low.


In fact, the number of C++ programmers is growing faster than ever. This is evident in the growing number and size of C++ conventions. (Bulgaria has its own, now.) Even ISO C++ Standard committee attendance is reliably a lot more than every previous meeting, even when held in inconvenient places. Attendance will hit 500 soon. The amount achieved at each meeting grows accordingly. Proposals get more scrutiny and draw on more experience.

To suggest C++ is a dying, slowing, or stagnant language is objectively delusional. The language is healthier than ever, and going gangbusters.


The C++ that they teach you in universities barely gets you started. I wouldn’t count on those for a steady supply.


The C++ they teach in universities is either just C, or putting Java spin on C (C-with-classes). I've never seen a decent "modern C++" class taught in universities.


Sure, but that's nothing a few years in the real world can't fix. The point is that C++ programmers are not some rare breed of neckbeard that are gradually going extinct. They are being produced en mass.


I love that Java spin on C remark, given that stuff like Turbo Vision, MFC, OWL, PowerPlant, Motif++, CORBA, COM, VCL, SOM, CSet++, POET precede Java for several years, some almost a decade.


While we see some adoption of Rust from Google and Microsoft, all their new releases are heavly focused on C++.

React Native, the new Games SDK for Android, WinUI 3.0 release, lifetime analysis support for Visual C++ and clang and lets not forget they are two major contributors to ISO C++.

While the Rust/WinRT efforts from Kenny Kerr are welcomed, that it is just yet another option alongside C#/WinRT, C++/WinRT, Python/WinRT and JavaScript/WinRT.


COBOL has been dying since the early 80s yet to this day more than 80% of all daily business transactions are processed in COBOL and 5 billion lines of new COBOL are written every year. If this is what a dying language looks like then yes, C++ is a dying language.

P.S. I'm not a COBOL programmer nor have I ever been a COBOL programmer.


The only language that one can honestly say that is dying (if not already dead) is VisualBasic. Perl and Delphi are probably going to continue to decline. Objective-C will be obsoleted by Swift some day, but is still relevant. Ruby's not too hot now, but far from dead AFAIK.

Other than that it's nonsense to say that X is dying.


C++ is being blamed for allowing people to write buggy, insecure programs. In my mind, that's different to just becoming unpopular; it's dying because it's too dangerous and too complicated.

Sure, it'll stick around for some years yet but all those jobs will become maintenance jobs. Very little greenfield projects will elect to use it outside of niche areas (games and maybe embedded - UK salaries for embedded dev are terrible). Both C++ and Rust can use LLVM, so the generated code is likely to be the same.

If you were starting a greenfield project today why would you choose to do it in C++?

I forgot to mention Go too.


In fact, essentially all new development in the highest-paid financial, HPC, CAE, telecomm, aerospace, and ML fields is pure C++. Rust is not a blip in any of them, and will not be for years to come. C is dead there (except in aerospace and telecomm), Go is nonexistent, and Java is mentioned on rare occasions.

To suggest C++ usage is in decline is, objectively, nothing short of delusional. For Rust, C++ will the one to beat in ten and twenty years, provided not too many have already skipped onto some new hotness.

Rust is an objectively better design than anything else that has arisen in 30+ years. That doesn't guarantee success.

I used to hope a better language would displace C++, and for a time thought Rust might be it, but that better language turned out to be C++ itself. Nothing else is even on the horizon.


I would choose C++ because the tooling is superb, talent is widely available, it is performant, there are libraries for pretty much everything, and it's a great language.

Oh and by the way, LLVM is 100% c++.

Saying it is too dangerous and complicated is absurd. It is easy to write safe code in C++, having been doing it for almost 30 years.

You are throwing around lots of assertions - challenge you to back them up with real data.


My company starts new programs in C++ because everyone knows C++ already, we write modern C++, our libraries are written in C++, and our bugs are mostly not memory safety issues.


The world runs on C/C++ code. And new C++ projects are started every single day.


I don't understand your claim that C++ is dying. Do you have data to back this up?


As a normal person learning and using C++ I'm sorry but I agree with him. If I weren't trying to get a job in the game industry I wouldn't touch it. I'm not a student either, I've been programming in multiple languages for over a decade.

The language is messy and filled with undefined behaviors and unsafe methods by default. Where there are rules you can mostly ignore them whenever you want. People complain about JavaScript being messy but C++ is way worse.

Though the language itself isn't all that bad, I don't understand why there so many build systems? And the top build system CMake isn't so much a build system as it is a build system for build systems that exists because no one can seem to agree on one.

Many of these systems seem bloated and over designed by comparison when I can install libraries or cross compile in one line in go. I couldn't help but think there had to be a better way and it seems like rust is that way. I expect C++ will eventually go the way of Cobol and eventually be used to maintain legacy systems.

p.s. thank God for vcpkg because I had nearly thrown in the towel while trying to integrate simple libraries until I discovered it.


1. Could you give a few examples of libraries that can’t be made in Rust due to lack of abstraction compared to C++? GUI libraries apart, I can’t think of anything offhand.

2. True, but growth curves are rarely linear. Here’s a rough proxy on users - the number of subscribers to /r/rust - https://subredditstats.com/r/Rust. Look at the growth between 2014-18 and 2018-2020. You’re extrapolating on current growth rate, but that may increase in future.

3. “Ambitious”. Nothing I’ve seen precludes using Rust for ambitious projects. In fact, seeing the experience of Dropbox, Mozilla, Facebook and others, there are some ambitious projects that could only have been done in Rust. I’m gonna say [citation needed].

I agree with Stroustrup and look forward to the day people complain about Rust :)


I am under the impression that Rust is lacking even the most basic level of dependent typing: being able to template over a value; pretty much every typesafe buffer library I have ever written uses this to make Random<32>() return not just "a buffer" but "a buffer of size 32", which makes doing parsing of various packet formats and combining sources of information a lot more reasonable. (I am also under the impression that the Rust people intend to fix this lacking, but until then I know I am going to feel a bit crippled.)


The basics are in nightly, but yes, not yet. We’ll get there.


1. Could you give a few examples of libraries that can’t be made in Rust due to lack of abstraction compared to C++?

I'm guessing, but I think that something like Armadillo[1] would not be possible on stable Rust. Something like Catch[2] might also difficult to make ergonomic.

I don't program in C++ anymore and I would personally live with the lack of expression/abstraction for a safer language though.

[1] http://arma.sourceforge.net/speed.html [2] https://github.com/catchorg/Catch2/blob/master/docs/tutorial...


Can you elaborate on why Catch would be impossible or unergonomic? It's a test framework, right? Why would one even use it instead of the normal rust test framework?

Also, how is it ergonomic? I'd agree if you say that it's (one of?) the best for C++, and it's also my go-to option, but ergonomic?


Why are they impossible in Rust? Are you aware of Rust's macros right?


Rust macros know nothing about types, but types are what do all the work at compile time.


Do they have to know about types?


Only to build designs that today are possible only in C++.

Type-aware macros might not be the best way to implement the features needed to match C++.


>Rust found a ready audience in people intimidated by C++, frustrated with the limitations of C, Java, and Go, and ready to try something wholly new.

What about people not intimidated by C++ and want to switch to Rust anyway? Why have you discounted them? Do such people exist in your world view? Do you think there might be a good reason for those people to choose Rust?


I read that the same way until I realized that it would be fair to say that even I'm "intimidated" by C++ despite having quite a bit of experience with it. It's not a matter of cleverness or experience. You can know something inside and out, and still admit that it's out of control and worry about the costs of its complexity.


If you are not intimidated by C++, you will be using those features that intimidate others to construct better libraries and programs than they can. Switching to Rust would mean a huge step down, where vast gaps in the feature set disable expressing what has been so easy.

There are kludgy workarounds for everything, more or less, but why switch to a limited language with immature tooling and practically nonexistent immediate prospects, when C++ demand is going up, up, and up?

Memory safety is just not an issue at the level where coders of modern C++ work. I have had exactly one lifetime error in five years, caught in initial testing. My bugs are overwhelmingly specification omissions and logic mistakes that Rust suffers from exactly as much.

My day-to-day experience is to write 2000 lines and, when it compiles, it works correctly, modulo a "!" short or extra. Then, I spend a few days refining the design, which often means deleting code. Things Rust promises to help with consume only trivial attention. Library features not expressible in Rust prevent many more and bigger problems.

Rust has some nice qualities I would rather C++ had--pattern match support, simple iterators, default const and default pass-by-move, sane conversions, sane initialization--but they are all low-level conveniences, not anything I am willing to trade away architectura-level capabilities for.


What architectural level capabilities?


Template partial specialization, function template overloading, variadic template argument lists, template operator overloading, generic lambdas, the list goes on and on and on. Look up any list of C++20 language features; most are not in Rust. Look up any list of Standard Library components; most are not expressible in Rust.

Rust is going interesting places, is taking full advantage of starting from scratch, and is miles ahead of C, Java, and Go on every axis. But if Rust could get to where C++ was in 2011 by 2025, that would be amazing. Meanwhile, C++ has already shipped C++14, C++17, and C++20, will have done C++23, and will be firming up C++26.

Assume Rust could match C++20, just five years later, in 2030, which would be more amazing. C++29 will be out.


Excellent explanation! Couldn't have said it better myself.


Thank you for putting it so aptly.

Unfortunately for many people technology is still an emotional rather than a professional topic.


I think the two go hand in hand. I get emotional over many a professional topic.


That's why we do tradeoff studies in systems engineering, to avoid that we take important decisions based on emotions or assumptions. Participants can still get emotional, but at least they have the facts and a process which converges to the optimum solution when followed.


> 3. C++ and Rust will coexist for decades.

Nah, I mean maybe in the way that Fortran coexist with C/C++ for decades, but it's not equal coexistence.

I would rather say that new languages arise, replaces old ones for most scenarios and in the cases where they can't, due to various reasons, they push the old language into zombie state like cobol.


You don't replace languages but program's, go into physic-space, fortran is alive an well, go into systems programming c is alive an well, go into business java is alive and well.

It's the same BS like NoSql will kill all R-D's.

You just don't invest millions just to rewrite programs that work's perfectly (and that's often the case with old battle-hardened software)


The reason that RDMSes aren't dead isn't that they have too much momentum to be displaced by NoSQL. The reason they're not dead is that they're a good data model for lots of applications, and their consistency semantics and tooling provide real boosts to developer productivity.


I think that NoSQL and SQL are so much different that they will equally coexist, in the same way that languages that are used for very different purposes like Java and Javascript can equally coexist. However, it is unlikely that we have 5 different equally popular languages for one specific domain (e.g. systems programming).


I know, but around 2009/10 every hipster programmer said RD's are a thing of the past..like C like Java etc...


I agree with you, so by zombie state I mean the languages are still being used, but for historic reasons (e.g. you don't want to rewrite), but no one really wants to start a new project in COBOL.


I got scared away by rust's syntax.

I feel that people can learn rust faster if they know c++ beforehand.

c++'s syntax is scary too. But there are different levels of c++. You don't need to use the scary part to make things work.


Disagree. Sure rust has a notable syntax tax (not what it used to be) but that's the easy part! It's the concepts and mindset that are the biggest hurdle in Rust. Going to C++ first won't help you there. If you already know it, great but Rust is a different language and you'll spend a lot time trying to transfer C++isms over until you realize writing effective Rust is not like writing effective C++ and you go through a process of unlearning. In my view, learning C++ for the purpose of learning Rust is massive waste of time.


> Rust is a different language and you'll spend a lot time trying to transfer C++isms over until you realize writing effective Rust is not like writing effective C++ and you go through a process of unlearning

Ding ding ding! However I do think that the combination of syntax with the brand new concepts just adds that extra layer of complexity. A similar thing is Optionals in Swift -- the syntax is so baked into the language that even if you really understand how optionals work, the syntactic sugar keeps piling up in different situations. (i.e., first the ? operator, then implicitly unwrapped optionals, then if lets, guards, guard lets...)


> I got scared away by rust’s syntax.

I’m curious about what you find scary about Rust’s syntax. I always found it to be a fairly natural extension of the syntax from C and other ALGOL-derived languages.

Its semantics, on the other hand, took quite a while to wrap my head around. I am reasonably productive in Rust these days, and I still sometimes can’t predict whether or not the compiler will allow something.


As a Rust newbie: macros, lifetimes, and (when I really first started), closures. All of that syntax just seemed so messy to me.

The borrowing model was actually my favorite part because it not only was interesting, but made sense! And the syntax was relatively clean :)


No, knowing C++ probably confuses you for a while, it has confused me.


> Industry really, really needed C-like language that was memory safe, and all-round good: both low and high level. And Rust quickly delivered that

Well, almost. I'm not sure I like unsafe FFI and other bits.

> Personally, at some point Rust was just clearly better and after a while - I lost interest in D. I don't have time to keep track of D catching up

Yup. Better to use Rust if it's the one introducing the features.


Support for unsafe constructs is almost critical to a languages success. There are certain things that just cannot be done safely, and any language that wants to be considered a systems language needs some method of providing that functionality. Usually native unsafe support is the cleanest way to go.


> Industry really, really needed C-like language that was memory safe, and all-round good: both low and high level. And Rust quickly delivered that, borrowing all the great aspects of other languages and addressing a lot of problems.

Industry has had Ada since 1983, Modula-2 since 1980, Object Pascal since 1990, and a couple of other ones, not counting all those Algol and PL/I variants that precede C for about 10 years.

Unfortunely the industry will only take security seriouly when security exploits are severly punishable by law.


I’m currently trying to get into robotics. But why does everyone want c++? Surely robots can be programmed in other languages.


Because the real world doesn't really match the expectations and statements of the HN community. It's really rare that I see here anything pragmatic regarding what programming languages to learn/use.

The community lives in a bubble and is out of touch with mainstream software development.


I'm a very senior engineer. I've had a strong desire to find a better alternative to C++ since the 90s when I was first exposed to it (I worked with it for about a decade, after a few years with C). Now, decades later, enough bandaids have been applied that it's somewhat tolerable. Congratulations...?

The industry has needed good alternatives for a long time. Finally, they're coming, and not nearly soon enough to suit me! :-)


I believe you're right about those alternatives not coming soon enough. If all things go right, by the time Rust will be (sort of) mainstream you'll be able to set up the "Rusty Grampas League" :-)


What are thoughts on D?


"pragmatic /praɡˈmatɪk/ adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations."

I consider Rust more pragmatic at this point. Perhaps it's because I code in C++ as my dayjob and have to deal with the consequences.

In theory, C++ is perfect given perfect developers. In practice, it's more sensible and realistic to write tricky, like multithreaded, code in Rust.

One rarely mentioned important factor: fear. It's much less scary to modify something written in Rust than in C++. Doubly so for less experienced developers.


I'd wager we actually have a lot of clever teenagers here at HN. Well-meaning, but has never worked in a team nor has any experience of what the market rewards.


Technically robotics isn't mainstream, Javascript/PHP/Java/C# are, at least in terms of developers. Now in terms of code deployed, C on the billions of embedded devices may be able to compete with servers?


A language is more than just a technology: it's an ecosystem of libraries, platform APIs, developer mindshare and experience, familiarity, legacy codebases, product support. Don't discount the weight of all of those auxiliary, human factors.

Rust, culturally, comes from the web. That's why it has the most traction in the web server/WASM space for now. It's starting to poke its head into Systems use-cases because of the sheer weight of its memory safety benefits there. Maybe in a few years it'll get some real use in the games industry (real industry; not just enthusiasts), though Unreal remains a bastion of C++ that isn't going anywhere anytime soon. But then there are some dark corners of C/C++'s territory that move even more slowly, and where the cultural shift will take a long time. I think to a great extent, embedded falls into that category.


Not really. While there is a growing set of web-based application for Rust, it's not like PHP, where the very purpose of the language is the web. Rust is a system language before it is a web language.

WASM as a target is actually a great indication that it's a system language -- performance is a primary consideration.


You're missing the point. The point is that Rust came from Mozilla. Its mind-share started with web people and is expanding from there. What I'm trying to get across is that those social forces can matter more for adoption than just the tech's appropriateness, considered in a vacuum.


In that case, it came from Mozilla for working on a web browser, with primary goals of security, building sandboxes & language runtimes (js), and replacing an application-level cross-platform C++ core.

Which is very different than "web people", which in my mind implies webdev -- html/css/js + API server/db/caching backend.

Which also further explains why WASM is so far along (sandbox, security), much better than any association with webdev itself; but not kernel-level system development. (But if the web browser is an userspace OS... then it's probably not that far from it)


Off course it's a system language, there are even some that try to build an OS in Rust

https://www.redox-os.org/


Everyone is targeting WASM nowadays.


> But why does everyone want c++?

Few "want" C++, but for robotics a non garbage-collected language is necessary so latency is predictable. There are few mature languages besides C/C++ in that category.

Rust is an improvement, but I'm hopeful something like Julia (Julia Robotics, https://juliarobotics.org/) or Scala Native (https://scala-native.readthedocs.io/en/v0.3.9-docs/) becomes mainstream, the productivity gains would be substantial.


Garbage-collected languages can have (and some have had) latency-predictable GCs. It's not entirely an either/or, it's something of a false dichotomy. "Non-garbage collecting" languages blur the line anyway because even basic things like reference-counting are still a garbage collection technique. The trade-offs are in how many control knobs and where those knobs are/how you turn them, and a lot of developers still seem to feel much more "comfortable" manually writing all the knobs by hand than trusting a more algorithmic GC's shiny chrome knobs on the outside of (what they presume to be) a black box.

But perceived "comfort" isn't entirely reality. (The comfort of smart GC languages is immense in a different way.)


Something of a false dichotomy - perhaps. The fact is that allocating at all during realtime operation is frowned upon. Given that the best approach is pre-allocation and then turning off the GC, why carry the overhead of the GC at all?

For 99% of realtime work, the Rust or Scala Native approach is just fine. No GC required. Julia users can just use the pre-allocation approach.

The important thing is avoiding language patterns that encourage needless allocation.


> Given that the best approach is pre-allocation

GC languages still support stack allocation, you don't have to pre-allocate anything you can stack allocate. (That's where .NET Core has been especially burning rubber in recent releases. Span<T> is a stack allocated, GC-safe "pointer", for instance, that is doing all sorts of heavy lifting in .NET Core performance-critical work these days. It's still early too, as not everything has moved to Span<T> that can move to Span<T> and family.)

But also, not everything needs to be pre-allocated for the "best approach". There's some work to get used to the feel of any specific GC, but most modern "VM" GCs (.NET and today's Java, not yesterday's) are multi-generational and there's a lot you can do in strategies such as "focus on the nursery and the LOH" (using only [potentially many] small short-lived objects and a few, mostly stable "very large" objects, avoiding the intermediate generations).

> why carry the overhead of the GC at all?

Safety. (Why wear seatbelts?) Rust's borrow checker is great but it still requires a lot of manual adjustment and it's still possible to miss something (it's not easy, certainly, but it is possible); a GC gives you safety by default, with no manual intervention required to guarantee safety, and requires manual effort to write unsafe code.

> The important thing is avoiding language patterns that encourage needless allocation.

That's where we agree and why I'm very adamant that though some of the tools ("knobs") look scarily different in performance optimization for GC versus non-GC languages, the vast majority of the tools are the same: know the O(memory) of your algorithms, and make smart trade-offs regarding that O(memory), avoid allocating what you don't need, know your trade-offs between pre-allocation and allocation only when necessary, etc.


> it's still possible to miss something

Could you elaborate?


Tbf, I've not directly worked in Rust so my understanding is mostly academic of a sort. The issues I'm directly aware of are primarily in boundary conditions between unsafe and borrow-checked code, which isn't entirely fair to Rust as GC-languages of course have the same boundary conditions. My impression however is that because the borrow checker is a lot of work, there's a lot more Rust libraries in the wild with unsafe code sections than strictly need to be (as compared to similar libraries in GC-languages, and especially with modern tools like Span<T> in .NET nearly shrinking GC-unsafe blocks to non-existent in modern code).


PTC and Aicas sell real time Java implementations for robotics, among other similar deployment scenarios, lack of customers is something that they don't suffer from.


For some reason Python seems to be very popular in academic robotics right now. Not a great choice


Being a "better, stronger, faster" Python is fairly near Julia's sweet spot... :-)


> Not a great choice

It is a great choice to prototype the ideas


As a datapoint/anecdote, I work in an autonomous vehicle company and we have adopted Rust extensively in our codebase in the last six months or so.

Previously, the code base was primarily Python with some C++. Now there is a significant chunk of code, particularly related to safety, written in Rust.


That's interesting. But did your company consider using D? if so, why did chose Rust?


Rust is very very new compared to Cpp. People have decades of experience with cpp, learned in in University. Why would you throw all of that overboard just to learn a fancy new language with a weird ownership system? Keep in mind that people often still write cpp98 and have a rely hard time getting used to newer cpp concepts and programming styles. And all of that is backwards compatible with their existing codebase.


> Why would you throw all of that overboard

Firstly, because 75% of all that knowledge is easily transferrable.

Secondly, because you want to take 50% of your bug count.


He was saying this in the context of "why do people still use C++ at all".


But why not program in Python and take 100% of your bug count?


It is slow.

It doesn’t work well for embedded programming.

It very much does not fix all bugs, especially given lack of static type checking.


It will sound harsh, but people who can't up their game from C++98 to C++11, are probably not a people that I would consider hiring anyway. Generally, personally I would not hire anyone that knows just one programming language that they've learned in University and for years didn't manage to practice anything else, but that's just me.

I actually worked in Automotive, and the software higher level up the stack there is usually god damn awful piece of s*, often done by people who have almost no clue what they are doing, with plenty of misconceptions about how C/C++ even really works (using `volatile` for concurrency/atomicity and stuff like that). They are just beating their spaghetti code from segfault to segfault for decades.

This and slow delivery process easily explains why entertainment, navigation and other software-driven part of mainstream cars are so buggy, slow and generally terrible, and why Tesla could have so easily deliver way better experience.

So it doesn't matter that some people can't "get into Rust". The business that hire them will be replaced if they can't up their game, that's all.


If D have had a proper tooling, like C# and VS, do you think companies in the automative would consider to use D instead of C++?


Probably the same reason Python is big in scientific computing. A lot of stuff has already been written for it. If scientists needed to bootstrap scientific computing from scratch, Python wouldn’t be any more established than Rust, Java, PHP, or VB6.


Afaik pythons success in that field is relatively recent, only really taking of ~2010. The language was already 20 years old by then. Compare that to rusts first stable release in 2015.

Building ecosystem just takes time.


Python is easy to just start writing then the network effect made others use it


Check out https://www.ros.org - it allows you to program in either C++ or Python (with some other languages being supported by the community)


The problem is that whIle C++ has problems, all languages have problems and C++ has the most going for it in terms of being fast and easy to write.

C++11 is a really good language. Also there are tons of libraries and things people have already built in it that you can leverage to reduce development time.


Really? I find that rust is worse than C++ thanks to clang

For example, is there a way in rust to get a runtime error when there's an int overflow?


Of course. rustc has the "-C overflow-checks" flag. Cargo turns it on by default for debug builds. To turn it on for release builds, just put "overflow-checks = true" in the [profile.release] section of your Cargo.toml.

Or better yet, the Rust standard library exposes all the relevant LLVM intrinsics for the primitives, so you have the {Integer}::checked_, {Integer}::saturating_, {Integer}::wrapping_, {Integer}::overflowing_ (inlined) functions to do all your integer math in an error-free fashion.


Yes there is. Overflow panics by default in debug mode, and you can turn that in in release mode with the overflow-checks compiler option. There's also checked_add.


Normal people? Exactly what is a normal person there, Einstein.


Are you saying AAA-game/kernel/embedded developers are not normal? Pretty uncalled for if you ask me.


Depends on how you define normal. :D I offended a lot of C++ fans, I guess.

I guess what I meant is "vast-majority of devs out there".

I did ~10 years of kernel/embedded myself. Generally people use C++ only when they really have to (like: they work in one of this niches, or want to get a job there). I've experienced myself many times when people would go with anything but C++ because of all it's faults, weaknesses and general infamy. And I also have seen some people that gave Rust a try and it went smoothly. They deliver a proper C++-level performance and resource control, without any of the problems and were happy about the experience.

AAA-game/kernel/embedded are all lucrative (except games, lol), important and not tiny but they are still niche.


How aren't games so lucrative? did you any of your guys did try D before rust?


First mover. For a long time D targeted the same abstraction level as Go, and most of its libraries were designed with that in mind. Stuff like no_std was never a major goal for most supposed "systems languages" (that are not C/C++) until Rust came along. D was too slow in gaining momentum, getting corporate sponsorship, and adding new features that pushed the boundaries of what a systems programming language was capable of. Go had first class tooling, D felt like a C++ with a Garbage Collector. It reminds me a lot of Ocaml which also had a lot of great ideas and occasionally showed up in the engineering blog of a major corporation but if you look closely then you would notice severe issues with package management and multithreading (both of which are finally getting attention and being fixed, 5 years too late). There are a lot of boring engineering that goes into making a good programming language ecosystem that many smaller languages do not have either the willpower or resources in tackling.

This is not criticism of the D language, programming languages are like startups, success often has little to do with the product itself but more the ecosystem, funding, and luck.


> Go had first class tooling

Eh, I would describe go's tooling as "minimalist" or, less charitably, as "barely adequate." Pre-modules the global GOPATH approach was hacky and ugly, and post-modules the go command is a mess of contradictions straining against the backwards compatibility guarantee. And editor integration back in the day wasn't much more than running go fmt and go build.


Arguably that's one of the things that made it easy to pick up. I remember tons of JavaScript programmers who were suddenly systems programmers when it came out.


I know most people won't like this answer but the reason why rust is more popular now is because it had klabnik-san, mozilla, cargo and the super excited community.

The same goes for go-lang. It throws away years of research into programming languages. While rust is a great language and deserve the popularity, do you think go would have peaked in popularity if there weren't rob-pike-san and google behind it.

It's not a matter of features for programming languages popularity. It's who is backing them and doing the work to unite the community.

Programming communities also need to be aggressively cultish to take off in the beginning. You must be able to bite everyone's same repeated rehashed argument about lacking ecosystem, bad tooling and so on. You must be able to survive that and still shill the language.

It's reality. Everyone will tell you I don't care about your language when I can use my favourite language. People have invested more money than one can imagine into fixing php, js etc.

You can't easily get someone to switch from their single threaded language when they can scale it through AWS lambdas or other layers of abstractions.

This is why you don't see wide use of ML. All those communities are passive. They write their tutorials and papers in pure html on a weird forgettable domain name. They don't tell people to use the language because they are conscious of the lacking ecosystem but how would you get a good ecosystem without someone adopting it? OSS doesn't pay enough. Tooling require money. They don't focus on marketing or sponsorship.

Same applies for dlang.


Case study: awk. Brian Kernighan, who (co-)wrote the book on C, designed (with two others) another language, awk. Same organization (Bell Labs) pushing it as pushed C. C ate the world. awk... um... was available on all Unix installations, and got used for some things.

Sure, there are people who rave about how great awk is. I've read them here on HN. When you've got the right kind of problem, it's a great tool. But there are very few people for whom it is their main everyday language.

My point: Author/designer and organization can only take a language so far. At some point, the actual usefulness of the language determines how much it is actually used.


So you're saying Awk isn't "actually useful" which is why it's hardly used?! It's an entirely different kind of tool to C. Or rather, C is a programming language, Awk is a tool. To "get used for some things" is what it's for. Sounds like you're talking more about what purpose things are used for than how much they're actually used. And Awk seems a failure to you because it's used for Awk-problems rather than C-problems? I don't understand your negativity. Awk was and is wildly successful.


> So you're saying Awk isn't "actually useful" which is why it's hardly used?!

I deny you the right to put words in my mouth. That is not remotely what I am saying.


Hi. Well, that's very dramatic language. I was asking if that's what you're saying...because that's what it seemed to me like you're saying, but it seemed strange. Isn't that just what I should've done? Then "I deny you the right to put words in my mouth."! Hopefully you don't often say that in conversation when people ask you what you meant. So, if by

> C ate the world. awk... um... ... got used for some things.

> the actual usefulness of the language determines how much it is actually used.

you didn't mean something like

> Awk isn't "actually useful" which is why it's hardly used

then what did you mean? What are you saying? Because it really seems to me like that's the impression you meant to convey.


I reply that way when someone asks if I mean X, when X is very far from what I mean to convey. Often it's done dishonestly. That is, someone asks if I mean X as an argumentative gambit, rather than because they are genuinely trying to understand my position.

It sounds like you are genuinely trying to understand, so my response may have been inappropriate. I apologize.

To me, it seems that awk is less used than C. As I said, "C ate the world" - it became an incredibly dominant language. If you believe the TIOBE index, C is currently (June 2020) the most popular language in the world. By comparison, awk is somewhere in the 51-100 range. So, yes, by comparison to C, awk is not used nearly as much.

My larger point was this: C and awk both came from Bell Labs, both had famous people from that group involved in their creation, and both got distributed with Unix. And yet C saw (and sees) much wider use. This disproves the thesis that a language's popularity is a function only of famous people and organizational support. If those were the only factors, awk should be used as much as C, but it isn't.

Why isn't awk used as much as C? Because C is useful for a wider range of things. You don't write embedded systems or operating systems in awk. awk is still quite useful. What it does, it does well. But it's less useful than C (when you consider the entire universe of programming tasks, it's useful for fewer of them), and therefore it is used less.

My overall point: Fitness to the task matters for programming language use. Programmers are not just lemmings, led around by the nose to pick languages based on the fame of the author and the organization supporting the language. They actually pay some attention to whether the language is good for writing the kind of program they're trying to write. Languages that are good for writing a wider range of programs get used more than languages that are good for writing a narrower range of programs. That doesn't make the narrower languages bad or useless. It just means they will mostly be used on a smaller range of tasks.


Thank you.


> do you think go would have peaked in popularity if there weren't rob-pike-san and google behind it.

This is dismissing the fact that Go is the way it is because of Pike, Griesemer and Thompson and their common design process. You have to go out of your way to not appreciate the inherent simplicity and readability of the language and its minimalist, orthogonal features.

But I agree with you on the general sentiment, that a new language needs a lot of convincing. Rightfully so.


I'm pretty sure I agree with everything you said but I don't see it as a bad thing. PR/marketing (for lack of a better term) might be outside of a language initially but those efforts lead to things like making cargo really good—and it is.

I think it's good for thought leaders to rally people around new ecosystems: excitement breeds innovation. I don't think programming languages need to move to the scientific method and double-blind testing.

That said, you never outright said that it's bad. I'm inferring that from your choice of words.


As far as I know, D does not have ADTs (algebraic data types, a.k.a. tagged unions, a.k.a. Rust enums). I see that it has "enums" and "unions", but neither of these appear to be ADTs if I'm reading them correctly.

And Rust's borrow checker can give very strong guarantees that aren't present in any other mainstream language that I'm aware of. In Rust, you can pass mutable references to large data structures between threads, without copying or GC or any type of runtime checking (e.g. Mutexes), and the borrow checker will guarantee that you can't have a data race (data race = concurrent read & write). In comparison, I believe that in Haskell you'd do this with GC, in Java you'd do it with GC and a mutex, and in C you'd do it very carefully.

As another example, in Java if you modify an ArrayList while iterating over it, you'll get a ConcurrentModificationException. In Rust, you can't. The borrow checker won't let your program compile.

The cost of this borrow checker is huge: every reference in every program needs to be annotation with whether it's shared or mutable, and you often need to splatter confusing lifetime annotations all over the place. It adds a big learning curve to the language.

I don't know the details of D's ownership system, but it's not like Rust's borrow checker. Does someone who does know more want to describe it? I've just seen the language reference page here, that describes "scope" and "returns". https://dlang.org/spec/memory-safe-d.html


D's borrow checker is only semi-documented/WIP at the moment.

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

Basically D just needs that big break to actually get things done. There are some absolutely brilliant people working on D but there's only so much sweat people will donate (some people are paid but I imagine rust probably has upwards of a hundred full time staff given that Mozilla and Microsoft use it in an official capacity)


D does have smart people working on it, but like you said, maybe not enough. Walter Bright, creator of D, single-handedly created the first C++ compiler that compiled directly to machine code. Andrei Alexandrescu was on the C++ committee.


Yes it is very much still a WIP, what is currently implemented, how it is implemented and the fact it is already in the compiler (without a switch) is rather disappointing. Unless the implementation drastically changes, the outlook for the feature is not good at all.


Also D has a gcc backend.

Which is nice but it's still missing some of Rust's features.


Its more than that. D is part of GCC - The GNU Compiler Collection. Meaning that if you use linux and have recent GCC you already have D compiler.


Don't know anyone that uses the D GCC compiler, it is still playing catch up. The frequency of new D releases with intended and unintended breaking changes, usually source only ever compiles for a very narrow range of versions of D. What people usually focus on is the latest, unless there is a new bug that prevents them from using the newest version.


> The cost of this borrow checker is huge: every reference in every program needs to be annotation with whether it's shared or mutable

No. You need to "annotate" a mutable binding since bindings are immutable by default. But that also means that immutable bindings (ie the vast majority) does not to be "annotated". And even when you do need to, you literally just add the keyword `mut` as in `let mut foo = 42;`.

> and you often need to splatter confusing lifetime annotations all over the place. It adds a big learning curve to the language.

Again an extreme exaggeration. There are a few cases here and there where you need lifetime annotations, but most often the compiler simply infers them for you, allowing you to elide them completely. Specifically, you only need to do it yourself when it's ambiguous from which input(s) the output is derived.


Totally agree. I should have said "add sufficient annotations to distinguish shared references from mutable references", and "occassionally need to splatter confusing lifetime annotations all over the place".

EDIT: What's really relevant is that you can look at a Rust type, and tell whether it's shared, mutable, or owned; this is what Rust's borrow checker derives its power from. Likewise, Haskell's type system derives its (equally amazing) powers from the fact that you can look at a Haskell function's type signature, and tell what kinds of side effects it has. (Sometimes people think that Haskell functions don't have side effects in the sense that they never mutate anything. This is wrong; Haskell has mutable arrays in its standard library. Rather, it's that all side effects are reflected in a function's type signature.) https://hackage.haskell.org/package/array-0.5.4.0/docs/Data-...

I write Rust code for work, and we have a large codebase. We manage it pretty well, but there are definitely still innocuous looking changes that require adding lifetime annotations all over the place to avoid confusing error messages.

Rust is my favorite language by far (I get the impression you like it too and are defending it). I think the costs of its borrow checker are worth it, but they are significant costs.


D implementation of algebraic type is in the library. https://dlang.org/phobos/std_variant.html#.Algebraic

I have not utilized tagged unions outside this type so I'm not one to comment on any deficiency.


I remember how about 5 years ago I researched what new language to take on. I was in an unusual position to not consider job availability since I planned for a long game and was primary interested in growing my basic coding skills. It narrowed down to D, Go, Nim and Rust.

Rust won on paper based on C-like performance without GC and being not OOP-oriented in a Java way (I tried Java earlier and wondered who in his right mind would want to write that). But what convinced me was excellent basic documentation (the Book), concise and well documented standard library and nice FP-inspired idioms which I had no previous experience with.

I passed on Go due to GC and the fact that while I could probably learn the ropes quickly, there was not much I saw the language could teach me (I may be wrong here but such was an impression). Main accent was on speedy development in teams and it was orthogonal to my needs.

Nim (still Nimrod at the time) was intriguing but too fresh and lacking on documentation. It's much more intriguing now with gc:arc, move semantics and overall general momentum. I keep my eye on it.

D was the one I couldn't really find a place for. It was promising less, there was no killer feature that set it apart. To me it looked like more friendly C++ but with GC. I saw no real advantages.

I tend to think time proved my analysis to be mostly on point. At the time tooling and library ecosystem was rather poor for all four. Today even if featurewise D looks much more interesting, it needs to deliver on well-libraries to be competitive (I have no idea on its current situation on that front).

Sorry for such a long personal anecdote.


>Go [...] there was not much I saw the language could teach me

Interesting that you mention this; one of the reasons I really enjoy Rust is because of how it forces me to think through things more clearly, and how a number of the higher-quality crates teach more advanced approaches in a straightforward way.


I am a Python programmer first and foremost (data science-y stuff), but lately I've started reading the Rust documentation. First and foremost its really an enjoyable read. I also learn alot from it, and become a better programmer in general. I will try to write a library that I will use for my PhD, in Rust. I think it will teach me a lot about programming, be enjoyable and also give me a great library for string parsing and decryption.


A mix of misteps by D, and some unique advantages of rust.

* Releasing D under a closed source license was a non-starter. This has killed every language that has tried in the past 30 years.

* Garbage collection was really the only memory management until recently. Manual memory management has always felt clunky and tacked on. Ownership and borrowing came really late to the game in comparison with rust.

* Rust embraced all of the best parts of ML, like algebraic data types and pattern matching and strong static typing, but combined them in a package that made for extremely fast software with low resource utilization and static memory management. They combined it with hygienic fully typed macros. They added type classes, securing the majority of the benefits of OOP while still maintaining a functional style.

Whereas Rust has taken influence from a broad range of PL research, functional programming concepts, high assurance concepts, etc., and applied them to system programming, D has always just felt like C++ with garbage collection.

The one area where I think D still has an advantage over rust is GUI development. Functional programming advocates make lots of platitudes of functional reactive programming, and there are no shortage of toy examples for it, but when it comes down to industrial use, OOP still rules the roost. And while Rust gets most of the benefits of OOP, they still don't have anything approximating inheritance, which just works too well for GUI development to give up on. Maybe Rust will address that in the future, but it's not there at the moment.


Java, C#, Visual Basic and JavaScript all are less than 30 years old and all started off with proprietary main implementations. The phenomenon is probably real, but it's more recent than you suggest.


I can't remember one that's more recent than 20. All these languages were introduced before open source became the clear winner it is now.


Phobos/Tango. GC, then optional-GC. Compiler support for various platforms was wonky, never sure if I was using the right one.

D as of now is a worthy competitor to Rust, it wasn't always the case, it was more like Go, with the GC. I hit some snags and moved on and didn't go back. I am sticking with Rust.

I think a question with closer alignment is, "Why use Go when D is available" ? D feels like a 5x better Go, not a Rust competitor.


The biggest reason I started switching everything to Go is because of the IO / threading model.


Why did go took off then?


Go used one of the oldest sales tricks since day one. You sell all your shortcomings as merits. My imagination for fun:

* We don't have templates. Hm. Let's bad mouth them. Let's say templates are too difficult. Agreed.

* We don't have exceptions. Hm. Let's bad mouth them as well. Agreed. That one is easy.

* We don't have much abstractions. Hm. Let's convince new college graduates that they can't handle abstractions anyway. Mwahaha. But waait! New college graduates are actually smarter than us. I know... But we will convince them that they are not. Mwahaha.

There is more but I think I've just earned enough down votes with that much already. :)

But there is one sales sentence I will never forget. Go people said "No major systems language has emerged in over a decade"[1] As a person who was very much into D at that time (and I still am), and as a person who knows how "major" D is, that sentence from the Go people make me see them as either ignorant of the programming language scene or deceitful. Cheap sales tactic at best...

Disclaimer: I used Go professionally for 1 year for a product in the microservices space in 2017-2018. The only thing Go had going for it was the libraries that were already written at least for that space. Whatever we needed was already written for us; we had to wait at most 2 weeks for something that we needed to pop up. There was nothing else in the language that made me want to write in Go.

[1] https://web.archive.org/web/20091114043443/http://golang.org...


It's impossible to measure how much impact just having Rob Pike and Google behind Go has had on its adoption.


Google and Pike get you in the door. Goroutines get you to sit down. The onboarding-oriented nature of the language and ecosystem convince you to sign.


What Go did for the tooling space cannot be underestimated, it is wonderful and we will never go back to the before time.


What providing a formatter like indent has provided for decades?

Selling a Turbo Pascal/Modula-2 like compilation speed from MS-DOS days as novelty?

Or was using IDE code refactoring tools as UNIX CLI?


You're saying "it's impossible to measure", but it sounds like you have an assumption about the answer...


Do you really care about that or is that just ye olde "the lemmings use Go" bit?


For a bunch of reasons, but one of the most important was it had Google's backing.


Google being involved is mixed blessing, but having financial support to see it prosper is not unreasonable to appreciate.


Tango hasn't been in use for I think a decade now.


Engineers learn languages because of success stories by other companies—not by the merits of the syntax or one-off tricks like compiling itself in 5 seconds.

The fact that Firefox uses Rust for the browser engine or that Dropbox uses Rust for the sync engine is the kind of thing that gets me interested.


Corporate sponsorship is the new prereq for a successful language/framework in today's world. It didn't used to be that way but it is now. Bring on our new googlemozillaapplefacebookmicrosoft language/framework overlords.


I dont think this is new. C and C++ came from Bell Labs, for example. Cobol from the USA government, FORTRAN from IBM. Java from sun, javascript from netscape.

In general, they all had a big institution. I presume these provided a a few ingredients, like

* A strong urge to solve a real-world problem

* A cradle, where smart people had time and resources to build a basic core

* A broadcast platform as others would look up to the institution, and notice what they were doing

From the top of my head, perl and python don't fit in this pattern, so its not universal, but I would dare to call it common.


That's a dangerously general statement, and it does not apply to me (an engineer) for example. I learned a lot of languages because of the language itself, e.g. their type system.


Perhaps. But general as it is this explains what OP was asking: Why Rust is more popular when D has the same functionality.

There's always people that are fascinated by new languages but I feel this is likely a minority. I think people want to learn languages they know will be useful.


It may be dangerous to blindly trust that a language is good based on a company's success with that language, but a large company deciding to heavily invest resources and take a risk on a language is also evidence that the language has the designs to succeed.


That's based on the company, tech...yes, insurance..probably no ;)


I think you have to be updated. Rust has had success in countless places after Firefox/Dropbox.

With that being said fast compilation times are amazing and must be a default in new languages. If not they should follow an approach like Dart where there is a VM for development and also a AOT compilation support for producing binaries.


There’s ongoing work for a fast debug back end called Cranelift. It emits code 20-50% faster than LLVM while being less optimised.

Explained further here - https://jason-williams.co.uk/a-possible-new-backend-for-rust


Yes, I have read about this. I follow Rust very closely. This is a good trade off while developing for speed.


D has a fast backend that omits assembly- it's DMD.


I didn't imply in the slightest those are the only success stories


Compiling extremely quickly will change your development experience to be like using a scripting language. As far as I know, D can still compile itself- and the entire standard library- in less than 5 seconds, with parallelism turned off.


I've never heard of a commercial success built off the back of Racket or J but happily went through a book on Racket and would love to do the same for J.


And yet almost nobody uses Racket and J. I think they were talking about more wide-spread use.


Many schools around the world use Racket.

The financial industry makes heavy use of K, which is closely related to J. It's not open source or free to use for commercial use, however.


Uhh, that is quite wrong, lots of company's use racket, Haskell and even start new projects with Ocaml



Thank you! I just bookmarked it.


Are you implying that D is slow at compiling regular code but fast at compiling itself, because of some cleverness?

Is that actually true?


Lol, the person you're replying to never said, nor implied that.

I'm not trying to knock you, but your comment reminds me of the type of exchanges where one person says says "men do a lot of work", and the other person replies "are you saying women are lazy?"


> one-off tricks like compiling itself in 5 seconds.

I took that as saying D could compile itself in 5 seconds too. I was impressed. Bubble bursted.


I'm pretty sure that was a knock at go


I'm not saying that at all. But looking at a feature matrix or hearing from a fan what the great parts of a language are isn't enough to convince me to adopt it.

If it's been around for 2 decades and hardly has any adoption by large companies[0] I personally am not willing to learn it (unless that changes).

I'm not necessarily using adoption as a proxy for quality either. If there isn't any meaningful adoption it's not like I can join a company to write it or have an easy time convincing my manager to try it. It could be the greatest language on earth but if I can't write it then it doesn't matter.

[0]: https://dlang.org/orgs-using-d.html


The syntax is nicer.

Granted, I'm not very familiar with D. I didn't even know it had a borrow checker.

Rust took a lot of great features from Haskell, while keeping itself reasonably approachable from a C/C++/D/Java programmer's perspective.

Rust put type names after variable/function/parameter names, which really cleans up the syntax nicely.

Rust has very nice syntax for pattern matching, monads, and a slew of other really helpful functional language features.

Even if rust didn't have a borrow checker, it would still be a wonderful systems programming language.


One of the reasons why I haven't approached Rust is its syntax. Subjectively ugly and polluted with punctuation symbols that tell you little about their semantics. D looks cleaner and more readable even for a person not familiar with the language. D's readability is on par with scripting languages. Rust is far away from that.

Type names after variable or before? When you think about declaring a variable, do you think about its type of name first? I can't imagine you do the latter because "Hmm, I need an array of doubles to represent my tensor" is double[][] tensor; and not tensor: double[][]. Besides the types after names end up being more verbose in the languages which adopt the scheme (hello Scala).

I invite you to get familiar with D syntax to see a wider picture.

The borrow checker in D is WIP and given how much stir it created, I don't see it's happening any time soon.


For reading code, which arguably should happen more often than writing code, having the variable name first makes it easier to find, since it's right near the beginning of the line and it's a single word. If the type comes first, I have to scan the line to figure out where the type ends and the variable name begins.

Also, having "let" at the beginning of the line makes it immediately clear that it's a variable definition, whereas if it starts with some arbitrary type I haven't seen before I have to spend more time figuring out what's happening. Good syntax highlighting helps, but I think starting with types like C/C++/D is less elegant than starting off with a keyword that clearly identifies what the line does.

Similar applies for function definitions. It's nice when the function names are all lined up and not buried halfway across the screen because it has some long return type.


Subjectively, I see no point in having "val", "var", "let", "def", "fn" symbols which bring only noise to code. Why would you want to explicitly tell that something is a value while all you need to do is write its type and name?

double[] arr;

bam! Simple and clear.

What about functions? It has input, name and output and D nicely presents you with

double[] createArray(int size) {...}

This is as little typing as you can get while keeping readability.

And here is a basic Rust function

fn add_one(x: i32) -> i32 {...}

What kind of type is i32 btw? oh, there is u32 as well. integer 32bit and unsigned 32bit? What on earth are these? Ah, this is just D's size_t, the same size_t as in C/C++. So that C/C++ ppl have zero overhead reading D code and for Rust they will google. To top that, you have also -> because of the type after the definition scheme. Needless verbosity, same thing in Scala.

What about Rust unable to drop parenthesis after a function?

self.host_addr.clone()

Should I mention Rust's UFCS?

But I am nitpicking, right. This doesn't make a language bad in any way. However, as I said, Rust readability is pretty subpar in addition to already steep language learning curve.


You are nitpicking. size_t is architecture dependent, on x86 it will usually be 32-bit, on x86_64 it will be usually 64-bit. It's not equivalent to i32, u32 types.

Also, I find i32 and u32 types much cleaner than D's "unsigned int" and "int". What is the difference between "unsigned int" and "unsigned long" in D? It's still better than C++, but I'd rather write i32 and i64 rather than "int" and "long".


> Subjectively, I see no point in having "val", "var", "let", "def", "fn" symbols which bring only noise to code.

Usually, the reason is to make parsing easier. C++ is infamous for having undecidable grammar. Ruby is extremely pleasing to the eye, but its grammar is a clusterfuck. Newer languages have learned from that, so they try to have simpler grammars.

Another reason for those small syntax markers is to avoid implicit language decisions. In Rust, having to write one of "let/let mut/const" means forcing the programmer to make an explicit choice regarding mutability and memory usage. In Scala, "val/lazy val/var/lazy var/def" means having to think about mutability and evaluation times.

> What about Rust unable to drop parenthesis after a function?

In the case of Rust, the reason is uniformity. Even Scala, of all languages, is walking back on the optional parentheses, because the language allows to define functions with multiple argument lists, and optional parentheses introduce ambiguity between functions with empty argument lists and functions with no argument lists.


Yes, "make an explicit choice regarding mutability" can be done even easier by actually writing "immutable double[] arr = [1, 2, 3];", "const double[] arr = [1, 2, 3];". See, no Scala val/var which to a person who doesn't know the language tell nothing. When the language grammar is unambiguous and coherent you have faster compiling times and occasionally better readability. D hits a nice spot in here by capitalizing on C++ mistakes.

"optional parentheses introduce ambiguity" -- true, they do. However, I am struggling to understand why it is necessarily a bad thing? For a user I see a clear convenience of being able to write "double[] zeroArr = arr.zeros;" or "double[] newArr = 6.iota.sliced(3, 2).array.reverse.dropOne.join;". And if that is not enough, you can also inject your custom method into this chain and it will just work. Don't know about Rust but Scala simply refuses to compile in such cases which for a functional language looks like a limitation.

These are the D features that I really enjoy.


> this is just D's size_t

Rust has usize [0] as a size_t equivalent.

[0]: https://doc.rust-lang.org/std/primitive.usize.html


The nice thing about Rust is you often don’t have to declare the type of a variable since the compiler will just infer it for you. This is especially nice in an IDE like CLion which will show you the inferred type for each variable. As for the syntax for a type declaration, `variable: Type` is more natural and readable for me than `type variable`. The first one naturally reads as `variable is a Type` while the second reads like Yoda speak (`A Type, variable is`)

Since I am not familiar with Scalia, I am not sure why the types after the name would end up being more verbose, as far as I can tell the only difference is the : between the variable and its type. Would you mind expanding on that?

Personally although Rust definitely does not have the elegance of Haskell or Python, I definitely would not call it ugly. There aren’t that many symbols and once you actually spend the time to learn the language the semantics for each syntax element are pretty easy to remember. I also have looked at D, but the lack of algebraic data types makes it a non-starter for me.


The reason behind putting the type after the variable is that the resulting syntax plays way better with type inference. Scala is a clear inspiration for Rust in that regard.


(Let me nip a little here). Looks like not only Scala inference types but also its compile times too migrated into Rust.


Hahaha, it's true that Rust compile times are slower than its main competitors, due to the amount of work the compiler does. It's the same with Scala: even if some abstractions in both languages are zero- or low-cost during runtime, they still slow down compile times.

In any case, as a Scala dev, I wish the compile times were as short as in Rust!


> When you think about declaring a variable, do you think about its type of name first?

I completely disagree with your opinion on this subject, though I recognize that it's mostly subjective. I think types after the variable are completely better except for my muscle memory from C.


> Type names after variable or before? When you think about declaring a variable, do you think about its type of name first? I can't imagine you do the latter because "Hmm, I need an array of doubles to represent my tensor" is double[][] tensor; and not tensor: double[][].

You can just as equally think of it as, "I need my tensor to be an array of doubles".

That works much more cleanly with type inference, because the type is more of an annotation, and you can drop it without adding the boilerplate word "auto".

> Subjectively ugly and polluted with punctuation symbols that tell you little about their semantics.

Like what?


The elementary Rust syntax looks nicer. But once you start to do more intricate thing in Rust, then the syntax starts to look really ugly.

I think this is where Rust falls apart. In things like C, more features requires writing more C code. In Rust, more features requires learning more syntax features.


This is one of the things I disliked about Nim. I spent a few weeks with it hoping I'd love it as much as Python. But there are quirks in the type system that seem rather baffling to me, and frankly, ugly. Like having to type integer constants with 23'i32 because 23 is an int and int is not compatible with int32 (nor is it compatible with in64!) There are typed integer constants in many stdlib sources too.

In the tutorial, the language looks quite nice, comparable to Python. But in production level code, there are {.pragmas.} in a lot of places and they are not just advice for the compiler that can be ignored: they are important keywords that don't pollute the identifier space.

Another beef I had is that slice ranges and for loops are closed intervals by default. This is contrary to both Python and C, and while there is a syntax a..<b to be open on the right, it seems like a bad decision to be different from C and Python by default. It reminded me of Julia arrays starting at 1 by default. I guess I can see that if your audience is Fortran programmers, but arrays haven't started at 1 in a new language for a long time afaik.

I wish Nim had a goal of being a typed, compiled Python. But I don't think that ever was a main goal and now it's sort of too late because the language has a very wide scope (my opinion) and has compatibility concerns with all of its previous design choices.


How so?

My opinion is generally the opposite, that simple decisions like putting type annotations after names, etc. make it so each unavoidable complexity in syntax has its own home, instead of piling together like C++/Java/etc.


Judging by https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in... it's a pretty recent addition.


Also option / result types as well which are super nice


I was thinking about making a language with Rust syntax that compiled to D. ("Compile your Rust programs 10x faster!") You can replace "let" with "const" to get transitive immutability in D with type inference.

As a programmer who first used Python than C++, I don't find types after or before any nicer or worse.

As for Monads, you could write a template that wraps a pure function that creates side effects through its arguments into a Monad rather easily.

As for pattern matching, you can do that by writing your own template too.


It seems to me that D has been too many places and has too many features. My impression is that D sometimes uses a GC, sometimes not. I believe I can do many interesting things in D once I learn the language well enough to pick a certain subset of features, much like C++. In other words, if I want to write GC free code in D I have to learn what NOT to use.

If I want to pick a subset of features, I'd probably pick C++. Or, if I'm willing to use a GC and runtime, then there's lots of languages to choose from.

I use Rust if I want "safety" and no GC and that's all I get.

This is my impression. But I know very little of D so do not judge the language based on my impressions.


True. But unlike C++ or Rust, D is not a difficult language at all. You can easily understand when and how not to use GC. Which data structures require allocation and which can circumvent it. There is an ongoing work to make std a @nogc compatible. There is an excellent community of professionals to learn from. The problem is, it is small and resources are scarce. If only D had a bigger company backing it up...


Disclaimer: I've used D for an enormous time, and I tried Rust for about one hour for the experience.

Remarks:

- build times are worse in Rust, but not _that_ much worse

- with Rust error messages are plentiful and helpful to solve the error. It is a designed user experience, which is quite novel.

- the first Rust program I built downloaded no less than 146 packages, which seems to indicate the standard library is very barebones. This was an example program. So the granularity of package seems to be smaller there. I don't really like this.

- Rust has quite visibly a stronger open-source ecosystem, with lots of crates being built before a compiler release. Good.

- Rust documentation is more aimed at beginner programmers, and there is more of it.

- I just don't like to look at Rust code at all... the styling on the car is really bad

- it seems dub and cargo are very similar. Cargo download and installs a lot more cruft inside directories. Probably there is a way to have a shared directory for that.

- Rust libraries look a bit more systematically modular with the features tags ("configurations" in DUB parlance)

- it seems Rust has comparatively more C bindings than C-to-D translations in the ecosystem (vs D)

So... I'm not sure I would take Rust if starting a codebase today. It just doesn't add up for me versus D.

I try to be someone practical and need actual measurable improvements in the daily practice.

For me the key take-away is the very consistent experience when interfacing with Rust tools, since this experience has been designed and fine-tuned to be easy. I think D can learn some UX tricks from it.


Let me throw my uneducated and biased opinion on the table.

It's amazing how Rust development and popularity progressed over the years. Uncompromising features, no trade-offs except for complexity and compilation speed but what language is ideal, right?

For me personally, D was just easier and faster to learn than C/C++/Rust. I got basically the same speed without memory management and learning curve overhead. Coming from Python land I enjoyed fast rdmd compile-and-run times that made me feel like I am working with an interpreted language while having much more control and access to the system. Nowadays, D forum, IRC is so helpful that I get an answer within minutes. I expected quite the opposite considering how smaller the community is.

So, these are my reasons for why D. You can see that I didn't care whether the language was backed up by some global company or was trendy. I got tired of Python that fallbacks to C/C++ when performance matters and if you want some real work done good luck with C/C++. JVM based languages were also not my cup of tea due to memory appetites and being comparably slower. D came as a surprise managing to be faster both in execution and compilation. It is later that I learnt about some of the shortcomings, smaller community, fewer available libraries, etc. etc.


From what I understand D ownership is based on function attributes which means it's enforced only across function calls and only as an opt-in. In Rust this is done across everything, so function basic blocks are also validated.


For those you want the context of D please check its development history [1].

If history telling us something, python only take off after 20 years and now D language is around the 20 years mark. But fortunately D has passed the growing pain similar to python 2 to 3 when it transitioned to D2.

Personally I think D just need a big breakthrough in a form of a killer application like Ruby with RoR, and Go with Kubernetes to make it more popular and gets the snow ball rolling. The killer application probably involve some kind of data science or data analytics that is currently more popular now with python. But python seems starting to reach its limits and it will be good if D can take over.

For rust since it came from Mozilla team I'd expect by now Firefox is already re-written in rust by now but it seems yet to happen, and this article probably tell us why [2]. It will be wonderful to have Firefox-rust (if it ever happened) to replace Chrome that keeps eating away my quad core CPU and 16 GB ram laptop memory once opening more than 20 tabs.

[1]http://erdani.com/hopl2020-draft.pdf

[2]https://hacks.mozilla.org/2019/02/rewriting-a-browser-compon...


> For rust since it came from Mozilla team I'd expect by now Firefox is already re-written in rust by now but it seems yet to happen, and this article probably tell us why [2]

Nope. In fact that article says:

> By 2017, Mozilla had made two previous attempts to parallelize the style system using C++. Both had failed.

And goes on to say how they were successfully able to re-write it in Rust, and then talks about the kind of security problems Rust solves and the ones beyond language scope (correctness).

But I don't think we really needed an article to tell us why a 20+ year old browser that has a billion man-hours of development hasn't been re-written in a language that has only been stable for five years, and has a relatively small team working on it.


Chrome may be using a lot of active memory, but I don’t think it’s a result of poor programming practices. So I don’t see how switching to Rust would solve the problem. Unless Chrome has a memory leak problem.

If anything, Chrome can just offload the contents of the unused tabs to the hard drive, and reload it when it becomes active again. But this will require a massive architectural change to the core program itself.


Web pages have memory leaks, not Chrome itself.

Side note, but at least on linux, with both Chromium and Firefox, you can observe exactly this behavior- tab-based segregated memory management. The work was done on both engines over the past several years, works beautifully now.

The content of each tab lives in a separate process. Kill the process, see the tab marked failed in the UI. Reload the tab, see a corresponding process spin back up.

I keep dozens of tabs open and periodically kill the ones that creep to the top of ram use, both wired ram and virtual. Keeps me from going into swap.


I wouldn't compare a WIP borrow checker, just added some months ago, against Rust.

However, where it's the bigger and unique thing that D haves. Fast and very powerful metaprogramming. Can do things like parsing a XML or JSON at COMPILE TIME and generate code. No body catches how powerful is this ? For example, imagine parsing a gtk-build /glade XML and generating the GUI code at compile time, instead parsing it at runtime.


This is really quite common thinking in D.

I was writing a library and a contributor popped out of nowhere. He didn't knew D. The first patch it suggested was about parsing some JSON at compile-time.

It turned out std.json the stdlib parser was able to parse at compile-time in CTFE context. So, the contributor parsed JSON at compile-time without his knowledge, without really knowing D, and the fact it worked was accidental (since the parser was n't specially designed to do that, but could).


D was closed source when it was in the spotlight and missed its opportunity to gain mind share.


Rust enums are an amazing productivity boost because they can contain other values and data structures. This allows the type checker to help a lot more with business logic than is usually possible.


I can't tell if D is supposed to be used with or without the GC. I just know Rust is pretty close to an ML, which I like, and it has this nice borrow checker and is super popular.


The language doesn't tell you what to use. You choose what to use.


for something as fundamental as garbage collection, the last thing I want is a choice.


Then use garbage collection; it's an easy default.


I tried D some years ago, my naive program crashed as it wasn't memory safe. Being used to scala this was a surprising to me, I expected "if it compiles it works" but it turns out I had to take lifetimes into account just like c/c++. Rust has this "if it compiles it works" + quality.

Then I needed to create a program that would work both on android and Windows. Still liking D's syntax better funding rust rather verbose I decided to give it another try, but failed, I had to jump through too many hoops to make it produce a library usable on android. While with rust the experience was effortless.

After both experiences with D, I never looked back to it and rust is now my go to low level system language, the verboseness (with lifetimes and types) has grown on me.


Given the choice, I would rather use D, because experience has taught me that tracing GC are a productivy boom, even in systems programming, also D provides all the necessary tooling for doing GC free programming when required to do so.

However it lacks the commitment of a proper roadmap and big corporate support, and that sadly damages its image.

Rust on the other hand, while quite relevant for bringing affine types into mainstream, still isn't what I would like to use across the various domains I work on.

Ironically, I see Java and .NET getting the missing features (AOT, low level unsafe code, better control over memory allocation) that will eventually allow me to use them in system level programming scenarios, where I would choose D today.


Is there much choice though in terms of jobs? I mean, is it worth learning D vs rust? I'm actually thinking about that nowadays, for what to learn next..


In terms of jobs I guess Rust has the edge, including all major ones in desktop, server and mobile OSes, there are still some companies using D though.

https://dlang.org/orgs-using-d.html

So if getting a job is your major learning motivation, then I guess Rust has definitely the edge there.


Well learning D or Rust likely will not help you get a job writing Javascript. My C# style is heavily influenced by D, for the better IMO.

I have some potential coming up to do some Typescript, it will be interesting to find out how to transfer my experience into this language.


This is an excellent question!

There's an old saying about natural languages: "A Language is a dialect with an army."

I think Rust's army--the one that will invade any discussion and say "use Rust!"--is simply better than D's "army."


As a D user who never used Rust, few reasons why Rust is more popular than D:

- better ecosystem, cargo has many more packages, almost every important C library has a binding available, also many C++ libraries like Qt, Bullet. D claims to have the best C++ interop capabilities of all languages, but it's not reflected in the amount of bindings to C++ libraries available

- Rust has a better foundation in form of standard library and "blessed" packages. D standard library hasn't had many updates over the years. There are packages such as std.xml that are due for replacement, but no replacement exists. There is still no standard http package, serialization package.

- adding to the above - many problems in D are solved by the way of "I made something, maybe someone will find it useful". Pieces of code are shared, but there is no organized effort to fill in the gaps, and in the effort there is, there often seems to be lack of the final push to get something included in the standard library. There has been many potential stdlib packages in form of pull requests that never get merged due to codestyle nitpicking or some design concerns, with authors never moving in to fix it.

- more IDE-friendly environment. A lot of D code is constructed in build-time, which isn't friendly towards refactoring and code completion tools. Also, many people in D community are hostile towards IDEs, considering them as bloat and that "real programmers use Vim/Emacs and don't need those fancy syntax highlighting".

- stretching the language too thin. D started as a mostly GC language. Now we have @nogc and betterC. But neither really work as well as going full GC. Now ownership and borrowing system is coming into play soon. Automatic refcounting might be implemented in the future. That's a lot of possible failure points, and ecosystem splitting points.

- Lisp curse. There aren't many syntax sugars added into the language, and many language features can be somewhat implemented with templates. Things like named arguments can be implemented as a template hack, but it looks terrible both from caller and callee side. But for many people it's "good enough" and they consider the case closed and move on to other features. As a result, D offers often many half-baked solutions. Libraries that worked for someone but never really got fully implemented, language features that somewhat work as long as you don't use that other feature that they don't work with. etc.

Obviously many of those problems in D are just a matter of lack of manpower and lack of money, it's a bit of chicken and egg problem.


D tried to be a bit like Java, because in the early 2000 Java was the popular language dethroning C++ and sadly, it succeeded.

The worst thing about all this legacy is Android.

I would love a phone OS in D, Rust, or other well-designed language.


I love D but I think the GC is a good argument for Rust


d does not support ownership and borrowing “just like rust”


Because Rust is new and shiny.

People who use Rust aren't using it to solve real world problems, they're using it to scratch a novelty itch.

D is a tragedy in my opinion. It's an excellent language that just doesn't fit the political needs of any of the big players.

We have Swift which is a worse version of C#, we have Go, we have Java. Why don't we have a single language so that we can do cross platform development and abandon web browsers and javascript? Because politics. Every company needs to toot its own horn and suck up smart intelligent people so that they don't create a real competitor, and so we have a dozen languages that share 95% of the features and are all incompatible with one another and no one sane enough to say this is crazy, I'm going to take my FAANG money, move to a place with cheap rent and put an end to this madness.

It's only a game developer of all people, Jonathan Blow, that's doing it and his creation is a C++ replacement for games, not general purpose software. Sigh.


So your solution for there being to many languages is for somebody to create one more. And the main thing you want from that language is that it have no corporate sponsorship, such that whoever creates it will have to bear the financial burden personally.


Look no further than Clojure to see that it can be done. And I offer that as a 100% neutral statement.


Kinda. Clojure peaked interest around 2015 and has been declining ever since.

I think if it wasn't tied to the JVM ecosystem, it probably would have seen a lot more success outside of server side stuff. The long bootstrapping startup really is a killjoy. Then again, a lot of the type that made it popular in the first place came from being a part of the JVM ecosystem.


Clojure is and will always be a niche language.


> Why don't we have a single language so that we can do cross platform development

We do, we have dozens of them, C, C++, java, ruby, python, c# to name a few. We have at least a half dozen cross platform GUI toolkits to go with them, Qt, Gtk, swing, wxWidgets, tk. Pick whatever poison you want, they're all much better than electron.

I suspect you're right about rust though, something newer and shinier will come along soon, if it hasn't already.


> Why don't we have a single language so that we can do cross platform development and abandon web browsers and javascript?

What does that even mean? What do you lack in regards to cross-platform from Java / Rust / Nim / Go / Python / Ruby / Haxe / ...? (I'm assuming cross-platform here means desktops, not microprocessors)

Specifically, yes, there are things that you may miss in every one of them, but it's not like we don't have the option to use them. What's the point in complete unification in the first place?


He means cross platform ui frameworks. Afaik, only flutter has support for most platforms. It supports web, desktop and mobile.


> It's only a game developer of all people, Jonathan Blow, that's doing it and his creation is a C++ replacement for games, not general purpose software. Sigh.

That would still be huge. C++ keeps being used because of games. There's little to no C++ software being written nowadays that's not games.

And games are a gigantic industry, bigger than the film and music industries combined.

Many game developers would love the simplicity of D if there was a framework like Unreal but in D.


> There's little to no C++ software being written nowadays that's not games.

You need to look around more, because you are totally wrong on this point. It's true that C++ isn't used a lot in web programming, and web programming is what a lot of people see these days. But there is a lot more software being written than web programming and games, and C++ is still in fairly significant use.


I do write a tiny bit of this not gaming C++. And I feel extremely alone in what I do.

So please, instead of being snarky, do something useful and show me some of this software!


Well, I work in embedded systems. They tend toward C++ on higher-end systems and C on lower end. So it's your wireless router, your printer, your car, your washing machine, the medical devices at your hospital... all over the place.

But embedded is maybe 10% of code. Where else is it used? I'm not as sure of that, but the TIOBE index indicates that it's used pretty heavily.

I'm outside of that world, but I think that high-performance computing sometimes uses C++, because controlling memory alignment is a big deal there, and C++ does that pretty well.

The origin story of Go says that Google has a lot of C++, but that was a decade ago. I can't speak to how much new C++ is being written there.

Perhaps one way of looking at it would be to look at the membership of the C++ standards committee, and subtracting the language vendors. The rest are users.


On Web, desktop, mobile and distributed computing space, which are the areas I am focused on, C++ is indeed still used, however no longer for full stack applications like it used to be 20 years ago.

Rather we get to write the applications in some managed language, and C++ only gets used for some performance critical libraries, or GPGPU programming.


The new and shiny has already moved on to Pony, Zig, or whatever.


Possibly nim as well. But We should be able to provide interop between llvm and gcc so they can all cross pollinate in some way? Not saying it’s easy, nor that I have the skills to do it, but we should be able to build across boundaries and stop soloing so much?


I don’t hear much about Nim. Will this language ever take off? It seems this language needs a large corporation backing it, to get a chance to succeed.


Nim's compiler was full of bugs and would crash on trivial programs for a long time. It also has garbage collection so ends up in a different niche.

Just like Zig not parsing tabs or carriage returns or V being broken on windows and never fixed, I don't think it is corporate sponsorship that is the problem, but more basic utility.

Plenty of people are trying these new languages, the demand is there, but there is usually some huge blind spot that they don't deal with until it is too late and they have already burned a lot of people that gave them their attention.


Yeah I didn’t know about the bugs.. still, the idea / design is good. Hopefully they get it sorted out


Probably, but it could also be a positive as it is not beholden to one of the major tech companies.


>People who use Rust aren't using it to solve real world problems

Like a browser? Or google's fuchsia?

Have some fun: https://www.rust-lang.org/production/users

You know what WASM is?


I understand that people who use and like Rust would find my comment off-putting but there is no need to be snide.

There are precisely 0 job openings looking for Rust developers in my city, and I live in a city with millions of people.

To me, that's the real world where real people solve real world problems.

To me, when 0 people are hiring for Rust in a city in North America where there are maybe 10 other cities bigger than the one I live in, real problems aren't being solved using this language.

Sorry, that's empirical evidence, not opinion.

I understand that in a few places, people are using Rust and some are even getting paid to do it. I call that scratching the novelty itch - I'm sorry if my use of language offends your sensibilities, we'll have to learn to live with that somehow :)


>To me, that's the real world where real people solve real world problems.

Problems are technical, hiring is something completely different.

I live in a really small city and found 3 offers for Rust and 7 for Go (some of them are 'bonus points')...in Europe..and none of them are GAFA related.

But yes, it's a new language, java c/c++ is not.


Its certainly growing. For such a young language, its being thrown at projects that would have required c/c++ previously.

here's one notable one https://onesignal.com/blog/rust-at-onesignal/


Helpful community. Healthy ecosystem (never want to write byte formatting libraries). Fun language. Good APIs.

I wasn't early to Rust and I won't be early to any other language. For PLs I'm solidly on the far end of the chasm.


Its my understanding that the main reason is because Rust doesn't use a Garbage Collector.


- bad or missing tooling

- no clear direction

- no vision

- no ide

- no big company

- bad or missing documentation


* bad or missing tooling - true, it's missing but I wouldn't say it is bad

* no clear direction - agree

* no vision - there is but not well maintained unfortunately https://wiki.dlang.org/Vision/2018H1

* no ide - VS Code with D plugin works pretty well these days. There is an IDE written fully in D too.

* no big company - true, but there are a bunch of successful smaller ones.

* bad or missing documentation - not true, std documentation is pretty good and is gradually improved.

And don't forget that notwithstanding the lack of people and corporate funding (D is crowd-funded), you get a language that attempts to rival the big guys and frequently outplay them. Now, imagine the results given the resources were equal.


Because there's a movement called "Rewrite everything in Rust"


If that is indeed the answer (and I don’t think it is), perhaps try to answer the question “why isn’t there a similar movement for D?”


Because we have a movement called "Make the D compiler compatible with all C++ code" https://wiki.dlang.org/Calypso


Why should you rewrite good software? D can call C libraries. With DPP you can even use C macros in D code. D has some interoperability with C++ so now you have access to some C++ libs. But wait there is more. D can interop with python and R. And there was a person that talked about C# interop.


There will always be a movement "rewrite everything in x". This seems to be a natural manifestation of the generation conflict. Looking at the history of programming languages, it is certainly not wrong to say that any "most loved" language has a good chance to become the most hated language at some point in the future. And so on and so forth.


This is why I dislike using guest languages, instead of using existing "native" libraries for the platform, there is always that additional layer of idiomatic libraries for the guest language, yet another layer to debug and try to map to the original feature set.

And naturally their own build tool, debugging representations and IDE plugins.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: