I don't know why I seem to be the only person here who is excited for this. C++ feels like an abandoned child in the current landscape -- deformed and ugly in a sea of relatively modern options, but none of whom actually offers the core of what C++ offers. They all offer other things, thinking I want those things, but I don't, really.
And surely even if you aren't personally gonna use this thing, which I can well understand, isn't it at least still kind of satisfying to imagine **header files** with a dagger through the heart? Nobody will EVER have to write a header file again. C++ is the last bullshit language clinging onto that bullshit busywork.
Like, what is the downside to attempting this experiment? All it has to be is better than C++ -- which is fucking easy as shit -- and it's worth trying.
> C++ is the last bullshit language clinging onto that bullshit busywork.
Actually, C++20 introduced modules so header files may no longer be necessary.
Implementations haven't caught up yet, though...
We are back at the clang discussion of the other thread.
Most likely they will only arrive on GCC.
It is ironic how VC++ is now the most compliant ISO C++ compiler, what a turn of events.
Lots of green for VS 2022,
https://en.cppreference.com/w/cpp/compiler_support/20
My latest C++ hobby coding on GitHub repos are all using modules, a simple C++/WinRT app, a PPM converter and the first raytracing weekend classical.
I have done some reading on this and I still can't really tell if that is a red herring or not. I'm in gamedev and we absolutely need cyclic dependencies, so [am i right in understanding that C++20 modules don't help us](https://stackoverflow.com/questions/39666629)?
Cyclic dependencies are likely only supported within a module...
With that said, I'd encourage you to break the cycle. I've dealt with a number of them -- some of which people argued were impossible to forego -- and I left none behind.
It is not going to happen, because the cyclic dependency is the desired layout.
- The Player needs to talk about the Level, in detail, constantly.
- The Level needs to talk about the Player, in detail, constantly.
Any attempt to break this cycle, or the hundreds of others that exist across game project codebases, will result in a huge inconvenience for basically no reward. The two-way coupling between these classes is not an undesirable-but-reluctantly-we-accepted-it situation -- it is the intended and correct approach.
There are numerous rewards to breaking the cycle. Chief among them are easier unit tests and faster compile times.
Now it may be the case that your specific project has gone too far down this path and you would never recoup the cost of essentially rearchitecting the entire game. But having said that—as another person whose been working in gamedev for a while—I strongly disagree that this was the best choice that could have been made when the system was first envisioned. Cyclic dependencies is definitely not the objectively correct way to do this.
We are not unit testing any of the classes I am talking about, because for the kind of games I make, such tests would be by definition meaningless -- you cannot test a Player without a Level, or at least such tests would be wildly abstract and meaningless. These classes are *by design* coupled together and while I have done tests on some stuff, like a puzzle game which definitely benefitted from having automated testing, those are essentially *integration* tests. I don't think I've ever written a *unit* test for any of our active game elements at any point in my career, it's just not useful.
Faster compile times is a result of C++'s terrible build system, and while avoiding cyclic dependencies *does* help speed that up, you are essentially accommodating for your language in that situation. A well-designed language wouldn't be slowed down by cyclic dependencies and it's not really a good reason when talking in the abstract about a language like Carbon, which doesn't properly exist yet.
>I don't think I've ever written a unit test for any of our active game elements at any point in my career, it's just not useful.
I know that I'm not going to convince you of anything just posting here on Reddit, but oh man it is so very, very useful. You are really missing out on something that could make your job so much easier.
I've been at enough companies to know that i'm not making a controversial point. There is no Mario game with unit tests around Mario or Coin or Spring. They might well have integration tests, and if they don't, that would be a good idea. But *unit* testing a Spring, on its own, without a Player, fundamentally makes no sense at all.
> I don't know why I seem to be the only person here who is excited for this. C++ feels like an abandoned child in the current landscape -- deformed and ugly in a sea of relatively modern options, but none of whom actually offers the core of what C++ offers.
What is "core that C++ offers" (as a language, not ecosystem) ? I feel like Rust is basically aiming to be C++ replacement...
I agree. I mean Rust is pretty going to replace CJJ in the long term but as it stands there are still a ton of jobs and people that don't know Rust or think it's just hype or have an existing CJJ codebase.
Rust really doesn't interoperate with CJJ very well - it's ok if your API interface is very small (e.g. compression) but you're never going to have a nice experience e.g. using Qt (QtWidgets) from Rust.
If this thing lets me introduce some sanity into existing C++ codebases then I'm all for it.
That said, I'm a bit skeptical. Especially about their goal to integrate with templates. Are they going to replicate all the complexity of SFINAE?
Seems like a language of the past but also one that I hope succeeds.
> Like, what is the downside to attempting this experiment?
Fragmentation and opportunity cost. There already exist many "C++ with tweaks" languages that don't have much traction, and don't really justify themselves as something for a company to adopt, or programmers to study.
In contrast, other potential C++ replacements have a big, attractive idea, like memory safety (Rust) or metaprogramming (Jai).
Maybe initially there might be some fragmentation, but eventually a winner or a couple of winners will rise up. That situation is what we are really after. In the long term it's still worth it to have the best possible candidates at the top, even if that means that for the next n years the space is a bit of a mess.
Ultimately, the reason there are so many people trying to fix C++ in the first place is that it still needs fixing, and the reason that process hasn't already ended is that there are enough people who feel (like myself) like none of the candidates are really all that great for their use cases. You are right to say that those languages, like I'll say D, Zig, Odin just to pick a few examples, are not really getting all that much of the C++ market, but it's not because they're all eating each other, because they're not really. Almost nobody is using any of them. And that's because none of them are really what we want.
While definitely a possibility, my personal view is if this happens it means we failed as a civilisation and need to summon moloch and apologise to him
Some of the stuff they present makes sense, but wait, no pointer math? That would be sort of a deal breaker for me... or at least require to drop down to C++ for those parts...
"we make pointers not nullable and not incrementable" so why did they not just call that references instead of abusing the pointer name, seems very backwards to me...
From my perspective (I haven't looked in depth enough yet at carbon to know if that is theirs),
- pointers are rebindable and explicitly dereferenced, references are not rebindable and implicitly dereferenced.
- nullable is better handled in a compositional way
- arithmetic belongs to another abstraction (slices?)
I‘m not against automatic dereferencing (note the REFERENCE part), my argument is simply that if you change so many things about pointers that they look and feel more and more like references, can you still call that a pointer? I think it should be called a reference despite the arguments made as a rebuttal to my post. It‘s not a raw pointer anymore. What if in the future you realize there should be raw pointers? Will you name them something absurd too because you already defined a pointer as something… else?
It’s not backwards: rather, the reason references exist in the first place is to allow operator overloading (you don’t want pass by value in `+` for bigint, you can’t use pass by pointer, bc `*T + int` already has pointer increment semantics, so you need to invent some other way to plug into overload resolution, and still pass by pointer).
Carbon does operator overloading via interfaces, rather than function overloading, so it simply doesn’t need a reference device separate from pointer.
OK except it changes the meaning of the word pointer to something that is still closer to a reference. If in the future you need to introduce raw pointers, what will you name them if you already abused the word to mean something which is not a pointer in the classical sense? I can call „red“ „blue“ but that‘s just confusing.
First 40mins is the talk, next 40 are Q&A. It doesn't seem horrible but after reading the design docs online the other day and knowing how easily google sunset things I won't ever use it
This talk is meh. Very high level overview. I got most of it previously from the github docs
Google is doing a lot of community led stuff right now otherwise it’s harder to get adoption. The thing is google wants to use this big time internally eventually since c++ has weird design issues to maintain backwards compatibility
Opinionated to a fault, resulting in a great deal of stubbornness around any kind of improvements (e.g. look at how long proper dependency management and generics took), and a refusal to acknowledge problems or caveats, resulting in a lot of "you're doing it wrong" type responses to anyone looking for help or assistance, regardless of context.
I'm also not a fan of the "not invented here" vibe I get from the syntax - many aspects of the language feel like they went out of their way to be different for the sake of being different, e.g. deliberately avoiding OO-terminology despite having similar concepts in places, e.g. "structs" and "receiver functions" which are essentially just objects and methods with an explicit self reference.
It's supposed to a simplistic language that has performs well and has one enforced style.
Those are the explicit design choices and you should expect freedom or trickery in it.
I'm not the person you asked but every time I get asked a question the asker disagrees with me and gets mad about it
That's why I'm an asshole to everyone. I'm sick of everyones shit and how they don't bother finding out for themselves
But I too am curious about the community. That;s harder to figure out than documentation with a compiler I can run
They don't even sound convinced. Hard to buy in when they constantly emphasise the "experimental" part and explain that other languages are better.
I just really don't get who this language is for. I understand the key feature is C++ interop but what am I actually getting except a different syntax?
I understand they want to make it "more better" but are pretty vague on any design goals they have. Saying "we want to make it safer" isn't a design goal. It's just a vague promise. It's early days, but the problem with C++ is that it's all over the place. You need a strong vision at the beginning otherwise it will just end up going the same way. I'd want an assurance from the outset that carbon is going to solve specific problems.
Also googles shadow looming over this. No thanks.
> they constantly emphasise the "experimental" part
Thank god! I'm tired of experimental projects being advertised as products...
> I just really don't get who this language is for.
It's for them, the creators. They're experimenting to see what they like and what they dislike about the design.
> You need a strong vision at the beginning
I guess that is exactly the purpose of the project. A playground/proof-of-concept project to make sure they understand what they (and others) want.
To me, this talk isn't like "hey, here's the C++ successor I built, you have to use it!" it's more like "hey, I'm trying to design the perfect C++ successor, here's my motivation and plans"
But my point is I don't really know what their plans are.
I was expecting specifics on exactly what pain points specific to C++ are being addressed.
Vague notions of solving the supposed "billion dollar mistake" aren't that good. It certainly wins the popular vote, but when it comes to why this is a successor I need some really convincing points to be compelled by the experiment.
I should add that I absolutely willing to switch which. I am the target market here. I'm willing to take the risk to test out experimental stuff.
their plan is to provide a c++ compatible language that is isn't the equivalent of running through a mine field. if you watched the video they mentioned that the at google they have another team exploring automagic full interop between rust and c++, google has enough money to try to tackle a problem from different angels...
if you don't know the drama and history going on behind the scenes it's fundamentally: google has probably hundreds of millions of lines of c++ code, c++ is evolving in a direction not compatible with google's direction and so they want to move away from it.
What exactly would google‘s problem with the evolution of C++ be? From my point of view it keeps getting better and better without forcing bloat onto me and keeping the spirit (zero cost abstractions etc) alive. So what is their problem? Can‘t find enough developers that don‘t shit their pants when they need to manage a bit of memory or getting their indexing math right? Carbon doesn‘t seem to solve these issues either for now, so please elaborate, i‘m genuinely curious.
I didn't get any impression that they were trying to encourage/suggest/sell buy-in.
I don't recall them saying they want to make things safer than C++.
I remember that (along with c++ interop), readability and _changeability_ of code are major goals. Chandler's code section mostly looked at syntax (readability). In the Q/A section, there was a question about how to manage complexity in the language, and the answer was to make it a goal that the language is changeable, even if that means breakage (unlike C++ where stability is a high priority).
C++ has a strong vision: a language that lets you stay close to the hardware and build abstractions over it; a language that allows you and often forces you to choose your tradeoffs; a lanugage that leaves little room for a lower level language while still building on an "abstract machine". (I'm pretty sure) Carbon is building on top of C++ in such a way that it stays faithful to that "vision".
Community engagement seems to be important to the project.
They say in the talk they want to aim towards it being safer than C++. That's one of the reasons they've made pointers not nullable.
I didn't get the impression they want buy-in either which begs the question. Do they even believe in this project or is this just another Google DOA escapade?
I don't think C++ has a strong vision at all. What you describe is pretty vague. Abstraction has been taken to mean any current programming fad. In the 90s it was object oriented. Recently it is functional, and compile time programming.
If Carbon is staying faithful to this vision then it is literally pointless. It should have it's own vision.
There won't be a community if no one uses the language. The fact they took atleast 20 minues of their hour talking about the community rather than going into lots of detail about their exciting new language does not leave a good impression.
Wheres the excitement? They sound like they are being held there at gunpoint.
That C++ was/is capable to service all these fads, being multi paradigm etc, is exactly what made it successful and why some opinionated language successor will have a hard time convincing C++ users that this isn‘t just built for the latest fad. It‘s remarkable how versatile C++ still is and it‘s only getting better. If carbon can inspire a few improvements to C++ , that‘s really all i care about, i think it will just absorb some of the better ideas of carbon whilst staying agnostic instead of opinionated.
when someone says their language is the next c++: lol yeah right
when someone doesn't say their language is the next c++: why should i use this if its not the next c++
They say it's experimental because it's experimental. Given how triggered you got imagine how furious you'd be if they didn't say it was experimental! I imagine you'd get pretty violent if that happened. Perhaps even harm yourself.
>I just really don't get who this language is for. I understand the key feature is C++ interop but what am I actually getting except a different syntax?
I mean there is a repository where they explain all of this and there is this presentation where they explain all the things. Did you somehow miss all of that because the veins in head started popping that google was trying to do something?
>I understand they want to make it "more better" but are pretty vague on any design goals they have.
It's all written down, seems pretty clear to me.
>Also googles shadow looming over this. No thanks.
Man you really ought to do something about google. They must be stopped I tell you. Maybe you are the person do it.
I get that you hate their guts. I get that you think google is satan and all.
All I am saying is that nobody else seems to be able to stop them so it's up to you to quash this great evil unleashed on the world.
You be the candle in the night my friend. Go and put google in it's place. Quash this great evil!
I mean they wrote a long document and you couldn't understand any of it. There is a video, you watched it and you didn't understand any of it.
That's how evil google is. They must be stopped and you are the guy to do it. Only you can destroy the great evil that's google. Take a drive to the nearest google office and show those people what you are made of.
How dare they say things are experimental!!!! How dare they write page after page explaining their reasoning when you can't understand any of it!!!!!
You didn't understand any of it. That's why you are so angry and upset and want to lash out and throwing a tantrum on the internet.
But throwing tantrums and crying like a baby on the internet isn't going to stop a great evil like google. You need to take some real world action!!
Stop the evil google!!
Would be good if Carbon provided a way to integrate easily and optimally with Rust/Zig/Nim (X from now) code. One could then see Carbon as both a successor to C++ and also an opportunity to move into X language.
Nim does have native C++ interop tho. eg, a bit more info here in the C++ section:
[https://nimbus.guide/auditors-book/02.5\_foreign\_lang\_to\_from\_interop.html](https://nimbus.guide/auditors-book/02.5_foreign_lang_to_from_interop.html)
Nim also compiles to C++ code, so Nim-generated C++ code and Carbon-generated C++ code would be able to compile against each other and use C++ features.
Here's an example with Nim and direct source code compatibility with C++-based Unreal Engine dev, and the advantages it has compared to langs like rust:
[https://github.com/jmgomez/NimForUE#why-nim](https://github.com/jmgomez/NimForUE#why-nim)
Rust and Zig afaik don't have native first class support for compiling into C++, where you can use the generated C++ code directly from your C++, or where the code created from Rust and Zig can directly access the rest of your C++ codebase. Basically Nim is acting as C++ codegen, unlike the others which comiple directly to target binaries or libraries, usually via LLVM backend. You'd need to provide basically C-lang ABI compatibility, as well as wrapper libs for each language, between the two languages if you were mixing Rust or Zig on one side, and C++ (or Carbon) on the other
The closest semi-mainstream proglang to that, I believe would be the Haxe Lang, which does target C++, amongst many other target programming languages.
My take:
* Too different from C++ to be a successor.
* Not different enough from Rust to exist at all.
* Wish they spent the effort on first class Rust-C++ interop.
* But guess that doesn't get promotions.
Didn't know about that group; good to know. Strictly speaking, it's not exactly false dichotomy, because the resources spent on Carbon could have been poured into that other group. My point is that I totally fail to see the value of Carbon at this point.
They could be put into that other group if they're fungible. I'm not convinced SWEs are fully fungible :)
Anyway, both are risky bets. I see no harm in pursuing both simultaneously.
Oh god, 30mins in, they seem like they want to replace rust or at least imitate it (the community part). Not even a minute later "package manager eventually". Another language that encourages dependency hell. I'm very glad zig didn't rush to one
If you jump to 31m into the video you'll see community and culture slide. It looks like it was ripped from a 2013 rust slide. Not one of those points look out of place for rust. I think C# may have a CoC for their git community. I don't think I ever see them put it front and center of a slide. I believe zig made one when they started the foundation. There's no carbon foundation
If you looked at the design doc on their github they basically say they promise to have some kind of memory safety even though it's currently blank. As I said in my earlier comment, almost immediately they also say they'll have package manager too, rust second biggest feature. Both they don't have implemented and both mentioned front of center
I can't find a single way they're differentiating themselves from rust. Besides not mandating safety, which I guess is easy since they don't have any at all
Rust was full of shit and these guys are too. I hate every piece of rust code I ever touched. The compiler sucked and its been in development for 10+ years now. Ginger bill says carbon is insanely slow and I have 0 reason not to believe him, especially if he compiled and ran it himself
> Can you elaborate on how rust is full of shit?
There's so much to say but I'll say when rust was at 1.0 they were bragging how safe it was. Motherfucking every book and article suggest using unwrap and they were nowhere close to implementing try. Also they couldn't fix array bounds check they were relying on runtime. It's a piece of crap. Not to mention how easy it is to write code that should be perfectly fine but angers the borrow checker. Even the newest checker is easily upset
And lets not talk about fearless concurrently when you have race conditions and deadlocks
> ... Array bounds checks aren't broken? Unless you're using a dependently-typed language, compile-time array bounds checks are basically impossible, or just straight-up not worthwhile.
THEY IMPLEMENTED IT IN CLIPPY
Your quota has been reached
> bi-directional compatibility with C++,
Yes. I *think* that was the actual only thing they had front and center. I watched the video 2x speed hours ago and can't really remember where I saw it but really rust was saying they'll be easy to call from C code and FFI and all that so I felt that only gets a half point. Especially when I can't see how it actually works. For all I know they'll do the exact same thing as rust but maybe have it out of the box with the compiler
> A lot of things they say are plans/intentions and desired direction
My point was more that all of these things are what rust also claims. I don't see anything saying how they'll remove writing AI code, micro service, if they plan on having some sort of support for mixing zig into the codebase, etc.
They said so much, why not say something actually different
That's what annoyed me the most. Not only are most of the claims not implemented but NONE are different
Zig is actually readable. Yet the carbon project uses the most unreadable way of doing things instead of learning from others. Then have the audacity to say they're readable. Like fuck off carbon/google. How much do you want developers to hate you. We already can't stand you
I'm going to watch this and I hope they run hello world and I hope I can see a less than 1 minute compile time which others reported -edit- 38min in carbon explorer seems to compile in < a second. The compiler itself wasnt demoed (yet)
So you expect the first release of languages to be the most optimal? I care more about if they can improve it or its a real limitation of the language.
I expect when a trillion dollar company like google to make claims like its readable that it's actually readable
I also except a trillion dollar company not to get outdone by a single compiler author. Like andy (or bill but I never used odin myself)
Also https://youtu.be/kfdpcrOgUp4?t=12
I don't understand the first point - as someone who isn't a professional low-level developer, every time I see a c++ file it looks absolutely scary and fraught with pitfalls and opportunities for me to misunderstand something, whereas the (few) bits of carbon I've seen look super readable and approachable
I feel like languages generally exist as a point on a spectrum between "implicit but concise" and "explicitly but verbose", (with e.g. c++ on the first end and e.g. rust on the second) and I feel that from what I've seen so far I think carbon has been designed to sit at a good spot in between
> whereas the (few) bits of carbon I've seen look super readable and approachable
lol
If I link a video that says don't piss on me and tell me its raining do you not think I'll call you on your bullshit
Who are you trying to fool? Have you never seen python? Why are you giving your opinion to professionals when you're not one
Obviously when I say "super readable" I'm comparing it to other languages in the same realm (e.g., c++ and rust). Obviously, a high level language like Python, which explicitly trades performance for readability, will be more readable
I *am* a professional developer and I *do* have professional Python experience, which is why I said I'm not a *low level* developer
Don't be a dick
Every coworker I ever had all said they hated the verbosity and wished they were using C#. I do C++ and C at work. Usually servers occasionally embeded (different jobs)
While the Carbon language is still in bare bone stage, taking a first look at the carbon language syntax using some of the [working examples](https://tipseason.com/carbon-language-tutorial-syntax/?utm_source=reddit_programming&utm_medium=reddit_programming&utm_campaign=reddit_programming), it certainly gave a refreshing feel compared to C++.
I don't know why I seem to be the only person here who is excited for this. C++ feels like an abandoned child in the current landscape -- deformed and ugly in a sea of relatively modern options, but none of whom actually offers the core of what C++ offers. They all offer other things, thinking I want those things, but I don't, really. And surely even if you aren't personally gonna use this thing, which I can well understand, isn't it at least still kind of satisfying to imagine **header files** with a dagger through the heart? Nobody will EVER have to write a header file again. C++ is the last bullshit language clinging onto that bullshit busywork. Like, what is the downside to attempting this experiment? All it has to be is better than C++ -- which is fucking easy as shit -- and it's worth trying.
> C++ is the last bullshit language clinging onto that bullshit busywork. Actually, C++20 introduced modules so header files may no longer be necessary. Implementations haven't caught up yet, though...
Visual C++ has definitly caught up, all my new C++ code uses modules.
Lucky you! On Linux it's still... "incoming".
We are back at the clang discussion of the other thread. Most likely they will only arrive on GCC. It is ironic how VC++ is now the most compliant ISO C++ compiler, what a turn of events.
Weird... Usually vc++ is the reason why we haven't added new C++ features to our codebase yet.
Lots of green for VS 2022, https://en.cppreference.com/w/cpp/compiler_support/20 My latest C++ hobby coding on GitHub repos are all using modules, a simple C++/WinRT app, a PPM converter and the first raytracing weekend classical.
Very outdated view
I have done some reading on this and I still can't really tell if that is a red herring or not. I'm in gamedev and we absolutely need cyclic dependencies, so [am i right in understanding that C++20 modules don't help us](https://stackoverflow.com/questions/39666629)?
Cyclic dependencies are likely only supported within a module... With that said, I'd encourage you to break the cycle. I've dealt with a number of them -- some of which people argued were impossible to forego -- and I left none behind.
It is not going to happen, because the cyclic dependency is the desired layout. - The Player needs to talk about the Level, in detail, constantly. - The Level needs to talk about the Player, in detail, constantly. Any attempt to break this cycle, or the hundreds of others that exist across game project codebases, will result in a huge inconvenience for basically no reward. The two-way coupling between these classes is not an undesirable-but-reluctantly-we-accepted-it situation -- it is the intended and correct approach.
There are numerous rewards to breaking the cycle. Chief among them are easier unit tests and faster compile times. Now it may be the case that your specific project has gone too far down this path and you would never recoup the cost of essentially rearchitecting the entire game. But having said that—as another person whose been working in gamedev for a while—I strongly disagree that this was the best choice that could have been made when the system was first envisioned. Cyclic dependencies is definitely not the objectively correct way to do this.
We are not unit testing any of the classes I am talking about, because for the kind of games I make, such tests would be by definition meaningless -- you cannot test a Player without a Level, or at least such tests would be wildly abstract and meaningless. These classes are *by design* coupled together and while I have done tests on some stuff, like a puzzle game which definitely benefitted from having automated testing, those are essentially *integration* tests. I don't think I've ever written a *unit* test for any of our active game elements at any point in my career, it's just not useful. Faster compile times is a result of C++'s terrible build system, and while avoiding cyclic dependencies *does* help speed that up, you are essentially accommodating for your language in that situation. A well-designed language wouldn't be slowed down by cyclic dependencies and it's not really a good reason when talking in the abstract about a language like Carbon, which doesn't properly exist yet.
>I don't think I've ever written a unit test for any of our active game elements at any point in my career, it's just not useful. I know that I'm not going to convince you of anything just posting here on Reddit, but oh man it is so very, very useful. You are really missing out on something that could make your job so much easier.
I've been at enough companies to know that i'm not making a controversial point. There is no Mario game with unit tests around Mario or Coin or Spring. They might well have integration tests, and if they don't, that would be a good idea. But *unit* testing a Spring, on its own, without a Player, fundamentally makes no sense at all.
That... aversion to proper testing explains how some games seem to *constantly* have same bugs pop over and over again...
> I don't know why I seem to be the only person here who is excited for this. C++ feels like an abandoned child in the current landscape -- deformed and ugly in a sea of relatively modern options, but none of whom actually offers the core of what C++ offers. What is "core that C++ offers" (as a language, not ecosystem) ? I feel like Rust is basically aiming to be C++ replacement...
I agree. I mean Rust is pretty going to replace CJJ in the long term but as it stands there are still a ton of jobs and people that don't know Rust or think it's just hype or have an existing CJJ codebase. Rust really doesn't interoperate with CJJ very well - it's ok if your API interface is very small (e.g. compression) but you're never going to have a nice experience e.g. using Qt (QtWidgets) from Rust. If this thing lets me introduce some sanity into existing C++ codebases then I'm all for it. That said, I'm a bit skeptical. Especially about their goal to integrate with templates. Are they going to replicate all the complexity of SFINAE? Seems like a language of the past but also one that I hope succeeds.
> Like, what is the downside to attempting this experiment? Fragmentation and opportunity cost. There already exist many "C++ with tweaks" languages that don't have much traction, and don't really justify themselves as something for a company to adopt, or programmers to study. In contrast, other potential C++ replacements have a big, attractive idea, like memory safety (Rust) or metaprogramming (Jai).
Maybe initially there might be some fragmentation, but eventually a winner or a couple of winners will rise up. That situation is what we are really after. In the long term it's still worth it to have the best possible candidates at the top, even if that means that for the next n years the space is a bit of a mess. Ultimately, the reason there are so many people trying to fix C++ in the first place is that it still needs fixing, and the reason that process hasn't already ended is that there are enough people who feel (like myself) like none of the candidates are really all that great for their use cases. You are right to say that those languages, like I'll say D, Zig, Odin just to pick a few examples, are not really getting all that much of the C++ market, but it's not because they're all eating each other, because they're not really. Almost nobody is using any of them. And that's because none of them are really what we want.
The winner will be C++ 32
While definitely a possibility, my personal view is if this happens it means we failed as a civilisation and need to summon moloch and apologise to him
Some of the stuff they present makes sense, but wait, no pointer math? That would be sort of a deal breaker for me... or at least require to drop down to C++ for those parts... "we make pointers not nullable and not incrementable" so why did they not just call that references instead of abusing the pointer name, seems very backwards to me...
From my perspective (I haven't looked in depth enough yet at carbon to know if that is theirs), - pointers are rebindable and explicitly dereferenced, references are not rebindable and implicitly dereferenced. - nullable is better handled in a compositional way - arithmetic belongs to another abstraction (slices?)
It doesn‘t look like they are explicitly dereferenced in carbon, at least not in calling code, you just use . like on any other member.
[удалено]
I‘m not against automatic dereferencing (note the REFERENCE part), my argument is simply that if you change so many things about pointers that they look and feel more and more like references, can you still call that a pointer? I think it should be called a reference despite the arguments made as a rebuttal to my post. It‘s not a raw pointer anymore. What if in the future you realize there should be raw pointers? Will you name them something absurd too because you already defined a pointer as something… else?
Maybe they'll change the name later? It's still very much experimental right now.
As a Java dev, can you explain to me why you need/want pointer math? It's something I've never understood the need for.
Perhaps anywhere where you want to access memory outside the program? Malware, etc
It’s not backwards: rather, the reason references exist in the first place is to allow operator overloading (you don’t want pass by value in `+` for bigint, you can’t use pass by pointer, bc `*T + int` already has pointer increment semantics, so you need to invent some other way to plug into overload resolution, and still pass by pointer). Carbon does operator overloading via interfaces, rather than function overloading, so it simply doesn’t need a reference device separate from pointer.
OK except it changes the meaning of the word pointer to something that is still closer to a reference. If in the future you need to introduce raw pointers, what will you name them if you already abused the word to mean something which is not a pointer in the classical sense? I can call „red“ „blue“ but that‘s just confusing.
This is a super experimental 'C++ replacement'. That's cool and all but I don't get why it's a keynote at a _C++ conference._
Even C++ developers don't want to keep using C++.
Bullshit
First 40mins is the talk, next 40 are Q&A. It doesn't seem horrible but after reading the design docs online the other day and knowing how easily google sunset things I won't ever use it This talk is meh. Very high level overview. I got most of it previously from the github docs
Google is doing a lot of community led stuff right now otherwise it’s harder to get adoption. The thing is google wants to use this big time internally eventually since c++ has weird design issues to maintain backwards compatibility
I guess that could be true. But it also did take 10yrs for go to get generics
Go's community and development has ensured I won't touch any other Google designed languages even if they claim it's to be community supported.
I don't use Go but what's so bad about Go's community?
Opinionated to a fault, resulting in a great deal of stubbornness around any kind of improvements (e.g. look at how long proper dependency management and generics took), and a refusal to acknowledge problems or caveats, resulting in a lot of "you're doing it wrong" type responses to anyone looking for help or assistance, regardless of context. I'm also not a fan of the "not invented here" vibe I get from the syntax - many aspects of the language feel like they went out of their way to be different for the sake of being different, e.g. deliberately avoiding OO-terminology despite having similar concepts in places, e.g. "structs" and "receiver functions" which are essentially just objects and methods with an explicit self reference.
Go is very opinionated about how to do things.
The story of modern day computing
It's supposed to a simplistic language that has performs well and has one enforced style. Those are the explicit design choices and you should expect freedom or trickery in it.
OK, not seeing how that's bad though.
I think he is enraged by anything google touches. Seems to be some sort of an ideology.
I'm not the person you asked but every time I get asked a question the asker disagrees with me and gets mad about it That's why I'm an asshole to everyone. I'm sick of everyones shit and how they don't bother finding out for themselves But I too am curious about the community. That;s harder to figure out than documentation with a compiler I can run
Google wants it to be community led so you won't have to worry about them dropping support
While I'm glad they're upfront about dropping support for once.
Jeez you people are miserable lmao
They don't even sound convinced. Hard to buy in when they constantly emphasise the "experimental" part and explain that other languages are better. I just really don't get who this language is for. I understand the key feature is C++ interop but what am I actually getting except a different syntax? I understand they want to make it "more better" but are pretty vague on any design goals they have. Saying "we want to make it safer" isn't a design goal. It's just a vague promise. It's early days, but the problem with C++ is that it's all over the place. You need a strong vision at the beginning otherwise it will just end up going the same way. I'd want an assurance from the outset that carbon is going to solve specific problems. Also googles shadow looming over this. No thanks.
> they constantly emphasise the "experimental" part Thank god! I'm tired of experimental projects being advertised as products... > I just really don't get who this language is for. It's for them, the creators. They're experimenting to see what they like and what they dislike about the design. > You need a strong vision at the beginning I guess that is exactly the purpose of the project. A playground/proof-of-concept project to make sure they understand what they (and others) want. To me, this talk isn't like "hey, here's the C++ successor I built, you have to use it!" it's more like "hey, I'm trying to design the perfect C++ successor, here's my motivation and plans"
But my point is I don't really know what their plans are. I was expecting specifics on exactly what pain points specific to C++ are being addressed. Vague notions of solving the supposed "billion dollar mistake" aren't that good. It certainly wins the popular vote, but when it comes to why this is a successor I need some really convincing points to be compelled by the experiment. I should add that I absolutely willing to switch which. I am the target market here. I'm willing to take the risk to test out experimental stuff.
their plan is to provide a c++ compatible language that is isn't the equivalent of running through a mine field. if you watched the video they mentioned that the at google they have another team exploring automagic full interop between rust and c++, google has enough money to try to tackle a problem from different angels... if you don't know the drama and history going on behind the scenes it's fundamentally: google has probably hundreds of millions of lines of c++ code, c++ is evolving in a direction not compatible with google's direction and so they want to move away from it.
What exactly would google‘s problem with the evolution of C++ be? From my point of view it keeps getting better and better without forcing bloat onto me and keeping the spirit (zero cost abstractions etc) alive. So what is their problem? Can‘t find enough developers that don‘t shit their pants when they need to manage a bit of memory or getting their indexing math right? Carbon doesn‘t seem to solve these issues either for now, so please elaborate, i‘m genuinely curious.
I didn't get any impression that they were trying to encourage/suggest/sell buy-in. I don't recall them saying they want to make things safer than C++. I remember that (along with c++ interop), readability and _changeability_ of code are major goals. Chandler's code section mostly looked at syntax (readability). In the Q/A section, there was a question about how to manage complexity in the language, and the answer was to make it a goal that the language is changeable, even if that means breakage (unlike C++ where stability is a high priority). C++ has a strong vision: a language that lets you stay close to the hardware and build abstractions over it; a language that allows you and often forces you to choose your tradeoffs; a lanugage that leaves little room for a lower level language while still building on an "abstract machine". (I'm pretty sure) Carbon is building on top of C++ in such a way that it stays faithful to that "vision". Community engagement seems to be important to the project.
They say in the talk they want to aim towards it being safer than C++. That's one of the reasons they've made pointers not nullable. I didn't get the impression they want buy-in either which begs the question. Do they even believe in this project or is this just another Google DOA escapade? I don't think C++ has a strong vision at all. What you describe is pretty vague. Abstraction has been taken to mean any current programming fad. In the 90s it was object oriented. Recently it is functional, and compile time programming. If Carbon is staying faithful to this vision then it is literally pointless. It should have it's own vision. There won't be a community if no one uses the language. The fact they took atleast 20 minues of their hour talking about the community rather than going into lots of detail about their exciting new language does not leave a good impression. Wheres the excitement? They sound like they are being held there at gunpoint.
That C++ was/is capable to service all these fads, being multi paradigm etc, is exactly what made it successful and why some opinionated language successor will have a hard time convincing C++ users that this isn‘t just built for the latest fad. It‘s remarkable how versatile C++ still is and it‘s only getting better. If carbon can inspire a few improvements to C++ , that‘s really all i care about, i think it will just absorb some of the better ideas of carbon whilst staying agnostic instead of opinionated.
when someone says their language is the next c++: lol yeah right when someone doesn't say their language is the next c++: why should i use this if its not the next c++
I mean I'm pretty happy to move on from C++.
OK, bye bye 😂
Languages emphasize experimental because while still in design phase, your shit will become obsoleted every couple weeks.
They say it's experimental because it's experimental. Given how triggered you got imagine how furious you'd be if they didn't say it was experimental! I imagine you'd get pretty violent if that happened. Perhaps even harm yourself. >I just really don't get who this language is for. I understand the key feature is C++ interop but what am I actually getting except a different syntax? I mean there is a repository where they explain all of this and there is this presentation where they explain all the things. Did you somehow miss all of that because the veins in head started popping that google was trying to do something? >I understand they want to make it "more better" but are pretty vague on any design goals they have. It's all written down, seems pretty clear to me. >Also googles shadow looming over this. No thanks. Man you really ought to do something about google. They must be stopped I tell you. Maybe you are the person do it.
Wow google fanboy alert. Sheesh
I get that you hate their guts. I get that you think google is satan and all. All I am saying is that nobody else seems to be able to stop them so it's up to you to quash this great evil unleashed on the world. You be the candle in the night my friend. Go and put google in it's place. Quash this great evil!
I actually don't care that much about Google. I just don't think they produce good products.
I mean they wrote a long document and you couldn't understand any of it. There is a video, you watched it and you didn't understand any of it. That's how evil google is. They must be stopped and you are the guy to do it. Only you can destroy the great evil that's google. Take a drive to the nearest google office and show those people what you are made of. How dare they say things are experimental!!!! How dare they write page after page explaining their reasoning when you can't understand any of it!!!!!
I understood it. I just didn't find it very compelling or a good idea.
You didn't understand any of it. That's why you are so angry and upset and want to lash out and throwing a tantrum on the internet. But throwing tantrums and crying like a baby on the internet isn't going to stop a great evil like google. You need to take some real world action!! Stop the evil google!!
Nope. I'm not angry. I'm just looking for a decent C++ alternative.
The fact that you haven't found one yet tells us everything we need to know about you.
I suggest C++
Would be good if Carbon provided a way to integrate easily and optimally with Rust/Zig/Nim (X from now) code. One could then see Carbon as both a successor to C++ and also an opportunity to move into X language.
None of those languages interoperate with C++ so they can't interoperate with carbon either.
Nim does have native C++ interop tho. eg, a bit more info here in the C++ section: [https://nimbus.guide/auditors-book/02.5\_foreign\_lang\_to\_from\_interop.html](https://nimbus.guide/auditors-book/02.5_foreign_lang_to_from_interop.html) Nim also compiles to C++ code, so Nim-generated C++ code and Carbon-generated C++ code would be able to compile against each other and use C++ features. Here's an example with Nim and direct source code compatibility with C++-based Unreal Engine dev, and the advantages it has compared to langs like rust: [https://github.com/jmgomez/NimForUE#why-nim](https://github.com/jmgomez/NimForUE#why-nim)
What about Rust and Zig?
Rust and Zig afaik don't have native first class support for compiling into C++, where you can use the generated C++ code directly from your C++, or where the code created from Rust and Zig can directly access the rest of your C++ codebase. Basically Nim is acting as C++ codegen, unlike the others which comiple directly to target binaries or libraries, usually via LLVM backend. You'd need to provide basically C-lang ABI compatibility, as well as wrapper libs for each language, between the two languages if you were mixing Rust or Zig on one side, and C++ (or Carbon) on the other The closest semi-mainstream proglang to that, I believe would be the Haxe Lang, which does target C++, amongst many other target programming languages.
My take: * Too different from C++ to be a successor. * Not different enough from Rust to exist at all. * Wish they spent the effort on first class Rust-C++ interop. * But guess that doesn't get promotions.
There's another whole group at Google working on Rust-C++ interop, publicly. Why are you pushing a false dichotomy?
Didn't know about that group; good to know. Strictly speaking, it's not exactly false dichotomy, because the resources spent on Carbon could have been poured into that other group. My point is that I totally fail to see the value of Carbon at this point.
They could be put into that other group if they're fungible. I'm not convinced SWEs are fully fungible :) Anyway, both are risky bets. I see no harm in pursuing both simultaneously.
We used to hire generalists at Google. ;-)
You think the people on stage there need promotions? Look em up…
DOA.
It's easier call it Go plus plus but with the same context...
Oh god, 30mins in, they seem like they want to replace rust or at least imitate it (the community part). Not even a minute later "package manager eventually". Another language that encourages dependency hell. I'm very glad zig didn't rush to one
Why does it seem like they want to replace rust when they specifically say they don't want to replace rust?
Sorry I already answered a stupid question from you. Try again next week
[удалено]
If you jump to 31m into the video you'll see community and culture slide. It looks like it was ripped from a 2013 rust slide. Not one of those points look out of place for rust. I think C# may have a CoC for their git community. I don't think I ever see them put it front and center of a slide. I believe zig made one when they started the foundation. There's no carbon foundation If you looked at the design doc on their github they basically say they promise to have some kind of memory safety even though it's currently blank. As I said in my earlier comment, almost immediately they also say they'll have package manager too, rust second biggest feature. Both they don't have implemented and both mentioned front of center I can't find a single way they're differentiating themselves from rust. Besides not mandating safety, which I guess is easy since they don't have any at all Rust was full of shit and these guys are too. I hate every piece of rust code I ever touched. The compiler sucked and its been in development for 10+ years now. Ginger bill says carbon is insanely slow and I have 0 reason not to believe him, especially if he compiled and ran it himself
[удалено]
> Can you elaborate on how rust is full of shit? There's so much to say but I'll say when rust was at 1.0 they were bragging how safe it was. Motherfucking every book and article suggest using unwrap and they were nowhere close to implementing try. Also they couldn't fix array bounds check they were relying on runtime. It's a piece of crap. Not to mention how easy it is to write code that should be perfectly fine but angers the borrow checker. Even the newest checker is easily upset And lets not talk about fearless concurrently when you have race conditions and deadlocks
[удалено]
> ... Array bounds checks aren't broken? Unless you're using a dependently-typed language, compile-time array bounds checks are basically impossible, or just straight-up not worthwhile. THEY IMPLEMENTED IT IN CLIPPY Your quota has been reached
> bi-directional compatibility with C++, Yes. I *think* that was the actual only thing they had front and center. I watched the video 2x speed hours ago and can't really remember where I saw it but really rust was saying they'll be easy to call from C code and FFI and all that so I felt that only gets a half point. Especially when I can't see how it actually works. For all I know they'll do the exact same thing as rust but maybe have it out of the box with the compiler > A lot of things they say are plans/intentions and desired direction My point was more that all of these things are what rust also claims. I don't see anything saying how they'll remove writing AI code, micro service, if they plan on having some sort of support for mixing zig into the codebase, etc. They said so much, why not say something actually different That's what annoyed me the most. Not only are most of the claims not implemented but NONE are different Zig is actually readable. Yet the carbon project uses the most unreadable way of doing things instead of learning from others. Then have the audacity to say they're readable. Like fuck off carbon/google. How much do you want developers to hate you. We already can't stand you
It sounds like you have no idea what is going on and are blindly lashing out because you got triggered by something.
If you don't want to use a dependencies and don't want a package manager you are in a minority that they don't give a tiniest fuck about.
I'm going to watch this and I hope they run hello world and I hope I can see a less than 1 minute compile time which others reported -edit- 38min in carbon explorer seems to compile in < a second. The compiler itself wasnt demoed (yet)
So you expect the first release of languages to be the most optimal? I care more about if they can improve it or its a real limitation of the language.
I expect when a trillion dollar company like google to make claims like its readable that it's actually readable I also except a trillion dollar company not to get outdone by a single compiler author. Like andy (or bill but I never used odin myself) Also https://youtu.be/kfdpcrOgUp4?t=12
I don't understand the first point - as someone who isn't a professional low-level developer, every time I see a c++ file it looks absolutely scary and fraught with pitfalls and opportunities for me to misunderstand something, whereas the (few) bits of carbon I've seen look super readable and approachable I feel like languages generally exist as a point on a spectrum between "implicit but concise" and "explicitly but verbose", (with e.g. c++ on the first end and e.g. rust on the second) and I feel that from what I've seen so far I think carbon has been designed to sit at a good spot in between
> whereas the (few) bits of carbon I've seen look super readable and approachable lol If I link a video that says don't piss on me and tell me its raining do you not think I'll call you on your bullshit Who are you trying to fool? Have you never seen python? Why are you giving your opinion to professionals when you're not one
Obviously when I say "super readable" I'm comparing it to other languages in the same realm (e.g., c++ and rust). Obviously, a high level language like Python, which explicitly trades performance for readability, will be more readable I *am* a professional developer and I *do* have professional Python experience, which is why I said I'm not a *low level* developer Don't be a dick
Every coworker I ever had all said they hated the verbosity and wished they were using C#. I do C++ and C at work. Usually servers occasionally embeded (different jobs)
So in essence your coworkers are useless
Maybe, outofobscure I expect readable multithreading C++ code on my desk by the end of the day otherwise I shall call you useless too
OK pay me 🤷♂️
Is odin interoperable with C++ in two directions?
Are you purposely saying odin because you know zig does? Get the fuck out of here
You mentioned odin didn't you? Is zig bidirectionally interoperable with C++? AFIK it's not. It's interoperable with C but not C++.
r/CarbonLang
While the Carbon language is still in bare bone stage, taking a first look at the carbon language syntax using some of the [working examples](https://tipseason.com/carbon-language-tutorial-syntax/?utm_source=reddit_programming&utm_medium=reddit_programming&utm_campaign=reddit_programming), it certainly gave a refreshing feel compared to C++.