4 ms·

I am very bullish on Carbon. Using C++ semantics will make switching and integration much easier.

galangalalgol 4y ago
Its abstractions and memory safety aren't zero cost though. I do wish ffi between rust and c++ was easier, having just fought that battle again recently, but I'm not willing to give up performance over it. I think it is telling that carbon came out of google, and rust came out of mozilla, but rust is what google is using to make android safer, and to create things like kataos.
- surajrmal 4y ago
  kataos is a greenfield project. Carbon isn't being created for greenfield applications, it's being created to deal with maintenance of large existing c++ projects. The carbon repo publicly mentions that you are better off using rust otherwise. Using rust in android is indeed interesting, but it's largely not hindered by legacy interop with c++ there either. Rust has struggled to overcome the challenges with c++ interop in chrome. I fear other c++ codebases face this same struggle.
  - galangalalgol 4y ago
    That makes a lot of sense. It is hard enough on small codebases. I'm very familiar with some c++98 behemoths and I can't think of any good ways to go about it piecemeal. The interop truly is painful.
tialaramex 4y ago
Carbon got one obvious thing right: Culture. The most important thing Rust has that C++ doesn't is the right culture and so it was correct to focus there very early. Unfortunately on the technical side it still feels as though the intent is to add safety, and IMNSHO that's not a good idea, you want to design safety in from principle, when it's layered on later the resulting joints and discontinuities always end up causing problems. On the other hand I am even less confident Cpp2/ CppFront has the right idea. There's no sign that Herb Sutter groks the culture problem and he's not as focused on safety, preferring to see this in part as a vehicle to give all Herb's rejected C++ proposals a second chance. As WG21 convenor and as an otherwise important person in the C++ community Herb has opportunities for Cpp2 that don't exist for Carbon, but if this language isn't enormously safer than C++ I don't see the point. Val certainly has the "from principle" thing. Like Rust there's a clear and articulable rationale for why this way to do things is safe. I don't know much about Val's culture, and of course like these other 2022 "successors" it's very young.
ChubbyGlasses 4y ago
Same, I was really hopeful that Rust was going to fill the void of a modern systems language (been following it since around 0.6), but judging by the direction it's been headed the since 1.0, state of libs and the ecosystem, and the general community sentiment, I've kinda lost hope at this point. To quote Carbon's readme, "barriers range from changes in the idiomatic design of software" (emphasis mine). What took the cake for me though, was a post a couple weeks ago where people were griping about Go's error handling (if err != nil) when Rust is, at best, no better than Go (e.g if you want to add any context to your error), or just objectively worse off (? operator moves all your error handling logic to a separate, completely different part of your code base).
- xedrac 4y ago
  > people were griping about Go's error handling (if err != nil) when Rust is, at best, no better than Go Have you used Rust in a non-trivial context recently? I have a few minor gripes about Rust's error handling, but Go's error handling isn't even in the same ballpark. Your complaint about the ? operator is moot, because you can easily use "match", "if let", "unwrap_or_else()", etc... to handle the errors in place. ? just gives you the convenience of mapping/propagating an error, which is desirable in some situations.
  - ChubbyGlasses 4y ago
    > "match", "if let", "unwrap_or_else()", etc... all different ways to write `if err != nil`, none of them are better than the other > mapping/propagating an error which is literally what i said "moves all your error handling logic to a separate file" have you written any long-term maintainable code? comments like yours is why i've lost hope in rust and the community; you don't even understand the challenges large code bases face and yet continue with baseless zealotry.
    - deleted 4y ago
      [deleted]
    - xedrac 4y ago
p0nce 4y ago
But this is exactly why we have C++ in the first place, you could port your C code to cfront without doing any effort.

Its abstractions and memory safety aren't zero cost though. I do wish ffi between rust and c++ was easier, having just fought that battle again recently, but I'm not willing to give up performance over it. I think it is telling that carbon came out of google, and rust came out of mozilla, but rust is what google is using to make android safer, and to create things like kataos.

surajrmal 4y ago
kataos is a greenfield project. Carbon isn't being created for greenfield applications, it's being created to deal with maintenance of large existing c++ projects. The carbon repo publicly mentions that you are better off using rust otherwise. Using rust in android is indeed interesting, but it's largely not hindered by legacy interop with c++ there either. Rust has struggled to overcome the challenges with c++ interop in chrome. I fear other c++ codebases face this same struggle.
- galangalalgol 4y ago
  That makes a lot of sense. It is hard enough on small codebases. I'm very familiar with some c++98 behemoths and I can't think of any good ways to go about it piecemeal. The interop truly is painful.

tialaramex 4y ago

Carbon got one obvious thing right: Culture. The most important thing Rust has that C++ doesn't is the right culture and so it was correct to focus there very early. Unfortunately on the technical side it still feels as though the intent is to add safety, and IMNSHO that's not a good idea, you want to design safety in from principle, when it's layered on later the resulting joints and discontinuities always end up causing problems. On the other hand I am even less confident Cpp2/ CppFront has the right idea. There's no sign that Herb Sutter groks the culture problem and he's not as focused on safety, preferring to see this in part as a vehicle to give all Herb's rejected C++ proposals a second chance. As WG21 convenor and as an otherwise important person in the C++ community Herb has opportunities for Cpp2 that don't exist for Carbon, but if this language isn't enormously safer than C++ I don't see the point. Val certainly has the "from principle" thing. Like Rust there's a clear and articulable rationale for why this way to do things is safe. I don't know much about Val's culture, and of course like these other 2022 "successors" it's very young.

ChubbyGlasses 4y ago

Same, I was really hopeful that Rust was going to fill the void of a modern systems language (been following it since around 0.6), but judging by the direction it's been headed the since 1.0, state of libs and the ecosystem, and the general community sentiment, I've kinda lost hope at this point. To quote Carbon's readme, "barriers range from changes in the idiomatic design of software" (emphasis mine). What took the cake for me though, was a post a couple weeks ago where people were griping about Go's error handling (if err != nil) when Rust is, at best, no better than Go (e.g if you want to add any context to your error), or just objectively worse off (? operator moves all your error handling logic to a separate, completely different part of your code base).

xedrac 4y ago
> people were griping about Go's error handling (if err != nil) when Rust is, at best, no better than Go Have you used Rust in a non-trivial context recently? I have a few minor gripes about Rust's error handling, but Go's error handling isn't even in the same ballpark. Your complaint about the ? operator is moot, because you can easily use "match", "if let", "unwrap_or_else()", etc... to handle the errors in place. ? just gives you the convenience of mapping/propagating an error, which is desirable in some situations.
- ChubbyGlasses 4y ago
  > "match", "if let", "unwrap_or_else()", etc... all different ways to write `if err != nil`, none of them are better than the other > mapping/propagating an error which is literally what i said "moves all your error handling logic to a separate file" have you written any long-term maintainable code? comments like yours is why i've lost hope in rust and the community; you don't even understand the challenges large code bases face and yet continue with baseless zealotry.
  - deleted 4y ago
    [deleted]
  - xedrac 4y ago

p0nce 4y ago

But this is exactly why we have C++ in the first place, you could port your C code to cfront without doing any effort.