14 ms·

The syntax looks a lot like Rust, though. I'm surprised they made such a break when there explicit goal is to make migration from C++ as easy as possible. Also,

The syntax looks a lot like Rust, though. I'm surprised they made such a break when there explicit goal is to make migration from C++ as easy as possible. Also, Rust (from my biased point of view) is currently on its way to become the standard low-level language, so I'm not too confident that Rust-but-with-OO is enough of a selling point.

anon25783 4y ago
looks like Rust mixed with Go
zozbot234 4y ago
> The syntax looks a lot like Rust, though. I'm surprised they made such a break Convergent evolution. Rusty syntax is pretty close to what you get if you want to make a language look broadly similar to C/C++ while avoiding pathological and/or computationally difficult parsing.
imachine1980_ 4y ago
Rust is like c++ but only the new way to doing c++ is huge rust is like subset of c++ and ownership model. I thing is the right way c++ is harder than rust only because is so bloated. Carbon seams less bloated "fork" of c++ whit only the new way of doing things, but allow you full interoperability whit all c++, instead of partial and i don't see ownership, i thing is taxing mentally (worth or not depends). if i work in c++ i totally will use this.
usrusr 4y ago
Considering the seemingly endless list of things that deliberately don't break with the c++ legacy, new syntax is almost the only change left. And if you were about to give c++ a syntax reboot, why wouldn't you look at what successful other modern syntaxes are doing? "c++, but in a syntax for people accustomed to rust instead of in a syntax for people accustomed to C" sounds like a perfectly reasonable approach. Your perception (and mine) that rust is about to become the new default for "true native" is perfectly consistent with this, a language for the rust generation for when they have to deal with the c++ legacy. A legacy that won't be going away any time soon. I suspect that the author (authors?) wouldn't disagree at all with "use Rust when possible, Carbon when you can't", my perception (from a quick glance at the site) is that they are fully aware of the limitations of the niche they have so clearly staked out.
- mempko 4y ago
  The problem with C++ is it keeps getting better. There was a time when Rust was interesting to me but then C++11 came out. Then they kept improving it
  - fouronnes3 4y ago
    C++ has virtually zero tooling and the committee is not interested in ever working on that. Comparing CMake to cargo is like comparing fifth century fireworks to the Space Shuttle. I mean we are getting modules that aren't literally copy paste maybe next year.
    - AnimalMuppet 4y ago
      Given that gunpowder was invented in the 9th century, fifth century fireworks were probably pretty uninteresting...
    - pjmlp 4y ago
      Use Visual C++ and you will have modules today. I have cargo today in C++ via NuGET and vcpkg, and what is great about it, I don't have to compile my depedencies from scratch.
      - joshuamorton 4y ago
        > I have cargo today in C++ via NuGET and vcpkg, and what is great about it, I don't have to compile my depedencies from scratch. To be fair, if you're using a language that has a reasonable compilation story, this is only every a concern the first time you compile.
        pjmlp 4y ago
        Sure I always need an excuse to go out for lunch.
    - StillBored 4y ago
      "C++ has virtually zero tooling" I read that and I was like WTF, the entire programming ecosystem exists on C/C++ tooling. But from your perspective its modules/cargo that is the tooling? That is IMHO an odd viewpoint. As someone who despises the way cargo works, and hates not having long term explicit control over my dependencies (going so far as to track and check them in along with build artifacts) I'm not convinced that the recent toss another random dependency that itself pulls dependencies into the build is a good thing. I like the fact that I have three dozen+ different ways to do regexp's in C depending on my priorities, and that picking one requires cognitive overhead and modifications to source control/etc. Its easy to add a line to a makefile/etc to pull crap off github in C, so its not like this is a hard problem to deal with in C/C++ but its one where the scale of the problem allows for optimization. AKA like the dynamic typing argument, making the programmer think about a problem I believe yields a better solution. Its also one where i'm not tied to the whimsy of the library author should I decide to fork or maintain the code long after they have gotten bored or rewritten it 3 different times. I can to this day rebuild code I wrote 20 years ago on a modern machine with little effort. Can you say the same about even 10 year old node.js or python code? Put another way, I spend a little bit more on upfront effort and it pays off long term. And I know i'm in the minority, but its also why repeatedly I've run small teams of a half dozen or so people who's products are ahead of major competitors with teams of 100's+ of engineers.
