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

121–130 of 243 posts

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

#121

Post by emehex »

DiabloD3 wrote: post #112
sgjohnson wrote: post #73

Earlier quoted context omitted.

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

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

#126

Post by yakubin »

jcranmer wrote: post #54
yakubin wrote: post #38

Earlier quoted context omitted.

> In Rust, moves are destructive (which simplifies implementions - you don't need an "empty" state) and always bitwise (which is usually fine, so long as they're destructive); and copies are always explicit so you don't have the above problem. I personally think that is all more useful than the borrow checker. Without the borrow checker, this "move-by-default, move is memcpy" semantics would break all hell loose. Dan…

You don't need a full-on borrow-checker to make move-by-default safe. If you can track whether or not a variable has been (definitely) initialized, you can track whether or not a variable has been moved from. It's the same basic logic. And there are languages without full borrow checkers that can do that--Java is the first one that comes to mind.

Don't you need to know when all borrows end? E.g. here:

  fn main() {
      let x = [1, 2, 3];
      println!("{:?}", x);
      let y = x.map(|x| x % 2 == 0);
      println!("{:?}", y);
  }
x is borrowed by println (or rather by code that println expands to) and then it is moved by array::map. The compiler needs to know that before x.map(), x is not borrowed anymore. Otherwise it could be that println actually stored a reference to x somewhere and now you have a dangling reference possibly breaking type-safety (referring to an array of bools through a reference to array of ints, if the map is implemented as an in-place operation).

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

#127

Post by coldcode »

tayistay wrote: post #117
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.

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

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

#128

Post by gavinray »

rjh29 wrote: post #90
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.

It's a good convention. Some languages use val and var, which I always thought was bad ergonomics.

I think JS got it right with "const" and "let"

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

#129

Post by chrsig »

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 for standard library types & functions

- truly arrogant community (notice how the boost website doesn't advertise that it's the easiest to use library -- it's the "most expertly designed")

- class member function declaration is out of control (`virtual const foo bar(const baz& x) const override`)

- defaults are unsafe (mutable by default)

- package management is a nightmare (i've only used conan, which is starting to mature, but still has a limited selection of packages, and seems to constantly break how they do things...because package building for an ecosystem as wide and unstructured as c++ is an intractable problem)

- cmake is the worst dsl ever. the program itself is fine, but the dsl is the worst.

- footguns everywhere (auto vs auto&...but auto* exists, and isn't necessary)

- N different ways of initializing

- it's incredibly hard to teach

- inconsistencies w/ C (brace initialization w/ named fields)

- incredibly subtle things can have a huge impact (class member variable declaration order)

- no standard way to document classes & functions

there are still certainly use cases where it's worth using, but the hate is pretty straightforward to me: it's just more hassle than it's worth most of the time. and there is some inner language struggling to get out that's probably nice to use. There are some nice things about it: notably static destruction.

and yes, some of those are more ecosystem based / my own opinions / not necessarily "the language" -- and there are reasons for why many of the warts are the way they are (backwards compatibility, control over construction order). it's still a giant pain in my ass.

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

#130

Post by sauruk »

DiabloD3 wrote: post #112
sgjohnson wrote: post #73

Earlier quoted context omitted.

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

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.
Post reply on HN