Google at it again... Carbon!

[SiliconWizard]

https://github.com/carbon-language/carbon-lang

Yes. Yet another attempt from Google to come up with a C++ successor. Go and Dart were just appetizers.
This one is kind of a copycat of Rust from what I've seen so far, without the whole borrowing stuff and some other features, but otherwise it's very close, even syntax-wise.

Given that reducing our "carbon footprint" is all the rage lately, I guess the naming here is a bit unfortunate from a marketing POV. (Then again, one might say that the same applies to Rust. Yeah, good names are hard to find. Or maybe it's just intentional.)

So, what will be the next one after Carbon?

[ataradov]

I really dislike how a lot of modern languages are designed for the parsers. What is this "fn" and "var" nonsense? It is not needed and just adds extra stuff to type.

Single return value in 2022 is a huge fail.

Other than this, it looks half baked at the moment. I'm sure google can force their engineers to use that for internal needs, I seriously doubt it would go anywhere for wider adoption.

[KE5FX]

Parsing is something that modern language designers have forgotten how to do.  I took one look at Go and noped out of it as soon as I discovered that it enforces K&R bracketing "because that way we don't have to require semicolons," as a Go advocate put it.

 

[golden_labels]

I wonder what is the reason for existence of that language. Other than building financial value of course. Project goals start with “having a code of conduct” — not exactly what I expect to be the primary motivation for a new language. The rest of the documents give no explanation either.

There is a lot of talk about giving the developer control over performance and low-level access. But the language seems to not address the issues both C and C++ have in that matter: operation ordering and timing. Unless the language is guaranteed to never optimize code and be a high-level assembler, but it doesn’t seem like it’s among its goals. Are they meaning having precisely defined numeric types? Java had those for 24 years,⁽¹⁾ both C and C++ have those if you want to enforce a particular environment, and TBH thinking about solving that kind of “horrible problems” was something I was concerned with in college, 2nd year.

As for being explicit with keywords, I do not see a problem. That seems like forcing programmers into parser’s perspective, sure. But keep in mind: as the syntax grows in complexity that will prevent ambiguities, which would lead to introducing weird constructs just to satisfy parser. In the end it’s likely to be constrained by the parser anyway: they may do it cleanly now or ducktape later. Having a parser-friendly syntax also helps development of new tools.

⁽¹⁾ Even longer, if we ignore floating point types.

[ataradov]

I bet this is primarily for internal use. Having a reference compiler that you fully control allows for all sorts of interesting corporate stuff. In that case being close to C++ is a benefit. Being able to address a few issues here and there is nice, but you don't want to go wild, at least at first.

And it makes automated code converters easier to make. And they published those tools before any documentation.

[magic]

I wonder what is the reason for existence of that language. Other than building financial value of course.

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. Unfortunately, the designs of these languages present significant barriers to adoption and migration from C++. These barriers range from changes in the idiomatic design of software to performance overhead.

Carbon is fundamentally a successor language approach, rather than an attempt to incrementally evolve C++. It is designed around interoperability with C++ as well as large-scale adoption and migration for existing C++ codebases and developers. A successor language for C++ requires:

    Performance matching C++, an essential property for our developers.
    Seamless, bidirectional interoperability with C++, such that a library anywhere in an existing C++ stack can adopt Carbon without porting the rest.
    A gentle learning curve with reasonable familiarity for C++ developers.
    Comparable expressivity and support for existing software's design and architecture.
    Scalable migration, with some level of source-to-source translation for idiomatic C++ code.

With this approach, we can build on top of C++'s existing ecosystem, and bring along existing investments, codebases, and developer populations. There are a few languages that have followed this model for other ecosystems, and Carbon aims to fill an analogous role for C++

Also,

Interoperate with your existing C++ code, from inheritance to templates
Fast and scalable builds that work with your existing C++ build systems

I don't know how far they will get with it, but can you name any other language which even attempts to address these concerns?

R**t, for example, is simply "rewrite everything and forget that C++ ever existed".

[magic]

Enables automatic, opt-in type erasure and dynamic dispatch without a separate implementation. This can reduce the binary size and enables constructs like heterogeneous containers.

Somebody is finally starting to think, unlike certain earlier languages "better than C++"

[langwadt]

So, what will be the next one after Carbon?

c, when they realise they have to get stuff done and not play around trying to get this weeks new language

[Marco]

R**t, for example, is simply "rewrite everything and forget that C++ ever existed".

There's a lot of other ways to combine code than finegrain linking. For a language which tries to have a strictly memory "safe" subset, it's not really an option. Everything gets tainted, so what's the point?

A memory safe system programming language has a raison d'etre and can be justified at least some of the time, carbon to me doesn't seem to be worth the effort. Just use C or a C++ subset.

[magic]

There's a lot of other ways to combine code than finegrain linking. For a language which tries to have a strictly memory "safe" subset, it's not really an option. Everything gets tainted, so what's the point?

The point is that they would spend an eternity on regression testing if they were to rewrite large codebases from ground up in a new language. And half an eternity plus a performance hit if they were to split them into mixed-language submodules with message passing, databases or whatever in between.

A memory safe system programming language has a raison d'etre and can be justified at least some of the time, carbon to me doesn't seem to be worth the effort. Just use C or a C++ subset.

Safer fundamentals, and an incremental path towards a memory-safe subset

BTW, I'm surely not a Google fanboy and neither a Carbon fanboy or anything like that.
But answers to most of the criticism here can be found right in their FAQ, so

[Marco]

The alternative is still finding simple buffer overflows in their code even though they run every static analysis tool known to man in their build process.

Carbon doesn't have a safety at all now, it's not designed for it. Praying they can jury rig it in later without having to do a ton of recoding regardless is optimistic.

[SiliconWizard]

As I said, at this point, it doesn't look like a lot more than just a dumbed-down version of Rust, more approachable for the masses, even down to the syntax and maybe 75% of its features.

[SiliconWizard]

I think that was already posted before, but here goes, pretty hilarious:



And, if you want some rather "strange" content that may also trigger some laughter, but which is not meant to, you can watch some of the CppCon talks. Or even some of the Rust channels where people spend hours explaining how to solve relatively trivial problems with Rust. Pretty entertaining.

[Fixpoint]

I really dislike how a lot of modern languages are designed for the parsers. What is this "fn" and "var" nonsense? It is not needed and just adds extra stuff to type.

I sincerely doubt that this has anything to do with the parser. As a compiler guy and language designer who has designed and written many parsers by hand, I can confidently say that writing parsers for this kind of stuff is a mere technicality. If your syntax is so ambiguous that writing the parser by hand becomes difficult, you can even generate it automatically.

A serious language designer shouldn't let a rather banal technicality like a parser dictate the language design. Of course, writing good parsers is a complex topic, but the reason for that is *not* that the actual parsing of the syntax is difficult but that good, meaningful *error recovery* is difficult.

The reasons for keywords like "fn" and "var" should stem from computer-scientific language design considerations. Of course, it's ok if you don't like them and would leave them out, but I would be pretty sure that they serve a purpose other than making the parser "simpler" (which it really does NOT become because the true reason for difficulty is, as I pointed out, error recovery and reporting).

Keep in mind that an "obvious simplification" (meaning a simplification that seems obvious at first glance) can be the exact opposite, namely a deep complication. In such cases, difficulties and "logical impedances" may arise at places where you never expected them. A programming language is an extremely complex formal system where all the syntactical parts must play along with BOTH semantical AND practical considerations.

[SiliconWizard]

I don't particularly mind those extra keywords at all. If anything, I find them a bit too shortened for no useful reason other than saving a few keystrokes, something that is one of my pet peeves. (Damn, buy a good keyboard and use a good editor, and stop whining.) Clear keywords punctuate source code much better than obfuscate syntax IMHO, no matter how used to it you are. Source code is for humans. Machines can swallow horrendous shit correctly as long as it's unambiguous. And yes, parsers are not rocket science. They are definitely a solved problem and have been for a long time now.

So, that's absolutely not the problem I have with those new languages (as I said, if anything I find the abbreviated keywords unreasonably short for no useful reason other than address the whining crowd's "It's too verbose, I won't use it. Ha!")