UncleMeat 4y ago
Syntax migration is easy. It is the semantic migration that is hard.
flohofwoe 4y ago
I'd say the syntax looks like most other modern languages, not just Rust.
pron 4y ago
> Rust (from my biased point of view) is currently on its way to become the standard low-level language The evidence seems to suggest the opposite. Other than a lot of talk on programming fashion publications that are always more aspirational than representative (such as this site) Rust seems to have reached 0.3% of the market [1], up from 0.1% a couple of years ago [2], and while that is ok growth, programming languages with few exception tend to reach, approach, or at least point toward their all-time peak market penetration around age 10, and Rust is already 7. Any language could, of course, be an exception to historical trends, but there's nothing to suggest that is the case. More anecdotal adoption stories are just as bleak. Even at this relatively advanced age, many companies dabble in Rust — as they did in, say, Haskell — but not many established companies have yet to really bet big on it. The only positive is that among the low-level languages discussed on aspirational sites, Rust is, indeed, the most talked-about language, but history also suggests that that is a very bad predictor of long-term market success. [1]: https://www.devjobsscanner.com/blog/top-8-most-demanded-languages-in-2022/ https://www.devjobsscanner.com/blog/top-8-most-demanded-lang... [2]: https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/ https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/
- cogman10 4y ago
  > programming languages with few exception tend to reach, approach, or at least point toward their all-time peak market penetration around age 10 Notable exceptions from the links you've provided: C#, Java, Go, PHP. All appear to have an upward trajectory today. Javascript has also seen a similar penetration boost when nodejs came on the scene. With rust looking to get integration both into the Linux kernel and GCC, that points to some pretty positive things for the language's penetration. Particular in the embedded world.
  - pron 4y ago
    > All appear to have an upward trajectory today. They might have an upward trajectory, but they're not posed to break well beyond their respective records. With the possible exception of Python, how popular a language is at age ten is a reasonable rough indicator of how popular it's ever going to be. At its current growth rate Rust would reach 1% market share at age ten. Again, there can certainly be surprises, but I think it's weird to say that actual current evidence clearly points to success for Rust. On the contrary, to become a success it would need to buck the trend and be quite a surprise. So it could happen, but I don't see much to support the claim that this is what's currently happening. > With rust looking to get integration both into the Linux kernel and GCC, that points to some pretty positive things for the language's penetration. I agree that it shows that the language is taken seriously and isn't dismissed as a possible option, and that that's very good. That indicates that the language isn't an immediate irredeemable failure, but I don't think it's an indicator of future success.
aaaaaaaaaaab 4y ago
>Also, Rust (from my biased point of view) is currently on its way to become the standard low-level language Lol. Gave me a good chuckle!
mbrodersen 4y ago
> on its way to become the standard low-level language It will take a very long time for Rust to get even close to the huge amount of C++ code out there. There are more than 5 million professional C++ developers employed around the world today. And that number is increasing. Don’t get me wrong: I like Rust and other attempts to move beyond C++. But don’t underestimate how much C++ code has been written the last 30+ years. And new C++ projects are started every single day. There are probably more C++ projects started every day than Rust projects. So anything that makes it possible to move beyond C++ while being 100% interoperable is good news.
- zozbot234 4y ago
  Carbon is not trying to be 100% interoperable with C++. It's trying for some fuzzy notion of "good enough" - that's really not very different from what Rust is trying to do with cxx-rs. Yes there are serious challenges and I've described them here, but they're not impossible to address while staying with Rust.
  - lenkite 4y ago
    > Carbon is not trying to be 100% interoperable with C++ It's trying for some fuzzy notion of "good enough" No, it's clearly not a "fuzzy" notion of interop even in the most uncharitable interpretation. Your assertion is mis-information. "Seamless, bidirectional interoperability with C++, such that a library anywhere in an existing C++ stack can adopt Carbon without porting the rest." Support mixing Carbon and C++ toolchains Compatibility with the C++ memory model Minimize bridge code Unsurprising mappings between C++ and Carbon types Allow C++ bridge code in Carbon files Carbon inheritance from C++ types Support use of advanced C++ features Support basic C interoperability
    - zozbot234 4y ago
      And that's still not 100%. The Carbon devs are very clear that there will be some C++ code that Carbon is unable to interoperate with.
