5 ms·

I'm jumping into this a few hours late, but nobody has actually straight up asked the real question: Why try to compete with Rust while not really being a bette

I'm jumping into this a few hours late, but nobody has actually straight up asked the real question: Why try to compete with Rust while not really being a better Rust? The linked article generally defines a language that is more of the same, while Google is throwing Go under the bus to make it happen. The number of current and former Google employees that transitioned from being Gophers to being Rustaceans that I know of is basically a 100% conversion rate. Nobody at Google will use Carbon, nobody outside of Google will use Carbon. It's going to be worse than the Swift implosion.

quietbritishjim 4y ago
> Why try to compete with Rust while not really being a better Rust? The linked article explains this: classes defined in C++ can be used in Carbon and vice-versa. It even suggests you stick to Rust if that's not what you need. Edit: Oops, I assumed that the "linked article" was the github page[1] for Carbon, which is a lot more useful. [1] https://github.com/carbon-language/carbon-lang#why-build-carbon https://github.com/carbon-language/carbon-lang#why-build-car...
- DiabloD3 4y ago
  I guess the README really does answer my question: "Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should."
KptMarchewa 4y ago
They aren't trying to solve ownership problem as Rust does.
sgjohnson 4y ago
> Swift implosion What's wrong with Swift? It's a replacement for Objective-C, that nobody besides macOS/iOS devs used anyway, therefore it's no big deal if nobody uses it outside of macOS/iOS development, as it's not a regression
- DiabloD3 4y ago
  Very few people are using it at all, outside of calling OSX/iOS APIs. They're using it to weld platform support into a C++ codebase, same way they'd use ObjC for that (instead of writing entire apps in it). The number of pure-Swift projects I've seen per tempus is far less than pure-ObjC, which I think is the best measurement to comprehend Swift uptake. Nobody wanted an ObjC replacement, Apple misread the room.
  - tayistay 4y ago
    Do you have statistics? I’m an iOS/macOS dev. Everyone I know is using Swift. I think it would be a bad idea to start a new project in ObjC.
    - coldcode 4y ago
      I spent half of my iOS experience of a decade in ObjC and the last half in Swift. I also used ObjC way back when it was in NeXT. No comparison, you'd have to have your head examined to start something in ObjC today. The only reason to do it is maintain an old codebase; in my last job we replaced a huge ObjC codebase (written before I got there) entirely in Swift with higher quality and no issues (reason why was not just to convert it, it was part of a large new invasive project that was canceled but we shipped the Swift rewrite anyway).
  - emehex 4y ago
    This is a horribly misguided take. According to the latest S/O Developer Survey [1], Swift is used by 4.91% of respondents, while Objective-C is only used by 2.39%. Additionally, Swift is loved, and wanted by 62.88% and 4.3% of respondents, respectively. Objective-C is no where close by comparison... [1] https://survey.stackoverflow.co/2022/#technology-most-popular-technologies https://survey.stackoverflow.co/2022/#technology-most-popula...
    - BitwiseFool 4y ago
      Swift isn't bad, and I actually enjoyed using it. What I didn't enjoy was XCode, which is a shame because they're basically inseparable.
hnav 4y ago
Golang and C++ don't serve the same purpose. Google internally sometimes uses both to the same effect but that's because Google internally has a bunch of stuff (including new kernel syscalls) that makes highly concurrent server development in C++ palatable. So why "compete" with Rust? Because C++ compatibility was never a design goal of Rust, so gradual, painless migration from C++ to Rust is a non-starter. The best you can hope to do is rewrite entire subsystems where the API is narrow enough. This new language is obviously going to allow something more like Kotlin or even Swift where codebases will be mixed and new code will be written in Carbon.
- zozbot234 4y ago
  Google is contributing to "gradual migration from C++ to Rust" via autocxx and crubit. This Carbon thing looks more like a side project, and is still quite incomplete in many ways.
  - joshuamorton 4y ago
    Crubit and autocxx have, afaict, less investment than Carbon, and all three are collaborative. There's not certainty that crubit or autocxx will succeed. If they do, awesome. If they can't, Carbon exists. All three are experimental all three are incomplete in many ways. None are side projects.
- collegeburner 4y ago
  interesting, what kind of new syscalls are these? any plan to upstream?
  - hnav 4y ago
    Kind of a form of cooperative multitasking: https://news.ycombinator.com/item?id=24688225 https://news.ycombinator.com/item?id=24688225
