23 ms·

Ask HN: Why do you use Rust, when D is available?

147 points by crazypython 6y ago

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.

narrationbox 6y ago
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.
- lordlic 6y ago
  > 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.
  - isaiahg 6y ago
    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.
Buttons840 6y ago
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.
- tastyminerals2 6y ago
  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...
thomastjeffery 6y ago
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.
- juststeve 6y ago
  Also option / result types as well which are super nice
- erik_seaberg 6y ago
  Judging by https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in... it's a pretty recent addition.
- tastyminerals2 6y ago
  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.
  - vvillena 6y ago
    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.
gaze 6y ago
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.
- welkam 6y ago
  The language doesn't tell you what to use. You choose what to use.
  - gaze 6y ago
    for something as fundamental as garbage collection, the last thing I want is a choice.
    - EvenThisAcronym 6y ago
      Then use garbage collection; it's an easy default.
viraptor 6y ago
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.
sesuximo 6y ago
I love D but I think the GC is a good argument for Rust
jdxcode 6y ago
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.
- alexashka 6y ago
  Are you implying that D is slow at compiling regular code but fast at compiling itself, because of some cleverness? Is that actually true?
  - gm 6y ago
    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?"
    - cy_hauser 6y ago
      > 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.
      - cultofmetatron 6y ago
        I'm pretty sure that was a knock at go
  - jdxcode 6y ago
    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 https://dlang.org/orgs-using-d.html
alexashka 6y ago
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.
- jsnell 6y ago
  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.
  - leetrout 6y ago
    Look no further than Clojure to see that it can be done. And I offer that as a 100% neutral statement.
    - darksaints 6y ago
      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.
    - mbrodersen 6y ago
Scarbutt 6y ago
Because there's a movement called "Rewrite everything in Rust"
- elygre 6y ago
  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?”
  - crazypython 6y ago
    Because we have a movement called "Make the D compiler compatible with all C++ code" https://wiki.dlang.org/Calypso https://wiki.dlang.org/Calypso
  - welkam 6y ago
    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.
- Rochus 6y ago
  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.
  - pjmlp 6y ago
    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.
thrwaway69 6y ago
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.
- jdxcode 6y ago
  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.
- dgb23 6y ago
  > 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.
aey 6y ago
D was closed source when it was in the spotlight and missed its opportunity to gain mind share.
gameswithgo 6y ago
d does not support ownership and borrowing “just like rust”
sitkack 6y ago
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.
- thrwaway69 6y ago
  Why did go took off then?
  - OriginalPenguin 6y ago
    For a bunch of reasons, but one of the most important was it had Google's backing.
    - pstuart 6y ago
      Google being involved is mixed blessing, but having financial support to see it prosper is not unreasonable to appreciate.
  - pengaru 6y ago
    It's impossible to measure how much impact just having Rob Pike and Google behind Go has had on its adoption.
    - catach 6y ago
      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.
      - sitkack 6y ago
        What Go did for the tooling space cannot be underestimated, it is wonderful and we will never go back to the before time.
dpc_pw 6y ago
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.
- mrfusion 6y ago
  I’m currently trying to get into robotics. But why does everyone want c++? Surely robots can be programmed in other languages.
  - _bxg1 6y ago
    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.
justinpombrio 6y ago
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 https://dlang.org/spec/memory-safe-d.html
- mhh__ 6y ago
  D's borrow checker is only semi-documented/WIP at the moment. https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ 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)
  - crazypython 6y ago
    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.
darksaints 6y ago
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.
- jsnell 6y ago
  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.
  - rbanffy 6y ago
    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.
deleted 6y ago
[deleted]
woah 6y ago
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.
realangelbaby95 6y ago
No body has your shit arron
- realangelbaby95 6y ago
  You better not come in with a smart asa mouth to nobody and I'm not playing games
deleted 6y ago
[deleted]
TechMahn 6y ago
Its my understanding that the main reason is because Rust doesn't use a Garbage Collector.
ZoomZoomZoom 6y ago
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.
- trevyn 6y ago
  >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.
  - fastasucan 6y ago
    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.
renewiltord 6y ago
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.
teleforce 6y ago
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 http://erdani.com/hopl2020-draft.pdf [2]https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/ https://hacks.mozilla.org/2019/02/rewriting-a-browser-compon...
- blackrock 6y ago
  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.
  - jonahbenton 6y ago
    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.
Zardoz84 6y ago
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.
- ponce 6y ago
  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).
fortran77 6y ago
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."
tastyminerals2 6y ago
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.
deleted 6y ago
[deleted]
Shorel 6y ago
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.
MintsJohn 6y ago
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.
ponce 6y ago
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.
skocznymroczny 6y ago
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.
pjmlp 6y ago
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.
- ckcheng 6y ago
  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..
  - pjmlp 6y ago
    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 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.
  - he_the_great 6y ago
    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.
claudiug 6y ago
- bad or missing tooling - no clear direction - no vision - no ide - no big company - bad or missing documentation
- tastyminerals2 6y ago
  * 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 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.

e_y_ 6y ago

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.

tastyminerals2 6y ago
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.
- skocznymroczny 6y ago
  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".
- jbboehr 6y ago
  > 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 https://doc.rust-lang.org/std/primitive.usize.html
