Hacker News Reader

Comment by DiabloD3 | Hacker News Reader

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.

View on HN

> 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-car...

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."

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.

> 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

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.

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-popula...

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.

I love Swift. And Xcode 14 is great! What don't you like about it?

This might be difficult to communicate, but I feel like XCode has me spending way more time and clicks on window/pane management than other IDEs. Apple's design philosophy is to keep things minimalist and hide controls which are not in active use. This means I find myself going back to click on small buttons in order to bring up a pane that will finally allow me to just to click on one icon I need to perform some task. Whereas in other IDEs can I force an icon to stay visible and spend much less time traversing the application's UI.

For an analogy, imagine using a workbench and being forced to put each tool back into it's respective drawer once I am done using it - even though I will certainly need to use the tool again very soon. Whereas other IDEs let my workbench be as customized and cluttered as I want it to be.

The only people I've seen claim Xcode is great have never used virtually any other modern IDE, which basically all run on your hardware/OS of choice. But the IDE isn't the worst of it, the command line tooling is woeful. That the same company could come up with a great language but provide so little incentive for anyone to use it baffles me.

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.

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).

I'm not sure that's a great take. Swift's support for Linux is reputed to be bad (not sure what the actual case is) and I think that really hinders adoption. It's a nice language that is very expressive. I would use it for small projects over rust as it has a large standard library if not for the cross-platform difficulties.

It became a kitchen sink language similarly to C++. For all the hate Java gets, they did tackle language development very well - wait a bit for other, niche languages to be your testing ground of new features, and only add what sticks. Swift literally has all the features you can find in today’s modern languages, and they have some inconsistent interactions with each other. Also, even this litany of features isn’t enough to make SwiftUI implementable only as a Swift library, it uses some specifics not available in the language otherwise.

And also, as most apple dev tools, it is the only modern language whose compiler failed under me (other than being slow as hell) - I have never gotten a type inference timed out error in other languages, even though it has been around for a time :D

As for growing a language, this is a must watch (bear with the presenter for the bit, you will soon understand why he talks strangely in the beginning): https://m.youtube.com/watch?v=_ahvzDzKdB0

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.

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.

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.

interesting, what kind of new syscalls are these? any plan to upstream?

Kind of a form of cooperative multitasking: https://news.ycombinator.com/item?id=24688225

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.

> 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.

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.

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.

> 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.

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

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

Reply on news.ycombinator.com