randomdata 4y ago
There is nothing to suggest that it is competing with Rust. It would be a strange question to ask.
UncleMeat 4y ago
Rust has complicated interop with C++ and it is incredibly difficult to automate useful transcompilation from C++ to Rust. Various dynamic safety tools also don't work when you've got both Rust and C++ working together. The idea with Carbon appears to be a language with a much easier ramp for existing massive C++ codebases.
- rvz 4y ago
  > Rust has complicated interop with C++ and it is incredibly difficult to automate useful transcompilation from C++ to Rust. The problem with Rust is that it does not have this built directly into the language and relies on third party libraries. That doesn't really scale properly and some of the solutions are half-automated and needs lots of fine tuning, flag toggles and other configuration for it to work. Carbon, Swift and D have a different approach in integrating the interop capability directly into the language which does sound like an easier way to automate this use it for existing C++ libraries. But I guess that this approach is not easy, but it seems with D lang, it paid off.
formerly_proven 4y ago
My read on Carbon is that Google is in a spot where they have enormous amounts of C++ code flying around in a very idiosyncratic C++ dialect, and standard C++ is not working that well for them. So they are looking to create a C++-compatible language that better serves the needs of their codebase. We've seen this before with Facebook and PHP.
jollybean 4y ago
Because Rust is equally a terrible language to work with unless you're aligned with the objectives of the languages. Go is a bigger language than Rust, it's not surprising to see people move over, that doesn't mean it's going to get used. You're also vastly underestimating the number of people who otherwise like C++ and wish there was just an easier to use version. For example - if 'Magic Carbon' somehow got rid of the ugly parts of C++, integrated smart pointers into the syntax, made the tooling, builds more robust, and somehow made it possible to integrate with C/C++, it'd be my new favourite language.
wgjordan 4y ago
> Why try to compete with Rust while not really being a better Rust? The article addresses this directly and is clear that Carbon is not designed to 'compete with Rust', and instead targets a much narrower use-case: > Carbon is for those developers who already have large codebases in C++, which are difficult to convert into Rust. I don't have a large C++ codebase to maintain so I don't currently have any use for Carbon, but I could see it being interesting for those who do.
deleted 4y ago
[deleted]
ufmace 4y ago
I don't really get it either. The article says they want to focus on being a more direct replacement for C++ with easier conversions. I don't see that though - take maybe the most important issue, memory safety. As far as I can tell, they either 1. Take the C++ approach of mostly-manual with lots of inevitable mistakes that result, easy conversion, or 2. Rust approach of strict ownership and borrower checker model, which will almost certainly require substantial reworking, just like if they had used actual Rust, or 3. Golang approach, give up and go GC, in which case they won't touch the performance, low level features, and memory footprint of C++. So which way is this gonna go? Or do they have some other way to do memory management that nobody's thought of yet? If they had that, it'd be much more impressive than anything else they've said so far.

quietbritishjim 4y ago

> Why try to compete with Rust while not really being a better Rust? The linked article explains this: classes defined in C++ can be used in Carbon and vice-versa. It even suggests you stick to Rust if that's not what you need. Edit: Oops, I assumed that the "linked article" was the github page[1] for Carbon, which is a lot more useful. [1] https://github.com/carbon-language/carbon-lang#why-build-carbon https://github.com/carbon-language/carbon-lang#why-build-car...

DiabloD3 4y ago
I guess the README really does answer my question: "Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should."

KptMarchewa 4y ago

They aren't trying to solve ownership problem as Rust does.

sgjohnson 4y ago

> Swift implosion What's wrong with Swift? It's a replacement for Objective-C, that nobody besides macOS/iOS devs used anyway, therefore it's no big deal if nobody uses it outside of macOS/iOS development, as it's not a regression

DiabloD3 4y ago
Very few people are using it at all, outside of calling OSX/iOS APIs. They're using it to weld platform support into a C++ codebase, same way they'd use ObjC for that (instead of writing entire apps in it). The number of pure-Swift projects I've seen per tempus is far less than pure-ObjC, which I think is the best measurement to comprehend Swift uptake. Nobody wanted an ObjC replacement, Apple misread the room.
- tayistay 4y ago
  Do you have statistics? I’m an iOS/macOS dev. Everyone I know is using Swift. I think it would be a bad idea to start a new project in ObjC.
  - coldcode 4y ago
    I spent half of my iOS experience of a decade in ObjC and the last half in Swift. I also used ObjC way back when it was in NeXT. No comparison, you'd have to have your head examined to start something in ObjC today. The only reason to do it is maintain an old codebase; in my last job we replaced a huge ObjC codebase (written before I got there) entirely in Swift with higher quality and no issues (reason why was not just to convert it, it was part of a large new invasive project that was canceled but we shipped the Swift rewrite anyway).