BearOso 4y ago
I don't know about it becoming the standard LL language yet. There's a lot of memory management in low level programming, and peppering everything with unsafe seems like it'd be tedious. I'd rather just write in C to begin with. I'm interested in seeing how things are handled with the Linux kernel's rust support, if it ever becomes more than a proof of concept. That will be a good viability test.

anon25783 4y ago

looks like Rust mixed with Go

zozbot234 4y ago

> The syntax looks a lot like Rust, though. I'm surprised they made such a break Convergent evolution. Rusty syntax is pretty close to what you get if you want to make a language look broadly similar to C/C++ while avoiding pathological and/or computationally difficult parsing.

imachine1980_ 4y ago

Rust is like c++ but only the new way to doing c++ is huge rust is like subset of c++ and ownership model. I thing is the right way c++ is harder than rust only because is so bloated. Carbon seams less bloated "fork" of c++ whit only the new way of doing things, but allow you full interoperability whit all c++, instead of partial and i don't see ownership, i thing is taxing mentally (worth or not depends). if i work in c++ i totally will use this.

usrusr 4y ago

Considering the seemingly endless list of things that deliberately don't break with the c++ legacy, new syntax is almost the only change left. And if you were about to give c++ a syntax reboot, why wouldn't you look at what successful other modern syntaxes are doing? "c++, but in a syntax for people accustomed to rust instead of in a syntax for people accustomed to C" sounds like a perfectly reasonable approach. Your perception (and mine) that rust is about to become the new default for "true native" is perfectly consistent with this, a language for the rust generation for when they have to deal with the c++ legacy. A legacy that won't be going away any time soon. I suspect that the author (authors?) wouldn't disagree at all with "use Rust when possible, Carbon when you can't", my perception (from a quick glance at the site) is that they are fully aware of the limitations of the niche they have so clearly staked out.

mempko 4y ago
The problem with C++ is it keeps getting better. There was a time when Rust was interesting to me but then C++11 came out. Then they kept improving it
- fouronnes3 4y ago
  C++ has virtually zero tooling and the committee is not interested in ever working on that. Comparing CMake to cargo is like comparing fifth century fireworks to the Space Shuttle. I mean we are getting modules that aren't literally copy paste maybe next year.
  - AnimalMuppet 4y ago
    Given that gunpowder was invented in the 9th century, fifth century fireworks were probably pretty uninteresting...
  - pjmlp 4y ago
    Use Visual C++ and you will have modules today. I have cargo today in C++ via NuGET and vcpkg, and what is great about it, I don't have to compile my depedencies from scratch.
    - joshuamorton 4y ago
      > I have cargo today in C++ via NuGET and vcpkg, and what is great about it, I don't have to compile my depedencies from scratch. To be fair, if you're using a language that has a reasonable compilation story, this is only every a concern the first time you compile.
      - pjmlp 4y ago
        Sure I always need an excuse to go out for lunch.
  - StillBored 4y ago
    "C++ has virtually zero tooling" I read that and I was like WTF, the entire programming ecosystem exists on C/C++ tooling. But from your perspective its modules/cargo that is the tooling? That is IMHO an odd viewpoint. As someone who despises the way cargo works, and hates not having long term explicit control over my dependencies (going so far as to track and check them in along with build artifacts) I'm not convinced that the recent toss another random dependency that itself pulls dependencies into the build is a good thing. I like the fact that I have three dozen+ different ways to do regexp's in C depending on my priorities, and that picking one requires cognitive overhead and modifications to source control/etc. Its easy to add a line to a makefile/etc to pull crap off github in C, so its not like this is a hard problem to deal with in C/C++ but its one where the scale of the problem allows for optimization. AKA like the dynamic typing argument, making the programmer think about a problem I believe yields a better solution. Its also one where i'm not tied to the whimsy of the library author should I decide to fork or maintain the code long after they have gotten bored or rewritten it 3 different times. I can to this day rebuild code I wrote 20 years ago on a modern machine with little effort. Can you say the same about even 10 year old node.js or python code? Put another way, I spend a little bit more on upfront effort and it pays off long term. And I know i'm in the minority, but its also why repeatedly I've run small teams of a half dozen or so people who's products are ahead of major competitors with teams of 100's+ of engineers.

UncleMeat 4y ago

Syntax migration is easy. It is the semantic migration that is hard.

flohofwoe 4y ago

I'd say the syntax looks like most other modern languages, not just Rust.

pron 4y ago

