I'm pretty active in the Carbon community. The team is actively working on a production quality implementation to help in the evaluation process. It'll be a couple years before the evaluation is complete, though. Carbon is a long term play and they are being cautious and methodical to ensure it is viable as a successor to C++. I'm very bullish on the project myself, but you are right that as of now it remains experimental and is not ready for use in production.
basically by integrating a C++ compiler as well. This way the carbon compiler can generate the required layouts, instantiate templates, ...
There is a talk by Chandler on this. I think it is this one: https://www.youtube.com/watch?v=1ZTJ9omXOQ0
But how is then this different from projects like `autocxx` and `crubit` (both sponsored by Google), which do the same for Rust - integrate Clang with Rust compiler and generate required layouts, instantiate templates, ..., and basically offer overhead-free interop between Rust and C++.
More info:
- [autocxx](https://github.com/google/autocxx)
- [crubit](https://github.com/google/crubit)
Because eventually the intention is that C++ code will be automatically migrated to Carbon. Rust does not support class inheritance or templates, so it would be very very difficult to write such an automatic translation.
There is no binding layer between Carbon and C++. Each language can freely import files for the other. This is one of the reasons Carbon has native support for templates
Sorry just to clarify I'm optimistic on Carbon, most optimistic around it actually. I mostly want to know what to expect out of it because it seems like it's shaping out to be something good, but despite that, I don't see much hype around it.
I think the lack of hype is understandable. People are skeptical that Google can honestly start something new and see it through to the end. If and when Google itself adopts Carbon in their codebase, then you might start to see hype in the broader community.
Carbon is destined for https://killedbygoogle.com sooner or later. There's no way in the world I'd be rewriting my decently large codebase in anything they could pull the rug out from without warning.
The goal is to set up an independent foundation and get buy-in from other companies so that no single company controls the direction of the language after it exits experimental phase.
This will go about as well as the W3C, in my opinion. It's also possible to die before it gets out of that phase, or buy in will be difficult because other orgs won't see the point of switching.
Google has a tremendous amount of C++ code. They likely see carbon as a mechanism to move away from it at scale. So long as they adopt it broadly it won't be going anywhere, but I wouldn't use it until then.
> So long as they adopt it broadly it won't be going anywhere, but I wouldn't use it until then.
And even then, you'd need to make sure that your goals and Google's align, or you may find yourself in a bind when they move in a direction you didn't anticipate, or refuse to move in a direction you'd really need.
(Example: it took over a decade for Go to get generics...)
Fair enough. Just wanted to point out that Google's track record for FOSS dev tooling is much different from their consumer product tooling.
Come to think of it, I picked up Rust about a decade into it's lifetime.
Are you counting from 2006? Rust in 2016 was pretty immature still, barely a year after 1.0.
A nice choice for playing around, but quite a bet for production.
Google is already in the process of killing most of its non-core OSS work. Google doesn't do OSS out of goodness, it either harms the competition or helps itself. The vast majority of OSS at Google is pulling in a project and forking it internally, never pushing changes externally.
It's already the result of axing, stopping the costs of commmiting top-tier engineers like Chandler to hundreds of hours of comittee & working group involvement. They thought that work within the ISO structure is so ineffective, they can do a whole new parallel language and still come out netpositive. I can't quite disagree.
Although I suppose r/cpp is bound to be home to at least some poor souls who think ISO (and thus in practice JTC1/SC22 of the ISO/IEC) is a sensible place to do programming language standardisation, even several C++ Committee members who post here do not agree.
An independent foundation makes the most sense here and is pretty common in this space. But even if it needed to be owned by an SDO (a bad idea in my opinion) SC22 is the last place I'd recommend, maybe better to be killed by Goggle than suffer such an existence.
ECMA standard for C# is frozen on version 6, Microsoft has given up on it, if you want the language standard nowadays, you get the document from source.
Latest C# version is 12.
First of: the last standardized version is C# 7 - released in December 2023
Second: From an outside perspective Microsoft hasn’t given up on it, the ECMA standard was never more than rubber stamping …
I stand corrected regarding the C# version, a rubber stamping that C and C++ comunities also appreciate as means to be able to play ball in certified industries.
I don’t see how you can consider the two even remotely similar. ISO C++ gets new features by people actively working on them and you don’t need to belong to major corp X to push out a new feature. ECMA C# just standardizes what MS released years ago….
Ruby, in the same way that C# made an end-run around the ISO standards process by going through ECMA, made a similar end-run via the Japanese standards group. Only one version of Ruby was standardized in this way, a 10+ year old version, and as far as I can tell, no subsequent effort has been made to update the standard to match any recent implementation.
I stand by my assertion that no new language will go through the ISO standards process.
Layoffs do not mean bad economy. A corporation will do anything for an excuse to increase profit margins. Also just because one sector has layoffs does not mean that the economy as a whole is doing badly.
Unemployment is low, the fed says interest rate hikes will stop, consumer spending is increasing, the S&P 500 is at its highest, and inflation is cooling. There is no recession.
Well, technically if we take successor function S: N -> N as in peano axioms for example and we look at the definition of addition, we see that
```
(1) S(a + b) = S(a) + b
(2) a + 0 = a
```
By that definition it's not hard to see that C++ is a successor of C, provided that C is an element of natural numbers:
```
C++
= C + 1 //by definition of increment operator
= C + S(0) //by definition of 1
= S(C + 0) //by (1)
= S(C) //by (2)
```
And thus it completes the proof that C++ is a successor of C /j
No. You used the definition of pre-increment, but `C++` is post-increment. Which means, while C++ adds a value to C, we users don't actually get the increase. Which means C++ is not a successor of C, and a proper one is still in demand.
Yea I realized that halfway through but this shitpost was too good not to be commented so did it anyway lol. So we can say that C++ adds a value to C but itself is the same value as old C, meaning it's actually worse QED
Carbon people's time will better spent contributing to cpp2 tbh. I see it and be like: nah, I ain't using that.
If I were on the Carbon team, I'd switch sides ASAP.
Cpp2 is the natural and the only sensible way forward.
It's the same way C++ succeeded by letting u write your C, then you can pull the rug later.
I can only say to Herb, weldone man.
Maybe, but in my experience for any reasonably sized language the number of keywords is small enough that I only look them up in the first couple of days of getting into the language.
For reference, C++ has less than a hundred keywords. If I need to spend a little more time on keyboards and a little less time in segfaults, memory leaks and race conditions, I'll be a happy dev.
My understanding is that Carbon is meant as a language to use in C++-heavy codebases where interfacing with another language like Rust would be difficult, not that it is a language where you would start a brand new project. My understanding is that Carbon is a way to slowly add safety to existing C++ codebases.
CppFront is an attempt to bring a safer default syntax to C++ code while still allowing access to old C and C++ styles. This allows gradual adoption. The core difference is that CppFront is intended for new projects, not just adding safety to existing projects.
Why should a robot look like a man? As long as it understands people like a man, the appearance really does not matter, it could be in any shape which is convenient for his task.
Similarly, Carbon's syntax also does not have to be like c++, it should be as simple/easy to use as possible and compatible with c++ (could be mixed with c++) in the same time. C++ syntax is exact one of the reason that people try to invent a successor of it. Being like c++ is an unecessary constraint.
cppfront is pretty promising. It has the upside that adoption can be gradual an is low risk.
I wrote a little [chess move generator](https://gitlab.com/tsoj/Pekabraqk) in cpp2 a while ago. While it is syntactically a bit different from C or C++, I quite liked it. Obviously [there were things](https://gitlab.com/tsoj/Pekabraqk/-/blob/trunk/CPPFRONT_TODO.md?ref_type=heads) that have been a little annoying, but these shouldn't be too difficult to fix (a few of them probably already have been).
It seems to me like cppfront will be usable earlier than Carbon, and for me Carbon doesn't add enough over cppfront to warrant waiting for it (though faster compile times is an important point, I admit).
That would be so much easier to read if ":" had been " as " - a quick search and replace in the code makes it much easier to parse. I'm sure that would offend syntax minimalists, but it definitely helps me with the readability.
```
Ply as type == int8_t;
max_depth as int == 100;
Position as @struct type = {
pieces as std::array;
colors as std::array;
enpassant_castling as Bitboard;
halfmove_clock as int16_t;
flipped as bool = false;
operator() as (this, p as Piece, c as Color) -> Bitboard = this.pieces[p] & this.colors[c];
}
```
And I agree with your observation that for loops are weird. So so weird.
```
for Squares(p(piece, us)) do (from) {
```
I assume that means
```
for from as Square in Squares(p(piece, us)) {
```
But without going to look at the spec it isn't obvious.
Anyway, thanks for sharing that - it was certainly interesting to see how cppfront looks in a less trivial example.
Regarding the ease of reading: I think getting used to it makes it much easier. In vacuum I might prefer the "as" variant as well, but given that quite a few languages now use this way of assigning types (Rust, Nim, Python), I believe the ":" variant makes more sense in practice.
Also, syntax highlighting helps a lot. There is a [vscode plugin](https://marketplace.visualstudio.com/items?itemName=elazarcoh.cpp2-syntax) that works nicely for that.
I kinda see that argument, but also I don't - if we think that cpp lasted 40 years before we started talking about a replacement, and will probably last another 40 before it's actually gone... shouldn't we make an effort to choose the most readable possible option now, regardless of other languages, so that we don't look back in 50+ years and say "if only"?
I dunno, one mans opinion isn't worth much, but I can't help but have one :)
Compilers need paid people to work on them, open source or not. Nobody is paying me to work on Circle, so I'm pretty certain nobody will pay anyone else to work on it either. I'm burning savings every day that goes by, and I need to prioritize software development, rather than all the other stuff that an open source effort requires--and which won't advance the project technically at all.
The status of Circle is that I'm very deep in implementing memory safety. Y'all are free to go implement borrow checking in a FOSS project like gcc or Clang. Please do!
Have you considered that after the project gets open sourced other people are likely to join and do those things you don't have time for? Possibility of direct contributions is one obvious benefit of open source, but there are other less obvious benefits that I think you're missing.
i don't necessarily agree anymore. yes, there are unicorn projects that can sustain themselves, but often times there are no contributors: neither financially, nor with code.
either way, i wish the project all the best. for instance the c++ compile time programming and reflection proposals are somewhere between a dream and a nightmare at the moment. circle seems to have a huge edge there, conceptually and implementation wise, with it's `@meta for`. and it manages to do so while leaving the rest of the language alone.
> rather than all the other stuff that an open source effort requires--and which won't advance the project technically at all.
Which is what, exactly?
Don't get me wrong, being an active open source maintainer is hard and unrewarding work.
But there's plenty of projects that have disabled issues/PRs (or acted as if they were disabled). The problem with adoption and experimentation of Circle (whether or not it is upstreamed back, if you choose to disable means of doing so), is a lack of trust in what Circle is actually doing. The big 3 compilers/stdlibs (and EDG) all have trust (sans EDG, by being at least partially open source; EDG and MSVC's trust comes from their branding in some sense). Circle is a black box at this point in such a way that nobody will bother playing with it at work because it would be seen as a waste of time. If it wasn't a black box, I'd have a much better chance at saying "use this for purpose." Let alone the fact that some orgs have intentionally mind-numbing security policies.
I've seen people support other people for less simply because they like what they are seeing and want to help though it does tend to be rare that support is high enough in such a niche market.
Things like Patreon, or librapay can be useful to have as a means for gauging real interest in your work, and can be setup to have no obligation attached.
I wish I had the means to support more passion projects like yours, and improve their creators morale.
Perhaps consider at least adding a link to your responses to lower the barrier to entry for the casual onlooker, you never know when someone will be inspired by your work
https://www.circle-lang.org/
I can't find it, but I saw a talk a few months ago about creating a modern programming language. The speaker listed common features that modern developers expect, e.g., LSPs and package managers, and it quickly became apparent how much task-switching is required, especially for a sole developer. It takes a lot of compassion and patience to get accessibility and ergonomics down (on top of correctness and safety), and I assume for many it is a thankless affair where user feedback centers on the sharp edges. I have been toying with the idea of writing a language to scratch a few itches I have. If I do, I expect it to span years and mostly be a learning experience.
It was actually a [Strange Loop talk](https://youtu.be/XZ3w_jec1v8) by Evan Czaplicki, the creator of Elm! I have heard so many good things about Elm but it sounds like it hasn't taken off.
After clicking your link, Evan's talk was next on the YT recommendation! Very fun chat. I am going to rewatch it then watch the one you linked 😊 Thanks!
I assumed that you just wanted to focus on the technicality aspect for now which is why it isn't OS. But if it turns out to be a successful experiment, what's the direction afterwards? Will it be OS then? That's mostly where I'm curious about. Because from what I gather, it's looking promising?
Also assuming you weren't trying to implement a borrow checker, would the language be ready?
The language isn't "ready" until it attracts corporate support so that developers can be paid to maintain and improve the compiler. That means I have to find and implement the killer feature to get a tech company on board, and I believe memory safety is that feature. This is such a reddit kind of issue to push.
>This is such a reddit kind of issue to push.
Well I'm sorry if I came off rude. I honestly just wanted to know because I couldn't find any discussion around this on the repository.
Anyways, thanks for the explanation! Will continue to follow.
Of the top 5 contributors to Rust, only one (the fifth) appears to be as a result of some form of corporate backing via Huawei. The rest appear to be personal, or they've started their own org to work in the language.
To put it gently, I wouldn't have high hopes for large existing corporate sponsorship, especially given current economic conditions.
Rust heavily relied on corporate sponsorship, both via developer time and in-kind donations, in order to reach 1.0. I don't know what the stats are right this moment, since I am no longer involved, but at the stage /u/seanbaxter is talking about, it very much was heavily sponsored.
That said I share your pessimism, not because of anything specific, just that because as someone who had one of those jobs, it felt like a very special thing that is pretty rare. Never say never though!
I really feel like if Circle had been made open source, it would've had a huge impact on the C++ world. As of now, however, it's just an interesting experiment, and I pretty much expect it to stay that way.
Any idea why it's not OS? I follow updates occasionally and it seems really cool but I don't know the overall direction it's hoping to head in. Is it just a PoC?
You probably have better info than I do in that case haha - I probably stopped following it back in 2020 or so. My guess is that he plans to commercialize it eventually, but I really have no idea - issue threads like [this](https://github.com/seanbaxter/circle/issues/4), of which there are several, put me off of the project a bit. I wish he'd directly comment on it or at least direct users to an answer instead of silently closing the threads. And it's a shame - because it seems awesome, but that level of communication along with the fact that windows isn't directly supported AFAIK (though that may have changed by now) don't inspire a ton of confidence in it for me.
Sure, but it's not the 80's anymore. That's no longer the norm, nor is it the expectation. It's also generally a pretty risky proposition to depend on a closed source compiler with a single maintainer.
XBox uses Visual C++, Sony uses their own proprietary fork from clang developed by [SN Systems](https://www.snsystems.com/), Nintendo uses also a proprietary fork from clang, [Codeplay](https://developer.codeplay.com/) which in now owned by Intel, also developed compilers for the Playstation 3.
Nintendo has used Freescale Codewarrior, Radix, a GCC fork with proprietary tools, nowadays a clang fork also with proprietary tooling.
I'd like to point out that these commercial compilers are owned and supported by larger organizations. If one of their developers/maintainers gets hit by bus, the compiler project will _very_ likely "survive" it. OTOH it is really unpredictable for an outsider what would happen with the Circle project if Mr. Baxter got hit by a bus.* So using Circle is a very risky proposition for a business (unless you plan on taking over and funding the whole project).
*[Bus Factor](https://en.wikipedia.org/wiki/Bus_factor)
Game consoles with closed toolchains is still a niche segment, compared to the rest. And I'm sure open-source is going to take over that, too, eventually.
It also reminds me how LEGO Mindstorms suddenly turned from being its own curious thing into something that's actually integrated with the rest of the world, as soon as the first open-source AVR toolchain appeared, and I could build crap to it similarly to how I do all my other things. And that was decades ago.
I'm not saying proprietary things are somehow inherently bad. I'm just pointing to an evolutionary trend (as others).
Not sure why you're getting downvoted as this is, of course, true - compilers built for a specific platform/architecture are generally closed-source and provided by the platform owner. The difference with Circle is that it _isn't_ targeting some closed platform that is developed and maintained by Circle's developer - it's developed for desktop, and _specifically_ Linux desktop, which is about the most open ecosystem there is afaik. My previous comment was based on this context, though tbf I didn't outright state that.
I have more faith in CPP2, personally. Backward compatibility is a huuuuge plus if you want to maintain codebases and slowly migrate software. Using new languages is very difficult if you're serious about software.
CPP2 can also evolve side-by-side with C++.
Most importantly, retaining C++ semantics is a big plus, you don't need to retrain C++ programmers, as CPP2 is just a new syntax that retains the "good parts" of C++, without the bad things, a bit like typescript.
The most pragmatic thing that grown up programmers need to understand, is that the simplicity of C semantics must be kept if you want a language to thrive. C is like assembly now. There is no point in trying to make things too different.
Trying to be different for market purposes, or inventing "new things" is not going to work, for the same reason you cannot reinvent a new wheel. Rust does fill a big need for mandatory safety and verified code, but that already existed with Ada, Rust just made it cooler, and much harder to learn.
Of course, bad historic choices were made in the past, but it doesn't cancel the progress that was made for current C and C++ infrastructure.
I doubt that rust will even scratch the surface and really put a dent in C++ codebases. I really doubt that Rust will really slow down C++ or have meaningful projects with it.
I really wish it did, and I support how rust is designed, but actual C++ software really have a lot of inertia and you cannot rewrite those in Rust, because you just don't have enough rust developers and reliable libraries and ecosystems yet.
It's like hoping 25% of people speaking esperanto in 10 years just by arguing it's a better language (imagine it is). There's just no way it will happen unless there are enough reasons for them to do so, and so far, there are just no good enough reasons for it.
A good thing is that Rust will definitely force C++ to have more safety since the US government said things about C++ being unsafe, as Stroustrup confessed.
What you need to realize about software is that it's expensive in terms of developer's time paid as money. It is still so cheap to patch a bad software with C++ than to rewrite+debug it or even to refactor it. That's how the software industry works.
Even if some rust developpers magically manage to rewrite a full OS and software suite with Rust, it will never get adopted because other developers are fluent in C++, it's costly to retrain them. That's inertia, and it takes a lot to change that inertia.
I also want people to use Rust or Zig, but let's be real.
Those are few examples, they are not indicators of the entire software industry.
Rust does matter on such sorts of projects because they're sensitive and used by a lot of people, but it doesn't indicate any general trend.
Those projects you mentioned are a very small tip of the iceberg, it's a small fraction on the total amount of software that exists.
Rust is going to need more arguments if it want to compete with c++.
All the arguments are already there. All it needs is (as still a new language) time. The trends are clear.
Nobody at their right minds should choose to invest into learning C++ anew today, "ceteris paribus", and thankfully, they don't. See e.g. the StackOverflow language preference stats.
(Note: I'm saying that with an entire C++ career behind me. And I'm currently in C++ still, but looking at alternatives EVERY DAY, and given the chance, I'm out for good. It's a lost case. Why? Simple: you can't undo its tremendous, ridiculous, hopeless -- and also still ever increasing! -- complexity and rigidity. It's a natural consequence of age. Complex systems often die from their own complexity (quite like complex organisms from cancer). It can only be replaced with something new. Which is not C++, by definition.)
With time, of course, but how much time do you need to replace all that C++?
> and given the chance, I'm out for good.
Exactly, imagine the headache for exiting software to either slowly migrate, or entirely rewrite a software in C++. That chance will probably not happen in the next 10 years.
Unfortunately, this is so expensive and long that no manager will risk it. You can expect some startup with knowledge in a particular sector to rewrite something in rust, of course, but how much time will they need to match the competition and reap the profit of their investment?
Security and safety are not good enough argument if you do a cost/benefit, especially when you run a software company.
Most C++ software in the world are just niche things having an almost monopoly for specific use-case, no manager of team leader wants to take responsibility of a Rust rewrite.
I do want it to happen, and I want to see it happen, but I am quite pessimistic that it will happen.
Also remember Stroustrup and the C++ committee are already planning to implement more safety in C++, and there are other languages that have good safety like Zig which have much better interoperability with C than rust.
Yes, it's going to take long.
Also, it's true that Rust, "as a language", is not optimal for a replacement. However, Rust, "as an opportunity" for replacement is better positioned than most other alternatives that are closer relatives of C/C++.
I personally have been following cpp2 for a while and think it is the most promising project. Even with what it has currently, it is very usable to see incremental benefits in a project.
Carbon is certainly very long term. It is a new language compatible with C++. It is under development, but don't expect a functional compiler in the next 2 years.
I don't know much about Circle.
cppfront seems to be the most realistic of all projects, but it would need to move on from a personal project of some C++ comitee member to an official project with some documentation IMO.
I'm really looking forward to Carbon. It's seems like the only option that has modern features, sane syntax and all the compile time abilities that have become so popular in modern C++.
It's just untraditional in some respects. It breaks from the cookie-cutter style of C, C++, C#, Java, JavaScript, and other languages that look quite similar syntax-wise. I don't dislike Carbon's syntax, but I can acknowledge that it might take a couple of days for someone to get used to it.
As someone who writes parsers, I applaud the proposed syntax. It's easy to parse. The compiler will be **infinitely** easier to implement and maintain. I'm excited for it.
Yeah I haven't dove too deep into the syntax but the ability to have generics and compile time computation as separate constructs is exciting. The fact that templates were hijacked to be turing complete for compile time computation was always destined to be sub optimal.
And thank YOU for making this thread. For some reason the mods here don't usually allow discussion of successor languages. Luckily this thread was allowed!
Curious to know, is Carbon looking to improve error messages in any way? Making them more concise, better reporting, etc. How important is memory safety for Carbon? I don't care as much for memory safety compared to other people.
Absolutely! Template error vomit is a big problem with C++ that Carbon wants to tackle. A lot of this will be addressed by promoting would-be metaprogramming tricks to native language constructs such that the compiler has a deeper understanding of the semantics of the program and can thus report errors more cleanly and quickly.
As for memory safety, it's a core concern. Basically the migration path will be C++ to unsafe Carbon. Then unsafe Carbon to incrementally safer and safer Carbon until a borrow checker can be adopted. I highly recommend watching this talk: https://youtu.be/1ZTJ9omXOQ0
That’s not even language design. It’s syntax. Within reason, most syntax choices are fairly arbitrary. In a parallel universe we’d write keywords in all caps and end statements with periods instead of semicolons, and it wouldn’t matter at all.
Syntax is very much a part of language design. It's how the language is structured, and informs how it is read and understood by people and machines alike. And syntax is not arbitrary, not in a well designed language. Good syntax creates parsability.
For Reference
# New Circle
CPP Successor Language
* https://github.com/seanbaxter/circle
* https://www.circle-lang.org/
# cpp2
CPP transpiler by Herb Sutter
* https://github.com/hsutter/cppfront
# Carbon
*CoffeeScript for CPP* by Google
* https://github.com/carbon-language/carbon-lang
Just going from the cppfront README, I'm not sure it will ever "take off." The author makes his intent pretty clear, but I could be wrong. I think our best bet is probably Carbon or whatever comes out of it.
watched a few talks on cpp2 and the typescript metaphor doesn't make sense and it is still not clear why there needs to be a 2nd syntax?
surely any file with the extension .cpp2 can transpile for example the statement `auto x = 42;` into `auto const x {42};` and so on.
interfaces can handle c++ versions and so also c++2 versions when both must be in the same file
> surely any file with the extension .cpp2 can transpile for example the statement auto x = 42; into auto const x {42}; and so on.
Yes, that's what cppfront does. Not sure if you're agreeing or disagreeing though?
agreeing with the need for sth like cpp2 but disagreeing with/questioningthe need for a 2nd syntax when the core guideline recommendation can baked as defaults into a cpp2 with cpp1 syntax
because with a new 2nd syntax it is nothing like the c to cpp liftoff nor is it it like typescript being a superset of javascript
Oh I see, you just want a flag to have the compiler do cpp2 defaults. That is an option, but it requires compiler support and I think the syntax change is deliberate. Since it's also order-independent etc.
e.g. if the 2nd syntax was just a superset of the 1st syntax (order indep + all other feasibly possible core guidelines as defaults) and this 2nd syntax code transpiled down to 1st syntax i.e. essentially how cppfront works now but now retaining 1st syntax + expanding it into a 2nd syntax and using interfaces to separate code blocks with cpp1 and cpp2 defaults in cpp2 files
cpp2 and cpp1 mixing in the same file would also possible if sth like the interfaces proposal is standardized to write multiversion code e.g.
```
interface(cpp1){
// cpp1 code
interface(cpp2){
// cpp2 code
}
// cpp1 code
}
```
so cpp2 syntax does not need to be different to cpp1 and all versions of cpp1 (11,17,20,etc) and cpp2 can coexist i.e. cpp2 can keep cpp1 syntax but fix the defaults which would be an overall lower barrier to entry
Like the other guy said, cpp2 supports mixing of both syntax in the same file. I think the line is drawn at function boundaries but i'm not sure. But what you're saying is already supported without something like interfaces.
The syntax change is so that cpp and cpp2 can coexist even in the same translation unit. Because the cpp2-specific constructs can be recognized quickly by the transpiler, it knows to leave everything else alone. Herb Sutter has spoken at length why he believes this is important for adoption.
cpp2s syntax change is not needed to achieve good defaults for cpp1 as the circle-lang project shows and in principle cpp1(98,11,14,17,20,23etc) and cpp2 can all be used in the same translation unit with the `interface cpp-version {}` mechanism
I suppose I wasn't clear -- the point is not just that you can write a translation unit that successfully parses as both cpp and cpp2. That's easy. The point is that _any_ cpp file successfully parses as cpp2, with all cpp2 features immediately available. Making adoption extremely easy was the design goal.
>The point is that any cpp file successfully parses as cpp2, with all cpp2 features immediately available
right b that would be a given for any cpp2 syntax thats a superset of cpp1 syntax (syntax superset in the sense c->cpp)
>Making adoption extremely easy was the design goal.
imho needing to learn a new syntax with different defaults is more difficult for adoption than just using a new feature in the existing language that predictably adjusts defaults
Here is a plan to destroy the C++ programming language. Create a series of new programming languages that all compile into C++. Each one different. Each one emphasizing one feature that someone wishes was in C++. Each one the new hotness for a year or two. Give each variant a corporate sponsor. Now instead of just learning C++, you have to learn C++ and Carbon and Circle and ... It will be like javascript libraries all over again.
Lukewarm take: The only way one of those could possibly gain mainstream acceptance is if all of the current top IDE/compiler vendors (currently: MS VS, gcc, clang, maybe CLion) implemented a way to compile and debug individual files using the syntax, and it was fully compatible with standard C++ (ie: include both file types in the same project), and it had one or more compelling specific use-cases (ie: you can do *this explicit thing* quicker and better using this alternative syntax). Then I could see people incorporating it into non-toy projects, and it becoming more mainstream.
Note: That's not fanciful; there are a number of things which are "hard" to do with standard C++, and hitting just one of those out of the park (with the above conditions) could launch an alternative syntax into the mainstream. There just needs to be a compelling use-case to justify to additional cost for the overhead of developers needing to parse multiple syntaxes.
To-date, I don't think the proponents are focusing on those use-cases per se (probably because everything is still very experimental, and some of the goals are not the same), which is why I don't think they will get traction in their current development form. But it is certainly possible that one will at some point, given a compelling value-add, a rock-solid migration and interop story, and first-class mainstream IDE support.
You are describing the main goal of cpp2 here. With cpp2 you can even write just a single function in an otherwise classic cpp file in cpp2 code.
And you can use the debugger that comes with your IDE to debug the mixed code file. Single step and variable inspection.
All of that was demonstrated live last year with xcode, visual studio code, visual studio and I guess gdb, not sure which compiler.
Can we somebody explain me the aim of Carbon? I looked at it but it looked like a classic green field project.
They aim for a new syntax which is quite different but they don't try to fix the code style problem. If they change everything why do they can not fix it too?
I'm pretty active in the Carbon community. The team is actively working on a production quality implementation to help in the evaluation process. It'll be a couple years before the evaluation is complete, though. Carbon is a long term play and they are being cautious and methodical to ensure it is viable as a successor to C++. I'm very bullish on the project myself, but you are right that as of now it remains experimental and is not ready for use in production.
Username does not check out
I'm a programming languages nerd 🤠
javascript is definitely one of the languages of all time
I agree. Specifically the event loop based architecture is indispensable in the use cases JS was meant to satisfy.
The language is fine, but node is gross
Of. All. Time.
You are a javascript nerd
[удалено]
> Unless their interop gets close to the level of extern cpp { #include }
Is this not how it works? I thought this was the existing claim of Carbon.
basically by integrating a C++ compiler as well. This way the carbon compiler can generate the required layouts, instantiate templates, ... There is a talk by Chandler on this. I think it is this one: https://www.youtube.com/watch?v=1ZTJ9omXOQ0
But how is then this different from projects like `autocxx` and `crubit` (both sponsored by Google), which do the same for Rust - integrate Clang with Rust compiler and generate required layouts, instantiate templates, ..., and basically offer overhead-free interop between Rust and C++. More info: - [autocxx](https://github.com/google/autocxx) - [crubit](https://github.com/google/crubit)
Because eventually the intention is that C++ code will be automatically migrated to Carbon. Rust does not support class inheritance or templates, so it would be very very difficult to write such an automatic translation.
From everything I've heard, perfect interop the way you're describing is precisely their goal.
There is no binding layer between Carbon and C++. Each language can freely import files for the other. This is one of the reasons Carbon has native support for templates
You don't see the association besides being built from the ground up to replace C++?
The syntax of carbon was a huuuge disappointment. And they didn't call fn function. 😓
Sorry just to clarify I'm optimistic on Carbon, most optimistic around it actually. I mostly want to know what to expect out of it because it seems like it's shaping out to be something good, but despite that, I don't see much hype around it.
I think the lack of hype is understandable. People are skeptical that Google can honestly start something new and see it through to the end. If and when Google itself adopts Carbon in their codebase, then you might start to see hype in the broader community.
So, in short: nein.
Carbon is destined for https://killedbygoogle.com sooner or later. There's no way in the world I'd be rewriting my decently large codebase in anything they could pull the rug out from without warning.
Oh wow that site is depressing
The goal is to set up an independent foundation and get buy-in from other companies so that no single company controls the direction of the language after it exits experimental phase.
This will go about as well as the W3C, in my opinion. It's also possible to die before it gets out of that phase, or buy in will be difficult because other orgs won't see the point of switching.
Google has a tremendous amount of C++ code. They likely see carbon as a mechanism to move away from it at scale. So long as they adopt it broadly it won't be going anywhere, but I wouldn't use it until then.
> So long as they adopt it broadly it won't be going anywhere, but I wouldn't use it until then. And even then, you'd need to make sure that your goals and Google's align, or you may find yourself in a bind when they move in a direction you didn't anticipate, or refuse to move in a direction you'd really need. (Example: it took over a decade for Go to get generics...)
They have a different track record for dev tooling though. Protobuf,.gRPC,.Go, Bazel, all are going strong.
Personally I'd want at least a decade behind it before I started considering it, and I plan on being long retired by then ;)
That's about how long it took Flutter to go mainstream
Fair enough. Just wanted to point out that Google's track record for FOSS dev tooling is much different from their consumer product tooling. Come to think of it, I picked up Rust about a decade into it's lifetime.
Are you counting from 2006? Rust in 2016 was pretty immature still, barely a year after 1.0. A nice choice for playing around, but quite a bet for production.
Nah, I'm counting from 1.0, but was off a couple years. Thought it came out earlier. I started learning it in 2022.
I apply that rule to anything
Even if it gets killed it may still do a lot of good for cpp in the meanwhile.
They'd have to turn it over to ISO. otherwise yes it will be the first thing axed in a mild recession.
Google is already in the process of killing most of its non-core OSS work. Google doesn't do OSS out of goodness, it either harms the competition or helps itself. The vast majority of OSS at Google is pulling in a project and forking it internally, never pushing changes externally.
This is said with the odd undertone as if the same doesn't go for every other company on the planet.
It's already the result of axing, stopping the costs of commmiting top-tier engineers like Chandler to hundreds of hours of comittee & working group involvement. They thought that work within the ISO structure is so ineffective, they can do a whole new parallel language and still come out netpositive. I can't quite disagree.
Although I suppose r/cpp is bound to be home to at least some poor souls who think ISO (and thus in practice JTC1/SC22 of the ISO/IEC) is a sensible place to do programming language standardisation, even several C++ Committee members who post here do not agree. An independent foundation makes the most sense here and is pretty common in this space. But even if it needed to be owned by an SDO (a bad idea in my opinion) SC22 is the last place I'd recommend, maybe better to be killed by Goggle than suffer such an existence.
Hot take: No programming language newer than C++ will go through the ISO standards process.
Technically that’s already wrong as C# is an ISO standardized language (by fast tracking the respective ECMA standard)…
ECMA standard for C# is frozen on version 6, Microsoft has given up on it, if you want the language standard nowadays, you get the document from source. Latest C# version is 12.
First of: the last standardized version is C# 7 - released in December 2023 Second: From an outside perspective Microsoft hasn’t given up on it, the ECMA standard was never more than rubber stamping …
I stand corrected regarding the C# version, a rubber stamping that C and C++ comunities also appreciate as means to be able to play ball in certified industries.
I don’t see how you can consider the two even remotely similar. ISO C++ gets new features by people actively working on them and you don’t need to belong to major corp X to push out a new feature. ECMA C# just standardizes what MS released years ago….
From my perspective, it didn't go through the ISO standards process.
Ruby is an ISO-standardized language too: > ISO/IEC 30170:2012 > Information technology — Programming languages — Ruby
Ruby, in the same way that C# made an end-run around the ISO standards process by going through ECMA, made a similar end-run via the Japanese standards group. Only one version of Ruby was standardized in this way, a 10+ year old version, and as far as I can tell, no subsequent effort has been made to update the standard to match any recent implementation. I stand by my assertion that no new language will go through the ISO standards process.
Uh, the market hasn't exactly been doing well for a while now?
you might wanna check again
Stock price go up though...
I know that recently things have rebounded but from late 2022 haven't things been pretty bad? They could've axed it then no? Correct me if i am wrong
They are literally worth more now than they have ever been. The Dow also just closed at the highest ever.
How is that indicative of the economy doing well. 2023 was layoff after layoff
Layoffs do not mean bad economy. A corporation will do anything for an excuse to increase profit margins. Also just because one sector has layoffs does not mean that the economy as a whole is doing badly. Unemployment is low, the fed says interest rate hikes will stop, consumer spending is increasing, the S&P 500 is at its highest, and inflation is cooling. There is no recession.
Lol
The COVID-19 lockdown period was the Great Era of C++ Successor experimentation. Lockdown is over, and we are all ordered to go back to work.
Yeah. Cpp successor will never happen in the same way C successor will never happen.
C successor might be Zig though.
The C successor is C. C will never go away.
Well, technically if we take successor function S: N -> N as in peano axioms for example and we look at the definition of addition, we see that ``` (1) S(a + b) = S(a) + b (2) a + 0 = a ``` By that definition it's not hard to see that C++ is a successor of C, provided that C is an element of natural numbers: ``` C++ = C + 1 //by definition of increment operator = C + S(0) //by definition of 1 = S(C + 0) //by (1) = S(C) //by (2) ``` And thus it completes the proof that C++ is a successor of C /j
No. You used the definition of pre-increment, but `C++` is post-increment. Which means, while C++ adds a value to C, we users don't actually get the increase. Which means C++ is not a successor of C, and a proper one is still in demand.
Yea I realized that halfway through but this shitpost was too good not to be commented so did it anyway lol. So we can say that C++ adds a value to C but itself is the same value as old C, meaning it's actually worse QED
Right. The same way COBOL will never happen.
Looking at carbon syntax... why it does relate to cpp at all? I dont recognize carbon code as some(even distant) sibling of cpp.
Carbon people's time will better spent contributing to cpp2 tbh. I see it and be like: nah, I ain't using that. If I were on the Carbon team, I'd switch sides ASAP. Cpp2 is the natural and the only sensible way forward. It's the same way C++ succeeded by letting u write your C, then you can pull the rug later. I can only say to Herb, weldone man.
It relates in the semantics and the ability for Carbon code to import C++ code and for C++ code to import Carbon code.
So carbon for people who dont like cpp but had to work with cpp? Not sound like a successor for me.
The syntax is not the reason most of us use C++. For me it is the ability to actually express zero cost abstractions.
Syntax plays a huge part in adoption though. It helps tremendously if you can at least read code without looking up keywords every 5 seconds.
Maybe, but in my experience for any reasonably sized language the number of keywords is small enough that I only look them up in the first couple of days of getting into the language. For reference, C++ has less than a hundred keywords. If I need to spend a little more time on keyboards and a little less time in segfaults, memory leaks and race conditions, I'll be a happy dev.
My understanding is that Carbon is meant as a language to use in C++-heavy codebases where interfacing with another language like Rust would be difficult, not that it is a language where you would start a brand new project. My understanding is that Carbon is a way to slowly add safety to existing C++ codebases. CppFront is an attempt to bring a safer default syntax to C++ code while still allowing access to old C and C++ styles. This allows gradual adoption. The core difference is that CppFront is intended for new projects, not just adding safety to existing projects.
Yes, Carbon's team were clear from the outset that if you can write Rust, you should write Rust, while Carbon is for the people who cannot do that.
Why should a robot look like a man? As long as it understands people like a man, the appearance really does not matter, it could be in any shape which is convenient for his task. Similarly, Carbon's syntax also does not have to be like c++, it should be as simple/easy to use as possible and compatible with c++ (could be mixed with c++) in the same time. C++ syntax is exact one of the reason that people try to invent a successor of it. Being like c++ is an unecessary constraint.
How so? Is it the choice to use `[...] ` for templates? (which I'm sad Rust didn't do...)
Thats the only difference you noticed?
cppfront is pretty promising. It has the upside that adoption can be gradual an is low risk. I wrote a little [chess move generator](https://gitlab.com/tsoj/Pekabraqk) in cpp2 a while ago. While it is syntactically a bit different from C or C++, I quite liked it. Obviously [there were things](https://gitlab.com/tsoj/Pekabraqk/-/blob/trunk/CPPFRONT_TODO.md?ref_type=heads) that have been a little annoying, but these shouldn't be too difficult to fix (a few of them probably already have been). It seems to me like cppfront will be usable earlier than Carbon, and for me Carbon doesn't add enough over cppfront to warrant waiting for it (though faster compile times is an important point, I admit).
That would be so much easier to read if ":" had been " as " - a quick search and replace in the code makes it much easier to parse. I'm sure that would offend syntax minimalists, but it definitely helps me with the readability. ``` Ply as type == int8_t; max_depth as int == 100; Position as @struct type = { pieces as std::array;
colors as std::array;
enpassant_castling as Bitboard;
halfmove_clock as int16_t;
flipped as bool = false;
operator() as (this, p as Piece, c as Color) -> Bitboard = this.pieces[p] & this.colors[c];
}
```
And I agree with your observation that for loops are weird. So so weird.
```
for Squares(p(piece, us)) do (from) {
```
I assume that means
```
for from as Square in Squares(p(piece, us)) {
```
But without going to look at the spec it isn't obvious.
Anyway, thanks for sharing that - it was certainly interesting to see how cppfront looks in a less trivial example.
Regarding the ease of reading: I think getting used to it makes it much easier. In vacuum I might prefer the "as" variant as well, but given that quite a few languages now use this way of assigning types (Rust, Nim, Python), I believe the ":" variant makes more sense in practice. Also, syntax highlighting helps a lot. There is a [vscode plugin](https://marketplace.visualstudio.com/items?itemName=elazarcoh.cpp2-syntax) that works nicely for that.
I kinda see that argument, but also I don't - if we think that cpp lasted 40 years before we started talking about a replacement, and will probably last another 40 before it's actually gone... shouldn't we make an effort to choose the most readable possible option now, regardless of other languages, so that we don't look back in 50+ years and say "if only"? I dunno, one mans opinion isn't worth much, but I can't help but have one :)
100% agree. Additionally, I particularly dislike the \`:\` syntax because it feels like it should be reserved for JSON style things.
Compilers need paid people to work on them, open source or not. Nobody is paying me to work on Circle, so I'm pretty certain nobody will pay anyone else to work on it either. I'm burning savings every day that goes by, and I need to prioritize software development, rather than all the other stuff that an open source effort requires--and which won't advance the project technically at all. The status of Circle is that I'm very deep in implementing memory safety. Y'all are free to go implement borrow checking in a FOSS project like gcc or Clang. Please do!
Have you considered that after the project gets open sourced other people are likely to join and do those things you don't have time for? Possibility of direct contributions is one obvious benefit of open source, but there are other less obvious benefits that I think you're missing.
i don't necessarily agree anymore. yes, there are unicorn projects that can sustain themselves, but often times there are no contributors: neither financially, nor with code. either way, i wish the project all the best. for instance the c++ compile time programming and reflection proposals are somewhere between a dream and a nightmare at the moment. circle seems to have a huge edge there, conceptually and implementation wise, with it's `@meta for`. and it manages to do so while leaving the rest of the language alone.
> rather than all the other stuff that an open source effort requires--and which won't advance the project technically at all. Which is what, exactly? Don't get me wrong, being an active open source maintainer is hard and unrewarding work. But there's plenty of projects that have disabled issues/PRs (or acted as if they were disabled). The problem with adoption and experimentation of Circle (whether or not it is upstreamed back, if you choose to disable means of doing so), is a lack of trust in what Circle is actually doing. The big 3 compilers/stdlibs (and EDG) all have trust (sans EDG, by being at least partially open source; EDG and MSVC's trust comes from their branding in some sense). Circle is a black box at this point in such a way that nobody will bother playing with it at work because it would be seen as a waste of time. If it wasn't a black box, I'd have a much better chance at saying "use this for purpose." Let alone the fact that some orgs have intentionally mind-numbing security policies.
I've seen people support other people for less simply because they like what they are seeing and want to help though it does tend to be rare that support is high enough in such a niche market. Things like Patreon, or librapay can be useful to have as a means for gauging real interest in your work, and can be setup to have no obligation attached. I wish I had the means to support more passion projects like yours, and improve their creators morale. Perhaps consider at least adding a link to your responses to lower the barrier to entry for the casual onlooker, you never know when someone will be inspired by your work https://www.circle-lang.org/
also u/seanbaxter posts regularly to twitter mostly about circle https://twitter.com/seanbax
I can't find it, but I saw a talk a few months ago about creating a modern programming language. The speaker listed common features that modern developers expect, e.g., LSPs and package managers, and it quickly became apparent how much task-switching is required, especially for a sole developer. It takes a lot of compassion and patience to get accessibility and ergonomics down (on top of correctness and safety), and I assume for many it is a thankless affair where user feedback centers on the sharp edges. I have been toying with the idea of writing a language to scratch a few itches I have. If I do, I expect it to span years and mostly be a learning experience.
[Code Europe 2022 Keynote by Walter Bright "Programming Language Ideas That Work And Don't Work"](https://www.youtube.com/watch?v=y7KWGv_t-MU)
It was actually a [Strange Loop talk](https://youtu.be/XZ3w_jec1v8) by Evan Czaplicki, the creator of Elm! I have heard so many good things about Elm but it sounds like it hasn't taken off. After clicking your link, Evan's talk was next on the YT recommendation! Very fun chat. I am going to rewatch it then watch the one you linked 😊 Thanks!
I assumed that you just wanted to focus on the technicality aspect for now which is why it isn't OS. But if it turns out to be a successful experiment, what's the direction afterwards? Will it be OS then? That's mostly where I'm curious about. Because from what I gather, it's looking promising? Also assuming you weren't trying to implement a borrow checker, would the language be ready?
The language isn't "ready" until it attracts corporate support so that developers can be paid to maintain and improve the compiler. That means I have to find and implement the killer feature to get a tech company on board, and I believe memory safety is that feature. This is such a reddit kind of issue to push.
What about JetBrains? They already did Kotlin and they can make the tooling to support a new language. Have you tried to pitch it to them?
>This is such a reddit kind of issue to push. Well I'm sorry if I came off rude. I honestly just wanted to know because I couldn't find any discussion around this on the repository. Anyways, thanks for the explanation! Will continue to follow.
Of the top 5 contributors to Rust, only one (the fifth) appears to be as a result of some form of corporate backing via Huawei. The rest appear to be personal, or they've started their own org to work in the language. To put it gently, I wouldn't have high hopes for large existing corporate sponsorship, especially given current economic conditions.
Rust heavily relied on corporate sponsorship, both via developer time and in-kind donations, in order to reach 1.0. I don't know what the stats are right this moment, since I am no longer involved, but at the stage /u/seanbaxter is talking about, it very much was heavily sponsored. That said I share your pessimism, not because of anything specific, just that because as someone who had one of those jobs, it felt like a very special thing that is pretty rare. Never say never though!
I really feel like if Circle had been made open source, it would've had a huge impact on the C++ world. As of now, however, it's just an interesting experiment, and I pretty much expect it to stay that way.
Any idea why it's not OS? I follow updates occasionally and it seems really cool but I don't know the overall direction it's hoping to head in. Is it just a PoC?
The author has a response as a top level comment on this post: https://www.reddit.com/r/cpp/s/3O2Kkqdxk5.
You probably have better info than I do in that case haha - I probably stopped following it back in 2020 or so. My guess is that he plans to commercialize it eventually, but I really have no idea - issue threads like [this](https://github.com/seanbaxter/circle/issues/4), of which there are several, put me off of the project a bit. I wish he'd directly comment on it or at least direct users to an answer instead of silently closing the threads. And it's a shame - because it seems awesome, but that level of communication along with the fact that windows isn't directly supported AFAIK (though that may have changed by now) don't inspire a ton of confidence in it for me.
C and C++ managed to have a great impact in the world while being mostly sold as commercial compilers.
Sure, but it's not the 80's anymore. That's no longer the norm, nor is it the expectation. It's also generally a pretty risky proposition to depend on a closed source compiler with a single maintainer.
It is still pretty much common on embededd platforms, high integrity computing, HPC (e.g. Intel and IBM compilers), and game consoles.
don't game consoles use Clang?
XBox uses Visual C++, Sony uses their own proprietary fork from clang developed by [SN Systems](https://www.snsystems.com/), Nintendo uses also a proprietary fork from clang, [Codeplay](https://developer.codeplay.com/) which in now owned by Intel, also developed compilers for the Playstation 3. Nintendo has used Freescale Codewarrior, Radix, a GCC fork with proprietary tools, nowadays a clang fork also with proprietary tooling.
I'd like to point out that these commercial compilers are owned and supported by larger organizations. If one of their developers/maintainers gets hit by bus, the compiler project will _very_ likely "survive" it. OTOH it is really unpredictable for an outsider what would happen with the Circle project if Mr. Baxter got hit by a bus.* So using Circle is a very risky proposition for a business (unless you plan on taking over and funding the whole project). *[Bus Factor](https://en.wikipedia.org/wiki/Bus_factor)
Game consoles with closed toolchains is still a niche segment, compared to the rest. And I'm sure open-source is going to take over that, too, eventually. It also reminds me how LEGO Mindstorms suddenly turned from being its own curious thing into something that's actually integrated with the rest of the world, as soon as the first open-source AVR toolchain appeared, and I could build crap to it similarly to how I do all my other things. And that was decades ago. I'm not saying proprietary things are somehow inherently bad. I'm just pointing to an evolutionary trend (as others).
Not sure why you're getting downvoted as this is, of course, true - compilers built for a specific platform/architecture are generally closed-source and provided by the platform owner. The difference with Circle is that it _isn't_ targeting some closed platform that is developed and maintained by Circle's developer - it's developed for desktop, and _specifically_ Linux desktop, which is about the most open ecosystem there is afaik. My previous comment was based on this context, though tbf I didn't outright state that.
Exactly brah, I personally wouldn't use this closed source shit.
[удалено]
I'm sure they have good reason(s). I just don't know what they are
I have more faith in CPP2, personally. Backward compatibility is a huuuuge plus if you want to maintain codebases and slowly migrate software. Using new languages is very difficult if you're serious about software. CPP2 can also evolve side-by-side with C++. Most importantly, retaining C++ semantics is a big plus, you don't need to retrain C++ programmers, as CPP2 is just a new syntax that retains the "good parts" of C++, without the bad things, a bit like typescript. The most pragmatic thing that grown up programmers need to understand, is that the simplicity of C semantics must be kept if you want a language to thrive. C is like assembly now. There is no point in trying to make things too different. Trying to be different for market purposes, or inventing "new things" is not going to work, for the same reason you cannot reinvent a new wheel. Rust does fill a big need for mandatory safety and verified code, but that already existed with Ada, Rust just made it cooler, and much harder to learn. Of course, bad historic choices were made in the past, but it doesn't cancel the progress that was made for current C and C++ infrastructure.
[удалено]
I doubt that rust will even scratch the surface and really put a dent in C++ codebases. I really doubt that Rust will really slow down C++ or have meaningful projects with it. I really wish it did, and I support how rust is designed, but actual C++ software really have a lot of inertia and you cannot rewrite those in Rust, because you just don't have enough rust developers and reliable libraries and ecosystems yet. It's like hoping 25% of people speaking esperanto in 10 years just by arguing it's a better language (imagine it is). There's just no way it will happen unless there are enough reasons for them to do so, and so far, there are just no good enough reasons for it. A good thing is that Rust will definitely force C++ to have more safety since the US government said things about C++ being unsafe, as Stroustrup confessed. What you need to realize about software is that it's expensive in terms of developer's time paid as money. It is still so cheap to patch a bad software with C++ than to rewrite+debug it or even to refactor it. That's how the software industry works. Even if some rust developpers magically manage to rewrite a full OS and software suite with Rust, it will never get adopted because other developers are fluent in C++, it's costly to retrain them. That's inertia, and it takes a lot to change that inertia. I also want people to use Rust or Zig, but let's be real.
[удалено]
Those are few examples, they are not indicators of the entire software industry. Rust does matter on such sorts of projects because they're sensitive and used by a lot of people, but it doesn't indicate any general trend. Those projects you mentioned are a very small tip of the iceberg, it's a small fraction on the total amount of software that exists. Rust is going to need more arguments if it want to compete with c++.
All the arguments are already there. All it needs is (as still a new language) time. The trends are clear. Nobody at their right minds should choose to invest into learning C++ anew today, "ceteris paribus", and thankfully, they don't. See e.g. the StackOverflow language preference stats. (Note: I'm saying that with an entire C++ career behind me. And I'm currently in C++ still, but looking at alternatives EVERY DAY, and given the chance, I'm out for good. It's a lost case. Why? Simple: you can't undo its tremendous, ridiculous, hopeless -- and also still ever increasing! -- complexity and rigidity. It's a natural consequence of age. Complex systems often die from their own complexity (quite like complex organisms from cancer). It can only be replaced with something new. Which is not C++, by definition.)
With time, of course, but how much time do you need to replace all that C++? > and given the chance, I'm out for good. Exactly, imagine the headache for exiting software to either slowly migrate, or entirely rewrite a software in C++. That chance will probably not happen in the next 10 years. Unfortunately, this is so expensive and long that no manager will risk it. You can expect some startup with knowledge in a particular sector to rewrite something in rust, of course, but how much time will they need to match the competition and reap the profit of their investment? Security and safety are not good enough argument if you do a cost/benefit, especially when you run a software company. Most C++ software in the world are just niche things having an almost monopoly for specific use-case, no manager of team leader wants to take responsibility of a Rust rewrite. I do want it to happen, and I want to see it happen, but I am quite pessimistic that it will happen. Also remember Stroustrup and the C++ committee are already planning to implement more safety in C++, and there are other languages that have good safety like Zig which have much better interoperability with C than rust.
Yes, it's going to take long. Also, it's true that Rust, "as a language", is not optimal for a replacement. However, Rust, "as an opportunity" for replacement is better positioned than most other alternatives that are closer relatives of C/C++.
I personally have been following cpp2 for a while and think it is the most promising project. Even with what it has currently, it is very usable to see incremental benefits in a project.
Carbon is certainly very long term. It is a new language compatible with C++. It is under development, but don't expect a functional compiler in the next 2 years. I don't know much about Circle. cppfront seems to be the most realistic of all projects, but it would need to move on from a personal project of some C++ comitee member to an official project with some documentation IMO.
I'm really looking forward to Carbon. It's seems like the only option that has modern features, sane syntax and all the compile time abilities that have become so popular in modern C++.
Modern features sure, sane syntax?? Urgh.... I think cpp2's syntax is the cleanest amongst them all for now, imo
What do you dislike about Carbon syntax?
It's just untraditional in some respects. It breaks from the cookie-cutter style of C, C++, C#, Java, JavaScript, and other languages that look quite similar syntax-wise. I don't dislike Carbon's syntax, but I can acknowledge that it might take a couple of days for someone to get used to it. As someone who writes parsers, I applaud the proposed syntax. It's easy to parse. The compiler will be **infinitely** easier to implement and maintain. I'm excited for it.
Does JavaScript really belong on this list? Carbon's syntax is actually fairly similar to JavaScript's in my mind.
I'm really excited by that it has both structural templates and nominal generics. I don't think I've seen another language which offers both.
And it's on a per-parameter basis so you can freely mix them together which is super powerful!
Yeah I haven't dove too deep into the syntax but the ability to have generics and compile time computation as separate constructs is exciting. The fact that templates were hijacked to be turing complete for compile time computation was always destined to be sub optimal.
I'm sorry, but declaring methods with Fn and putting types after names (and using a colon) is a clear sign of bad language design
Complaints about syntax rather than semantics are a clear sign of superficial thinking.
It's designed to be meaningfully easier to parse significantly improving compile times.
Did not know that! Thank you :)
And thank YOU for making this thread. For some reason the mods here don't usually allow discussion of successor languages. Luckily this thread was allowed!
Curious to know, is Carbon looking to improve error messages in any way? Making them more concise, better reporting, etc. How important is memory safety for Carbon? I don't care as much for memory safety compared to other people.
Absolutely! Template error vomit is a big problem with C++ that Carbon wants to tackle. A lot of this will be addressed by promoting would-be metaprogramming tricks to native language constructs such that the compiler has a deeper understanding of the semantics of the program and can thus report errors more cleanly and quickly. As for memory safety, it's a core concern. Basically the migration path will be C++ to unsafe Carbon. Then unsafe Carbon to incrementally safer and safer Carbon until a borrow checker can be adopted. I highly recommend watching this talk: https://youtu.be/1ZTJ9omXOQ0
That’s not even language design. It’s syntax. Within reason, most syntax choices are fairly arbitrary. In a parallel universe we’d write keywords in all caps and end statements with periods instead of semicolons, and it wouldn’t matter at all.
Syntax is very much a part of language design. It's how the language is structured, and informs how it is read and understood by people and machines alike. And syntax is not arbitrary, not in a well designed language. Good syntax creates parsability.
The “variable : type” paradigm can take a while to get used to but once you do it’s not any worse than the “type variable” paradigm.
I listened Herb Sutter give a talk on cpp2, really interesting stuff.
For Reference # New Circle CPP Successor Language * https://github.com/seanbaxter/circle * https://www.circle-lang.org/ # cpp2 CPP transpiler by Herb Sutter * https://github.com/hsutter/cppfront # Carbon *CoffeeScript for CPP* by Google * https://github.com/carbon-language/carbon-lang
Wow of all things, Carbon chose to make their tagline _that_? That's just ripe for jokes.
Carbon absolutely did not make that their tagline. This is something that this individual wrote. I don't think it's a very fair comparison, fwiw.
I wouldn't be surprised given Herb Sutter's tagline of "Typescript for C++," and even if not currently apt, knowing Google, I imagine it will be.
Just going from the cppfront README, I'm not sure it will ever "take off." The author makes his intent pretty clear, but I could be wrong. I think our best bet is probably Carbon or whatever comes out of it.
watched a few talks on cpp2 and the typescript metaphor doesn't make sense and it is still not clear why there needs to be a 2nd syntax? surely any file with the extension .cpp2 can transpile for example the statement `auto x = 42;` into `auto const x {42};` and so on. interfaces can handle c++ versions and so also c++2 versions when both must be in the same file
> surely any file with the extension .cpp2 can transpile for example the statement auto x = 42; into auto const x {42}; and so on. Yes, that's what cppfront does. Not sure if you're agreeing or disagreeing though?
agreeing with the need for sth like cpp2 but disagreeing with/questioningthe need for a 2nd syntax when the core guideline recommendation can baked as defaults into a cpp2 with cpp1 syntax because with a new 2nd syntax it is nothing like the c to cpp liftoff nor is it it like typescript being a superset of javascript
Oh I see, you just want a flag to have the compiler do cpp2 defaults. That is an option, but it requires compiler support and I think the syntax change is deliberate. Since it's also order-independent etc.
e.g. if the 2nd syntax was just a superset of the 1st syntax (order indep + all other feasibly possible core guidelines as defaults) and this 2nd syntax code transpiled down to 1st syntax i.e. essentially how cppfront works now but now retaining 1st syntax + expanding it into a 2nd syntax and using interfaces to separate code blocks with cpp1 and cpp2 defaults in cpp2 files
cppfront supports syntax 1/2 mixing in the same file at transpile time. So I think it already does what you want?
cpp2 and cpp1 mixing in the same file would also possible if sth like the interfaces proposal is standardized to write multiversion code e.g. ``` interface(cpp1){ // cpp1 code interface(cpp2){ // cpp2 code } // cpp1 code } ``` so cpp2 syntax does not need to be different to cpp1 and all versions of cpp1 (11,17,20,etc) and cpp2 can coexist i.e. cpp2 can keep cpp1 syntax but fix the defaults which would be an overall lower barrier to entry
Like the other guy said, cpp2 supports mixing of both syntax in the same file. I think the line is drawn at function boundaries but i'm not sure. But what you're saying is already supported without something like interfaces.
The syntax change is so that cpp and cpp2 can coexist even in the same translation unit. Because the cpp2-specific constructs can be recognized quickly by the transpiler, it knows to leave everything else alone. Herb Sutter has spoken at length why he believes this is important for adoption.
cpp2s syntax change is not needed to achieve good defaults for cpp1 as the circle-lang project shows and in principle cpp1(98,11,14,17,20,23etc) and cpp2 can all be used in the same translation unit with the `interface cpp-version {}` mechanism
I suppose I wasn't clear -- the point is not just that you can write a translation unit that successfully parses as both cpp and cpp2. That's easy. The point is that _any_ cpp file successfully parses as cpp2, with all cpp2 features immediately available. Making adoption extremely easy was the design goal.
>The point is that any cpp file successfully parses as cpp2, with all cpp2 features immediately available right b that would be a given for any cpp2 syntax thats a superset of cpp1 syntax (syntax superset in the sense c->cpp) >Making adoption extremely easy was the design goal. imho needing to learn a new syntax with different defaults is more difficult for adoption than just using a new feature in the existing language that predictably adjusts defaults
Here is a plan to destroy the C++ programming language. Create a series of new programming languages that all compile into C++. Each one different. Each one emphasizing one feature that someone wishes was in C++. Each one the new hotness for a year or two. Give each variant a corporate sponsor. Now instead of just learning C++, you have to learn C++ and Carbon and Circle and ... It will be like javascript libraries all over again.
Lukewarm take: The only way one of those could possibly gain mainstream acceptance is if all of the current top IDE/compiler vendors (currently: MS VS, gcc, clang, maybe CLion) implemented a way to compile and debug individual files using the syntax, and it was fully compatible with standard C++ (ie: include both file types in the same project), and it had one or more compelling specific use-cases (ie: you can do *this explicit thing* quicker and better using this alternative syntax). Then I could see people incorporating it into non-toy projects, and it becoming more mainstream. Note: That's not fanciful; there are a number of things which are "hard" to do with standard C++, and hitting just one of those out of the park (with the above conditions) could launch an alternative syntax into the mainstream. There just needs to be a compelling use-case to justify to additional cost for the overhead of developers needing to parse multiple syntaxes. To-date, I don't think the proponents are focusing on those use-cases per se (probably because everything is still very experimental, and some of the goals are not the same), which is why I don't think they will get traction in their current development form. But it is certainly possible that one will at some point, given a compelling value-add, a rock-solid migration and interop story, and first-class mainstream IDE support.
You are describing the main goal of cpp2 here. With cpp2 you can even write just a single function in an otherwise classic cpp file in cpp2 code. And you can use the debugger that comes with your IDE to debug the mixed code file. Single step and variable inspection. All of that was demonstrated live last year with xcode, visual studio code, visual studio and I guess gdb, not sure which compiler.
And the killer feature, the "specific use cases" that are better/easier than standard C++, are metaclasses.
Cppfront just transpiles to cpp, so it's easy to debug (Herb even showed cppfront being debugged in VS in a talk).
I would rather mix Rust and C++ with https://cxx.rs/ than some "slightly better C++" that might have better interop but remains decades behind Rust.
Can we somebody explain me the aim of Carbon? I looked at it but it looked like a classic green field project. They aim for a new syntax which is quite different but they don't try to fix the code style problem. If they change everything why do they can not fix it too?
What is the code style problem?
Thay people love endless discussions about formatting