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

Carbon Language: An experimental successor to C++

github.com

Post reply on HN
Print view View original

361–370 of 521 posts

Re: Carbon Language: An experimental successor to C++

#361

Post by adev_ »

fouronnes3 wrote: post #134
mempko wrote: post #130

Earlier quoted context omitted.

The problem with C++ is it keeps getting better. There was a time when Rust was interesting to me but then C++11 came out. Then they kept improving it

C++ has virtually zero tooling and the committee is not interested in ever working on that. Comparing CMake to cargo is like comparing fifth century fireworks to the Space Shuttle. I mean we are getting modules that aren't literally copy paste maybe next year.

> C++ has virtually zero tooling and the committee is not interested in ever working on that

This sentence makes no sense at all:

1 - Tooling does not stop to the build systems

2 - The tooling set in C++ (and C) has been built over decades. It is indeed not a single shiny CLI cargo-style but it several order of magnitude bigger and more powerful than anything you will ever find in any other programming language: memtracers, profilers, thread sanitizers, debuggers, disassemblers, static analyzers, packages managers, bindings generators, ABI checkers, crash analyzers, loggers and I am sure I forget still many others.

Re: Carbon Language: An experimental successor to C++

#362

Post by ArrayBoundCheck »

dixego wrote: post #98
beeforpork wrote: post #50

Why use Rust syntax (fn, x:Type, ...)? Syntax is one thing that is not so well-designed in Rust (in my opinion). Also, with the stated goals, it seems a bit unnecessary to overhaul C++ syntax, but then I found no explanation why syntax was changed. So what's wrong with C++ syntax if your goal is a successor of C++? This now looks to me like a Rust-- instead of a C++++, which is a picture they might not want to give r…

From the "Why build Carbon?" section: > The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like a modern generics system, modular code organization, and consistent, simple syntax. That last part seems to imply that the authors don't consider C++ syntax to be a good foundation for a modern successor language, so they chose to…

They could have went the C# route, but didn't

Re: Carbon Language: An experimental successor to C++

#363

Post by zozbot234 »

pkasting wrote: post #358
tialaramex wrote: post #294

Earlier quoted context omitted.

Sure, the Chrome security team have got a problem, Rust has a solution, if somebody comes along with a better solution why wouldn't you. But, right now Carbon doesn't have a better solution, it only has an ambition to build an incremental path toward being able to be a solution. Importantly it has an ambition but it has no proposal for how to get there. There are other safe languages, but AFAIK none of them launched…

I work on the Chrome team. Safety is not the only goal for the codebase. There's also things like readability, maintainability, performance, and correctness. Finally, there's the need to chart a course towards how you get there. Rust provides many of these, but not much of an incremental path there. Carbon aims to provide many of these, but not as much safety as Rust (likely, even in the future). The upshot: there ar…

It's a web browser. If safety is not the one overarching concern when developing a web browser, of all things, the Chrome dev team is clearly dropping the ball.

> Rust provides many of these, but not much of an incremental path there

The incremental path is provided since you can refactor stuff into Rust at a scale as tiny as individual functions. Even an "unidiomatic", C/C++-like interface to "unidiomatic" unsafe Rust code is better than the status quo where no safe subset of the language can possibly exist.

The Rust borrow checking approach does a very good job of establishing memory safety in a way that respects compositionality and module boundaries; most proposed alternatives do not engage with this obvious concern at all. Pre-"Modern" C/C++ idioms are inherently unviable because proving them safe is a global, program-wide concern. The Core C++ Guidelines developers are quite aware of this, which is why Guidelines-compliant code is quite rusty already.

Re: Carbon Language: An experimental successor to C++

#364

Post by mihaic »

wiseowise wrote: post #286
mihaic wrote: post #133

Am I the only one that doesn't like this direction for the syntax? This was the main reason why I never got into Rust, it was just too different without any obvious reason. It's strange that I actually enjoy working with type annotated modern Python though. I'll now go away for a few years until the dust settles.

What exactly you don’t like about it?

Just a lot of small things stand out:

- function and variable types are harder to visually parse for me. The keyword to declare a variable and the type put the varible name in the middle for instance.

- the "fn" keyword is terrible, just to save on characters. Honestly, any keyword should have vowels and is pronounceable. Python has "def", I would have been fine with "func" as well

- type annotation for templatization make is hard to read where the real arguments begin (for me). I puts info on the type in another place than the variable itself.

- "Mutable" feels like it should be all lowercase, to stand out.

In general, I know there are areas to improve on C++ syntax, especially on modules, but some choices seem different just for the sake of difference.