> Rust (from my biased point of view) is currently on its way to become the standard low-level language The evidence seems to suggest the opposite. Other than a lot of talk on programming fashion publications that are always more aspirational than representative (such as this site) Rust seems to have reached 0.3% of the market [1], up from 0.1% a couple of years ago [2], and while that is ok growth, programming languages with few exception tend to reach, approach, or at least point toward their all-time peak market penetration around age 10, and Rust is already 7. Any language could, of course, be an exception to historical trends, but there's nothing to suggest that is the case. More anecdotal adoption stories are just as bleak. Even at this relatively advanced age, many companies dabble in Rust — as they did in, say, Haskell — but not many established companies have yet to really bet big on it. The only positive is that among the low-level languages discussed on aspirational sites, Rust is, indeed, the most talked-about language, but history also suggests that that is a very bad predictor of long-term market success. [1]: https://www.devjobsscanner.com/blog/top-8-most-demanded-languages-in-2022/ https://www.devjobsscanner.com/blog/top-8-most-demanded-lang... [2]: https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/ https://www.hiringlab.org/2019/11/19/todays-top-tech-skills/

cogman10 4y ago
> programming languages with few exception tend to reach, approach, or at least point toward their all-time peak market penetration around age 10 Notable exceptions from the links you've provided: C#, Java, Go, PHP. All appear to have an upward trajectory today. Javascript has also seen a similar penetration boost when nodejs came on the scene. With rust looking to get integration both into the Linux kernel and GCC, that points to some pretty positive things for the language's penetration. Particular in the embedded world.
- pron 4y ago
  > All appear to have an upward trajectory today. They might have an upward trajectory, but they're not posed to break well beyond their respective records. With the possible exception of Python, how popular a language is at age ten is a reasonable rough indicator of how popular it's ever going to be. At its current growth rate Rust would reach 1% market share at age ten. Again, there can certainly be surprises, but I think it's weird to say that actual current evidence clearly points to success for Rust. On the contrary, to become a success it would need to buck the trend and be quite a surprise. So it could happen, but I don't see much to support the claim that this is what's currently happening. > With rust looking to get integration both into the Linux kernel and GCC, that points to some pretty positive things for the language's penetration. I agree that it shows that the language is taken seriously and isn't dismissed as a possible option, and that that's very good. That indicates that the language isn't an immediate irredeemable failure, but I don't think it's an indicator of future success.

aaaaaaaaaaab 4y ago

>Also, Rust (from my biased point of view) is currently on its way to become the standard low-level language Lol. Gave me a good chuckle!

mbrodersen 4y ago

> on its way to become the standard low-level language It will take a very long time for Rust to get even close to the huge amount of C++ code out there. There are more than 5 million professional C++ developers employed around the world today. And that number is increasing. Don’t get me wrong: I like Rust and other attempts to move beyond C++. But don’t underestimate how much C++ code has been written the last 30+ years. And new C++ projects are started every single day. There are probably more C++ projects started every day than Rust projects. So anything that makes it possible to move beyond C++ while being 100% interoperable is good news.

zozbot234 4y ago
Carbon is not trying to be 100% interoperable with C++. It's trying for some fuzzy notion of "good enough" - that's really not very different from what Rust is trying to do with cxx-rs. Yes there are serious challenges and I've described them here, but they're not impossible to address while staying with Rust.
- lenkite 4y ago
  > Carbon is not trying to be 100% interoperable with C++ It's trying for some fuzzy notion of "good enough" No, it's clearly not a "fuzzy" notion of interop even in the most uncharitable interpretation. Your assertion is mis-information. "Seamless, bidirectional interoperability with C++, such that a library anywhere in an existing C++ stack can adopt Carbon without porting the rest." Support mixing Carbon and C++ toolchains Compatibility with the C++ memory model Minimize bridge code Unsurprising mappings between C++ and Carbon types Allow C++ bridge code in Carbon files Carbon inheritance from C++ types Support use of advanced C++ features Support basic C interoperability
  - zozbot234 4y ago
    And that's still not 100%. The Carbon devs are very clear that there will be some C++ code that Carbon is unable to interoperate with.

BearOso 4y ago

I don't know about it becoming the standard LL language yet. There's a lot of memory management in low level programming, and peppering everything with unsafe seems like it'd be tedious. I'd rather just write in C to begin with. I'm interested in seeing how things are handled with the Linux kernel's rust support, if it ever becomes more than a proof of concept. That will be a good viability test.