4 ms·

Funny, my cynical brain read the Swift/C++ announcement as two dead languages fighting for relevance, in the face of Rust, by banding together. Fuck Rust <-> C+

Funny, my cynical brain read the Swift/C++ announcement as two dead languages fighting for relevance, in the face of Rust, by banding together. Fuck Rust <-> C++. Let C++ die! ;-) (only half joking)

HNSucksAss 5y ago
pjmlp 5y ago
So when is Apple going to rewrite IO and Driver Kit, and re-base Metal Shading Language in Rust? If C++ dies Rust will have a hard time replacing its GCV/LLVM backends. Cranelift as it stands today won't do it.
- estebank 5y ago
  >> Let C++ die! > So when is Apple going to rewrite IO and Driver Kit, and re-base Metal Shading Language in Rust? Death of a language isn't a clear cut thing that really happens, so everyone has their own definition. Some consider a language dead when they fall from former glory, so for a popular language they don't need to disappear, they can even have multiple thriving niches and still be considered "dead" because they are a portion of the usage they used to have (see Python 2, still widely in use, but I can make argument to call it "dead"). Others consider a language dead when direct competitors are used instead of them for new projects (see Perl). Yet others consider a language dead when there's an active and thriving effort to migrate existing applications to other languages. All of these are varying interpretations of "dead language". I would call Delphi, Perl, Python 2 "dead", yet there are plenty of projects in use out there written in those languages, and in some cases even thriving communities. But even if their absolute numbers don't decrease, the rest of the world might continue to out grow them into "irrelevance" (whatever one might want to consider that to be). All that to say: C++ doesn't need to disappear to "die", it doesn't need to die for other langs to thrive, and it doesn't need to "die" even if other languages thrive. It is not a zero-sum game. > If C++ dies Rust will have a hard time replacing its GCV/LLVM backends. > Cranelift as it stands today won't do it. You're comparing a 20 year old project (LLVM) with a 4 year old project (cranelift) that have different goals. It's like comparing Rust and Python, or Fiat and Cannondale: they have some similarities, but any comparison is gonna be stretched beyond use.
  - pjmlp 5y ago
    Well, most Rust vs C++ comments, like the one I was replying to, tend to lack a perspective of what the market actually uses, and how Rust is dependent on C++ toolchains (at least for now), so.
- tialaramex 5y ago
  LLVM in Rust seems actually plausible, there are some Rust ideas that probably feel very natural indeed to LLVM core people, in particular as I understand it the niche trick, where Rust knows the valid bits for type A and type B don't overlap, so, it can fit them both in whichever was the largest (e.g. Option<NonZeroUsize>), is something LLVM does a lot in its own internals.
  - pjmlp 5y ago
    The problem isn't the language, rather the volume of contributions. Last year, LLVM has reached Linux kernel level of contributions from researchers and compiler vendors. LLVM in Rust won't have that, and no one is going to rewrite such a massive compiler building infrastructure. Then we have all the companies that building tooling on top of it, and everything related to the development process that relies on how LLVM is implemented.

Funny, my cynical brain read the Swift/C++ announcement as two dead languages fighting for relevance, in the face of Rust, by banding together. Fuck Rust <-> C++. Let C++ die! ;-) (only half joking)

HNSucksAss 5y ago

pjmlp 5y ago

So when is Apple going to rewrite IO and Driver Kit, and re-base Metal Shading Language in Rust? If C++ dies Rust will have a hard time replacing its GCV/LLVM backends. Cranelift as it stands today won't do it.

estebank 5y ago
>> Let C++ die! > So when is Apple going to rewrite IO and Driver Kit, and re-base Metal Shading Language in Rust? Death of a language isn't a clear cut thing that really happens, so everyone has their own definition. Some consider a language dead when they fall from former glory, so for a popular language they don't need to disappear, they can even have multiple thriving niches and still be considered "dead" because they are a portion of the usage they used to have (see Python 2, still widely in use, but I can make argument to call it "dead"). Others consider a language dead when direct competitors are used instead of them for new projects (see Perl). Yet others consider a language dead when there's an active and thriving effort to migrate existing applications to other languages. All of these are varying interpretations of "dead language". I would call Delphi, Perl, Python 2 "dead", yet there are plenty of projects in use out there written in those languages, and in some cases even thriving communities. But even if their absolute numbers don't decrease, the rest of the world might continue to out grow them into "irrelevance" (whatever one might want to consider that to be). All that to say: C++ doesn't need to disappear to "die", it doesn't need to die for other langs to thrive, and it doesn't need to "die" even if other languages thrive. It is not a zero-sum game. > If C++ dies Rust will have a hard time replacing its GCV/LLVM backends. > Cranelift as it stands today won't do it. You're comparing a 20 year old project (LLVM) with a 4 year old project (cranelift) that have different goals. It's like comparing Rust and Python, or Fiat and Cannondale: they have some similarities, but any comparison is gonna be stretched beyond use.
- pjmlp 5y ago
  Well, most Rust vs C++ comments, like the one I was replying to, tend to lack a perspective of what the market actually uses, and how Rust is dependent on C++ toolchains (at least for now), so.
tialaramex 5y ago
LLVM in Rust seems actually plausible, there are some Rust ideas that probably feel very natural indeed to LLVM core people, in particular as I understand it the niche trick, where Rust knows the valid bits for type A and type B don't overlap, so, it can fit them both in whichever was the largest (e.g. Option<NonZeroUsize>), is something LLVM does a lot in its own internals.
- pjmlp 5y ago
  The problem isn't the language, rather the volume of contributions. Last year, LLVM has reached Linux kernel level of contributions from researchers and compiler vendors. LLVM in Rust won't have that, and no one is going to rewrite such a massive compiler building infrastructure. Then we have all the companies that building tooling on top of it, and everything related to the development process that relies on how LLVM is implemented.