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.
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.
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.
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.
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).
> 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.
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.
Not hardly. This comment makes me think you don't have any significant experience with Rust.
> you don't even understand the challenges large code bases face
I've worked in more large code bases than I care to think about, including ones written in Go. In fact, one of the primary reasons I like Rust is because it gives me so much confidence when working in large codes. The compiler is ruthless! Data races won't compile. Forgot to handle a return value? Won't compile. Undefined behavior? Not likely. Async code that looks like sync code? You bet! I'm not hating on Go here; I think it's a fine language. And Rust isn't without its problems.
>continue with baseless zealotry
It's certainly not baseless, but I can see how it would come across as zealotry. I'm simply excited about Rust because it has made my life as a programmer much better.
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.