As I suggested, just have a look at the specifications of those languages - an honest, and deep enough look. And then go watch talks and learning videos and see for yourself what is wrong. That will eventually pop up.

[magic]

There are probably only a few parsers in the world capable of understanding all of C++.
Try writing another one and then tell us it's not a big deal

[Fixpoint]

There are probably only a few parsers in the world capable of understanding all of C++.
Try writing another one and then tell us it's not a big deal

We are talking about *parsers*, not compilers. While writing a C++ parser is certainly no small task, it is still not that big a problem. Writing a C++ compiler is a different story.

[eti]

Here's a tip for a happy technology life: If Google made it, avoid it. They are like children with ADHD, and abandon things RAPIDLY.

[50ShadesOfDirt]

I like playing with OS's ... doesn't matter whose, nor how obscure, etc. If I can get it to load and kick the tires a bit, it was both a success, and fun. While I have a few OS's that are daily drivers, the rest is just ... experimental and fun!

Must be folks like that in programming? Who want something new to kick the tires on ... They might use C++, Python, or whatnot to make a living, but at home, or on lunch breaks, *Carbon*-ize it ... that sounds fun (and green as a bonus)?

[eti]

"Debating" (arguing) over which prog lang is "best" is like debating which shoes, clothes, food, movies are "best"; it's a subjective choice. They ALL compile down to binary, and the only sane human level above that is ASM... so learn ASM, for the education alone - even if you end up never using it - and then stack up on top of that.