- emehex 4y ago
  This is a horribly misguided take. According to the latest S/O Developer Survey [1], Swift is used by 4.91% of respondents, while Objective-C is only used by 2.39%. Additionally, Swift is loved, and wanted by 62.88% and 4.3% of respondents, respectively. Objective-C is no where close by comparison... [1] https://survey.stackoverflow.co/2022/#technology-most-popular-technologies https://survey.stackoverflow.co/2022/#technology-most-popula...
  - BitwiseFool 4y ago
    Swift isn't bad, and I actually enjoyed using it. What I didn't enjoy was XCode, which is a shame because they're basically inseparable.

hnav 4y ago

Golang and C++ don't serve the same purpose. Google internally sometimes uses both to the same effect but that's because Google internally has a bunch of stuff (including new kernel syscalls) that makes highly concurrent server development in C++ palatable. So why "compete" with Rust? Because C++ compatibility was never a design goal of Rust, so gradual, painless migration from C++ to Rust is a non-starter. The best you can hope to do is rewrite entire subsystems where the API is narrow enough. This new language is obviously going to allow something more like Kotlin or even Swift where codebases will be mixed and new code will be written in Carbon.

zozbot234 4y ago
Google is contributing to "gradual migration from C++ to Rust" via autocxx and crubit. This Carbon thing looks more like a side project, and is still quite incomplete in many ways.
- joshuamorton 4y ago
  Crubit and autocxx have, afaict, less investment than Carbon, and all three are collaborative. There's not certainty that crubit or autocxx will succeed. If they do, awesome. If they can't, Carbon exists. All three are experimental all three are incomplete in many ways. None are side projects.
collegeburner 4y ago
interesting, what kind of new syscalls are these? any plan to upstream?
- hnav 4y ago
  Kind of a form of cooperative multitasking: https://news.ycombinator.com/item?id=24688225 https://news.ycombinator.com/item?id=24688225

randomdata 4y ago

There is nothing to suggest that it is competing with Rust. It would be a strange question to ask.

UncleMeat 4y ago

Rust has complicated interop with C++ and it is incredibly difficult to automate useful transcompilation from C++ to Rust. Various dynamic safety tools also don't work when you've got both Rust and C++ working together. The idea with Carbon appears to be a language with a much easier ramp for existing massive C++ codebases.

rvz 4y ago
> Rust has complicated interop with C++ and it is incredibly difficult to automate useful transcompilation from C++ to Rust. The problem with Rust is that it does not have this built directly into the language and relies on third party libraries. That doesn't really scale properly and some of the solutions are half-automated and needs lots of fine tuning, flag toggles and other configuration for it to work. Carbon, Swift and D have a different approach in integrating the interop capability directly into the language which does sound like an easier way to automate this use it for existing C++ libraries. But I guess that this approach is not easy, but it seems with D lang, it paid off.

formerly_proven 4y ago

My read on Carbon is that Google is in a spot where they have enormous amounts of C++ code flying around in a very idiosyncratic C++ dialect, and standard C++ is not working that well for them. So they are looking to create a C++-compatible language that better serves the needs of their codebase. We've seen this before with Facebook and PHP.

jollybean 4y ago

Because Rust is equally a terrible language to work with unless you're aligned with the objectives of the languages. Go is a bigger language than Rust, it's not surprising to see people move over, that doesn't mean it's going to get used. You're also vastly underestimating the number of people who otherwise like C++ and wish there was just an easier to use version. For example - if 'Magic Carbon' somehow got rid of the ugly parts of C++, integrated smart pointers into the syntax, made the tooling, builds more robust, and somehow made it possible to integrate with C/C++, it'd be my new favourite language.

wgjordan 4y ago

> Why try to compete with Rust while not really being a better Rust? The article addresses this directly and is clear that Carbon is not designed to 'compete with Rust', and instead targets a much narrower use-case: > Carbon is for those developers who already have large codebases in C++, which are difficult to convert into Rust. I don't have a large C++ codebase to maintain so I don't currently have any use for Carbon, but I could see it being interesting for those who do.

deleted 4y ago

[deleted]

ufmace 4y ago

I don't really get it either. The article says they want to focus on being a more direct replacement for C++ with easier conversions. I don't see that though - take maybe the most important issue, memory safety. As far as I can tell, they either 1. Take the C++ approach of mostly-manual with lots of inevitable mistakes that result, easy conversion, or 2. Rust approach of strict ownership and borrower checker model, which will almost certainly require substantial reworking, just like if they had used actual Rust, or 3. Golang approach, give up and go GC, in which case they won't touch the performance, low level features, and memory footprint of C++. So which way is this gonna go? Or do they have some other way to do memory management that nobody's thought of yet? If they had that, it'd be much more impressive than anything else they've said so far.