- vvillena 6y ago
  > 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.
  - tastyminerals2 6y ago
    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.

Shorel 6y ago

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

AnimalMuppet 6y ago
> 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.
- Shorel 6y ago
  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!
  - AnimalMuppet 6y ago
    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.
- pjmlp 6y ago
  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.

AnimalMuppet 6y ago

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.

yesenadam 6y ago
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.
- AnimalMuppet 6y ago
  > 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.
  - yesenadam 6y ago
    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.
    - AnimalMuppet 6y ago
      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.
      - yesenadam 6y ago
        Thank you.

blub 6y ago

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.

mratsim 6y ago
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?
danielscrubs 6y ago
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.
vardump 6y ago
"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.
Recurecur 6y ago
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! :-)
- blub 6y ago
  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" :-)
- MacSystem 6y ago
  What are thoughts on D?

calaphos 6y ago

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.

Aeolun 6y ago
> 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.
- bjourne 6y ago
  But why not program in Python and take 100% of your bug count?
  - UncleMeat 6y ago
    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.
- zucker42 6y ago
  He was saying this in the context of "why do people still use C++ at all".
vmchale 6y ago
> Why would you throw all of that overboard just to learn a fancy new language with a weird ownership system? lmao
dpc_pw 6y ago
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.
- MacSystem 6y ago
  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++?

Recurecur 6y ago

> 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/ https://juliarobotics.org/) or Scala Native (https://scala-native.readthedocs.io/en/v0.3.9-docs/ https://scala-native.readthedocs.io/en/v0.3.9-docs/) becomes mainstream, the productivity gains would be substantial.

rozab 6y ago
For some reason Python seems to be very popular in academic robotics right now. Not a great choice
- Recurecur 6y ago
  Being a "better, stronger, faster" Python is fairly near Julia's sweet spot... :-)
- type0 6y ago
  > Not a great choice It is a great choice to prototype the ideas
WorldMaker 6y ago
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.)
- Recurecur 6y ago
  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.
  - WorldMaker 6y ago
    > 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.
    - danielscrubs 6y ago
      > it's still possible to miss something Could you elaborate?
      - WorldMaker 6y ago
        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).
pjmlp 6y ago
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.

ncmncm 6y ago

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

tutfbhuf 6y ago
> 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.
- nix23 6y ago
  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)
  - lordlic 6y ago
    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.
    - nix23 6y ago
      I know, but around 2009/10 every hipster programmer said RD's are a thing of the past..like C like Java etc...
    - tutfbhuf 6y ago
      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).
  - tutfbhuf 6y ago
    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.
nindalf 6y ago
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 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 :)
- papaf 6y ago
  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 http://arma.sourceforge.net/speed.html [2] https://github.com/catchorg/Catch2/blob/master/docs/tutorial.md#top https://github.com/catchorg/Catch2/blob/master/docs/tutorial...
  - adamnemecek 6y ago
    Why are they impossible in Rust? Are you aware of Rust's macros right?
    - ncmncm 6y ago
      Rust macros know nothing about types, but types are what do all the work at compile time.
      - adamnemecek 6y ago
        Do they have to know about types?
secondcoming 6y ago
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.
- mantap 6y ago
  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.
  - Aeolun 6y ago
    The C++ that they teach you in universities barely gets you started. I wouldn’t count on those for a steady supply.
  - gnulinux 6y ago
    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.
    - mantap 6y ago
      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.
rational_indian 6y ago
>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?
- lordlic 6y ago
  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.
- ncmncm 6y ago
  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.
  - rational_indian 6y ago
Rochus 6y ago
Thank you for putting it so aptly. Unfortunately for many people technology is still an emotional rather than a professional topic.
- Aeolun 6y ago
  I think the two go hand in hand. I get emotional over many a professional topic.
  - Rochus 6y ago
    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.
bigjake 6y ago
Excellent explanation! Couldn't have said it better myself.
isaiahg 6y ago
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.

tluyben2 6y ago

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

Kaze404 6y ago
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.
- adamnemecek 6y ago
  Rust is much better at caching the intermediate results of compilation. First time compilation might take some time, recompilation will be faster though.
  - sivizius 6y ago
    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.
  - vmchale 6y ago
    cargo doesn't do a terribly good job of caching dependencies. Might be better than whatever C++ does though.
    - pjmlp 6y ago
      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.
      - adamnemecek 6y ago
        You can do this with a build script.
        pjmlp 6y ago
        So goodbye declarative builds.
        adamnemecek 6y ago
        I thought I cared about declarativeness, turns out I don't.
        pjmlp 6y ago
        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.
asdkhadsj 6y ago
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.
bigjake 6y ago
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 :)

billconan 6y ago

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.

cyberprunes 6y ago
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.
- peterkos 6y ago
  > 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...)
kd5bjo 6y ago
> 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.
- peterkos 6y ago
  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 :)
Avamander 6y ago
No, knowing C++ probably confuses you for a while, it has confused me.

jjpe 6y ago

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

justinpombrio 6y ago
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-Array-MArray.html#g:4 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.

blub 6y ago

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.

secondcoming 6y ago
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.
- krapht 6y ago
  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.
- ncmncm 6y ago
  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.
- mbrodersen 6y ago
  The world runs on C/C++ code. And new C++ projects are started every single day.
- bigjake 6y ago
  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.