[Fixpoint]

"Debating" (arguing) over which prog lang is "best" is like debating which shoes, clothes, food, movies are "best"; it's a subjective choice.

No. As a computer scientist who has been developing both enterprise and some embedded software for 28 years in many different languages, I can only say that this has nothing to do with "subjective choice". There are very serious mathematical and practical differences between programming languages, mainly

* what abstractions they support,
* how far their support for formal verification goes, and
* what non-functional characteristics they have.

Telling people that choice of programming languages is "subjective" is not only grossly wrong but also irresponsible.

They ALL compile down to binary

That's completely and uttlerly non-factual. Honestly, please.

[dferyance]

There are glaring problems in C++ so it is understandable to want to improve on it. But most languages that claim to be a successor to C++ fail to understand the strengths of the language. The D programming language is one rare exception. Go, Swift, Kotlin, Rust: yeah they have their own merits, but don't incorporate the advantages of C++. Just due to past attempts, I have my doubts that carbon will have learned to do it right, but maybe. It is always worth a try. There appears to be some promise at least on paper.

I like that C++ is an ISO standard, that there are multiple compilers for it, that it isn't owned by a company. That brings with it plenty of downsides but is fairly unique. It takes a massive amount of time and effort to get a language so this level.

[eti]

"Debating" (arguing) over which prog lang is "best" is like debating which shoes, clothes, food, movies are "best"; it's a subjective choice.

No. As a computer scientist who has been developing both enterprise and some embedded software for 28 years in many different languages, I can only say that this has nothing to do with "subjective choice". There are very serious mathematical and practical differences between programming languages, mainly

* what abstractions they support,
* how far their support for formal verification goes, and
* what non-functional characteristics they have.

Telling people that choice of programming languages is "subjective" is not only grossly wrong but also irresponsible.

They ALL compile down to binary

That's completely and uttlerly non-factual. Honestly, please.

I agree, upon reflection, that the majority of that post was a little (or a lot) based on my inexperience, as I am not a programmer.


However, your last quotation - that makes no sense - do you think the silicon speaks ENGLISH? Processors talk IN BINARY - whether or not you have a known compilation process, or the interpreted language silently compiles the source on the fly, it ALL compiles down to binary; it can't NOT do so, otherwise how do you propose that the transistors on the die, work? NO other way except the base level fundamental mechanism of transistors arranged into logic gates.

[ataradov]

The high level language design affects how efficient your final binary could be.

C does not care about array bounds checking, it will just access members outside the array. Really fast binary code though. Swift has array bounds checking. Each array access has to compile into a sequence of instructions that first check that the index is valid for a given array. Safe, but slow (relatively) code.

So, "everything is binary" is a true, but completely meaningless sentence.

This is why Rust talks a lot about "zero cost abstractions". They are purposefully designing high level language concepts keeping in mind how they would be implemented in the final binary code.

And if you really think that you can write assembly code that is as efficient as code generated by the compiler, then you really have no idea what you are talking about. Given low level architectural optimizations in the modern CPUs, it no longer possible to write sufficient chinks of code that would be faster than compiler generated code. There is just too much low level stuff to keep in mind and adjust for individual CPU architectures.

[eti]

So, "everything is binary" is a true, but completely meaningless sentence.

It's only "meaningless" until you get to wanting the chip - the very thing that runs the show - to understand it. Silicon dies don't speak anything BUT binary, and even then they are not "speaking" it, it's merely voltages leaning against MOSFETS, causing them to change state when the correct combination is reached.

I am not meaning to appear pedantic, but they LITERALLY CANNOT function another way.


[EDIT]: Besides, for all this "digital" stuff, and our human arrogance of "advanced digital technology", it's STILL all analogue components strung together at a minute scale; there is no intrinsic "digital-ness" in physics, it is a human design, 0101 0101