Re: Carbon Language: An experimental successor to C++

#365

Post by Maursault »

Why "Carbon?" I just want to known if I a missing something subtle... or if it is just C, the symbol for carbon.

Developers need better and unique names for their products. I realize no one will care because no one is using it anymore, but Carbon was already taken by Apple for their Objective C API.[1] That both are pretty much in the same space with the same name is sure not to cause any confusion.

[1] https://en.wikipedia.org/wiki/Carbon_(API)

Re: Carbon Language: An experimental successor to C++

#366

Post by zozbot234 »

mihaic wrote: post #364
wiseowise wrote: post #286

Earlier quoted context omitted.

What exactly you don’t like about it?

Just a lot of small things stand out: - function and variable types are harder to visually parse for me. The keyword to declare a variable and the type put the varible name in the middle for instance. - the "fn" keyword is terrible, just to save on characters. Honestly, any keyword should have vowels and is pronounceable. Python has "def", I would have been fine with "func" as well - type annotation for templatizatio…

It's pronounced "fun", they just didn't want to make it too explicit because coding isn't always fun.

Re: Carbon Language: An experimental successor to C++

#367

Post by kllrnohj »

mrits wrote: post #75
cogman10 wrote: post #21

If you are like me and wondering "What makes carbon different from Rust or Zig? 1. The ability to interoperate with a wide variety of code, such as classes/structs and templates, not just free functions. 2. A willingness to expose the idioms of C++ into Carbon code, and the other way around, when necessary to maximize performance of the interoperability layer. 3. The use of wrappers and generic programming, including…

Designing a language to interop well with a single language is short sighted in my opinion. I want a clean ffi that I know will be able to iterop with Swift, Typescript, C#, C++, C, python etc... In my current project I'm currently using Rust/protobuff to do all of this and it rarely gets in my way of how I want to do things.

It's funny you list typescript there given typescript itself is a language designed entirely around interop with a single other language.

Kotlin is another such widely liked language that was designed entirely around interop with a different language.

Re: Carbon Language: An experimental successor to C++

#368

Post by nicoburns »

jb1991 wrote: post #315
Jensson wrote: post #314

Earlier quoted context omitted.

For java the virtual machine provides the GC for everything, but then you can only use JVM libraries and not libraries in other languages. The reason C and C++ libraries can easily be included in basically any other language is that they don't have a GC, so there are no such issues, just call the functions and things works fine.

> Major problem with GC languages is that it is horribly to link against libraries that ships with a GC. I'm curious which GC languages do this. The most popular ones that come to mind for me are anything on the JVM, JS, and Go, and I've never heard anyone point this out about them.

Libraries work fine in GC languages if they're written in that language. But you can't easily take a library written in Java and import it into your Python project (you can do it, but it's not efficient, and the more languages you include the less efficient it gets). Whereas libraries written in C/C++/Rust/etc can have binding in every language without issue. Consider libraries like zlib or curl and SQLite that are ubiquitous is across every language ecosystem. Those are the libraries that need (well, greatly benefit) from being written in a non-GC language.

Re: Carbon Language: An experimental successor to C++

#369

Post by nicoburns »

pron wrote: post #226
Sebb767 wrote: post #72

Earlier quoted context omitted.

The syntax looks a lot like Rust, though. I'm surprised they made such a break when there explicit goal is to make migration from C++ as easy as possible. Also, Rust (from my biased point of view) is currently on its way to become the standard low-level language, so I'm not too confident that Rust-but-with-OO is enough of a selling point.

> Rust (from my biased point of view) is currently on its way to become the standard low-level language The evidence seems to suggest the opposite. Other than a lot of talk on programming fashion publications that are always more aspirational than representative (such as this site) Rust seems to have reached 0.3% of the market [1], up from 0.1% a couple of years ago [2], and while that is ok growth, programming langu…

I think the low-level world moves slower.

Key players like Microsoft and the Linux Kernel developers are only just beginning to pick up Rust. It's been considered promising, but immature for much of it's lifetime, and it's only recently gotten to the point that it's considered mature enough for core infrastructure projects (which are really it's forte) in the last couple of years.

Re: Carbon Language: An experimental successor to C++

#370

Post by astrange »

unethical_ban wrote: post #239
gpderetta wrote: post #124

Earlier quoted context omitted.

while we have you here, may I ask why is it called Carbon? It is because the symbol for atomic carbon is C ? :)

To make it as hard to search for solutions online as it is for "go".

Shouldn't be a problem if they're both created by a search engine company.
Post reply on HN