Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Launches Carbon, an Experimental Replacement for C++

thenewstack.io

Post reply on HN
Print view View original

141–150 of 243 posts

Re: Google Launches Carbon, an Experimental Replacement for C++

#141

Post by BitwiseFool »

emehex wrote: post #121
DiabloD3 wrote: post #112

Earlier quoted context omitted.

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.

Re: Google Launches Carbon, an Experimental Replacement for C++

#142

Post by scotty79 »

KptMarchewa wrote: post #76
Terretta wrote: post #66

How to make your replacement for a C language Google-able: name it after an API for a C language: Carbon was one of two primary C-based application programming interfaces (APIs) developed by Apple for the macOS (formerly Mac OS X and OS X) operating system. Compare also keywords or key terms: Carbon will be built on a foundation on modern programming principles, including a generics system, that would remove the need…

Carbon API is so old that this pretty much isn't issue. You have to google explicitely for "Carbon API" for it to show up. Whether even now, "carbon programming" or "carbon code" give results for Carbon language - and some other non-c++ libs named Carbon. Even "carbon" by itself gives me some Carbon language links.

Don't forget they named language go, while language named Go! already existed.

They just don't care.

https://en.m.wikipedia.org/wiki/Go!_(programming_language)

Re: Google Launches Carbon, an Experimental Replacement for C++

#143

Post by mynameisash »

melling wrote: post #4

I’m a big fan of ‘var’ and ‘let’ in Swift. Easier to identify mutable vs immutable variables. I believe Carbon uses the same convention? https://github.com/carbon-language/carbon-lang Helps with quick auto-completion, and someday when I get to dictate code, fewer mistakes.

I admittedly only have moderate experience in Scala, which uses `var`/`val` -- but I am glad Rust opted for `let`/`let mut` instead of a single word to make the distinction. It feels much easier to distinguish between mutable and immutable values.

I wonder if `var`/`let` is easier because the words aren't as close as `var`/`val`? Or maybe it just gets easier with experience?

Re: Google Launches Carbon, an Experimental Replacement for C++

#145

Post by rvz »

UncleMeat wrote: post #95
DiabloD3 wrote: post #61

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 kno…

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.

Re: Google Launches Carbon, an Experimental Replacement for C++

#147

Post by UncleMeat »

chrsig wrote: post #129
drawkbox wrote: post #49

The example to me looks like C++ is still nicer, I don't get the hate on C++ but then again most of the native work I do is gamedev. The benefit that C++ and Carbon can run together is a nice feature. It is like Objective-C++ (using ObjC + C++ together) or Swift/ObjC that worked well in gamedev as well when you needed to wire in a C/C++ game engine into iOS. For Android the NDK. I think any C++ replacement has to be…

I work on a project that is a c & c++ codebase where there isn't really a great reason for it being in those languages vs a language "with a runtime" the hate is pretty simple: - compile times - vague compiler errors - template syntax is incredibly hard to read, especially when using techniques like sfinae, or trying to write functional interfaces - really bad names for idioms (raii, sfinae, pimpl) - really bad names…

Many of these things are indeed true problems. But they miss the big one: C++ is just plain unsafe. Applications written in C++ that process untrusted input are serious security risks. The industry needs a path a future where no C++ code is processing untrusted input. Rust is (mostly) safe, but the path to shift gazillions of lines of C++ to safe Rust is painful.

Re: Google Launches Carbon, an Experimental Replacement for C++

#148

Post by quietbritishjim »

gpderetta wrote: post #80
jeffbee wrote: post #43

Earlier quoted context omitted.

The move situation would be less confusing to newcomers if they had called it what it really does, std::become_rvalue_reference or something.

alternatively move should have been a real move: template T std::move(T&& t) { return T(static_cast ::type&&>(t)); } But it would have had performance implications.

Interesting - that prevents one of the two cases.

Given fn(const Foo&) (or fn(Foo&)), your implementation would stop fn(move(x)) from compiling.

But given fn(Foo) and const Foo x, your implementation would still allow fn(move(x)) to compile and perform a copy.

Re: Google Launches Carbon, an Experimental Replacement for C++

#149

Post by lifewallet_dev »

tekknik wrote: post #70
nazgulsenpai wrote: post #36

Earlier quoted context omitted.

Nim also uses 'var' and 'let' for mutability. I like it as well.

knowing neither of these languages i’d rather it be labeled something more clear as neither one of those screams immutable to me. the immutable variant should use the ‘const’ keyword instead.

Well Nim also has `const` the difference is that `const` must be evaluated in compile time, but `let` is just to prevent reassignments, more info: https://nim-lang.org/docs/tut1.html#constants which is different than what JavaScript does.

Re: Google Launches Carbon, an Experimental Replacement for C++

#150

Post by UncleMeat »

ho_schi wrote: post #30

> Frustrated by the slow evolution I think already the very first sentence is already wrong. 1998 ISO/IEC 14882:1998 C++98 2003 ISO/IEC 14882:2003 C++03 2011 ISO/IEC 14882:2011 C++11 2014 ISO/IEC 14882:2014 C++14 2017 ISO/IEC 14882:2017 C++17 2020 ISO/IEC 14882:2020 C++20 Where C++11 and C++20 are huge major upgrades.

There are new versions and C++ has had a lot more love recently than in the past, but a lot of valuable changes are made impossible by the committee because of compatibility concerns.
Post reply on HN