C never become a clusterfuck like C++ is Although it's possible that languages like Zig may become more popular in low level tasks eventually because of their easier to read syntax, integrated build systems and package managers, etc.
One thing I always need to know about when a language is promoted over C++ is, how much control do I have over the language, in that how much is it going to get in the way? Yes C++ is CAN be very performant, but that is because it doesn't get in the way of the writer. So it's almost entirely down to their skill on how good C++ code will be.
Perhaps but that's at the cost of safety. Rust is amazing as it gets C++ benefits at the cost of taking more time to write code. But you get certain guarantees.
@@leeroyjenkins0 Kotlin is made by JetBrains, not Google. Even though Google encourages its use for Android development, I would hardly say that it is "theirs".
I'd normally agree, but this isn't the same as Google services. Look at Go. It's been around quite a while now. These are also open-source projects. Even if Google "abandons" the language, there is nothing stopping the community from taking control anyways
If r/cpp is to believed...this project was born out of Google's frustration over the ISO C++ committee refusing to budge on the ABI issue. The greater meta theory is that this ABI protection stuff is mainly pushed by Microsoft due to their insistence on binary compatibility with older MSVC compilers/Windows versions. Stupid corporate drama over which massive tech company gets to control the language, in other words. I think we'd have to wait and see if this goes anywhere, though the syntax being so Rust like begs the question on why not just use Rust... Also promising C++ compatibility without C++ style syntax/templates? Whats the point? Just make a C interface (using the Hourglass pattern for C++) since almost every language in existence will be able to interface with it.
Google points, but about the c++ compat: I guess the point is that you can gradually port existing c++ code bases and improve them by writing new parts in carbon while having no effort of wrapping / porting the existing parts. And the syntax looks to be much cleaner (although different with the "modern" rust like style), so I don't see a problem if you can achieve the useful parts of templates with it
Well, I'd say that every company is pushing it's own agenda. M$ with C++/C#, Google with Go, Carbon, Kotlin, ... Apple with Swift/Objective-C, Java is still hanging in there for non mobile development, Rust is slowly taking over the low level world, even though C is still going strong there, ... And these are all, let's say general purpose programing languages. Let's not even start with the web oriented ones, or some of completely different paradigm like the functional ones... Soo... What I'm trying to say is that there's a lot of crocs but the pond is really not that big.
one of the major reasons rust adoption is slow is because of the small ecosystem. carbon allows you to use the thousands of c++ libs. this is why i think it will have much faster adoption.
Sure, standardization makes things less agile. But pre-standardization agility and 'wild west' of language implementations got us in this mess in the first place.
Can't wait to write about it in google+ and fork the project into repo at google code. Knowing google's track record,. I'm sure the project awaits long life ahead of it. In the meantime I might as well go with Zig. It also has interop with C/C++ as it libclang.
Weird.. I'm developing in asm/c/c++ for automotive industry..controllers for airbags and other safety/security devices and never heard of any reason why we should switch to something new. I can't even see any advantage of the "successors" for us.
Especially when all of them just copy TS and Swift syntax instead. The readability of these languages pisses me off because nothing is flush and information is never compact.
Google has said the optimal use case is writing Carbon code to interface with large C++ code bases with a more modern design. It sounds like making smaller projects for things like safety sensors isn't really the intended application, especially not right from the beginning. If anything it's more of a project for their own needs at Google that others are welcome to use if they want.
@@saadisave how is fn addTwoNumbers(left : i64, right : i64) -> i64 more flush and readable then int addTwoNumbers(int left, int right)? The extra syntax is unneccessary and just bloats the readability of your code, its already widely recognized that developers read code by symbols and the way its done in C++ is more then necessary to understand what its saying, it doesn't even help type generic syntax either because you just end up with the same problem.
@@Spartan322 the first thing is that you know exacly the size of the variable looking at the types, int is dependent to the platform rhe second is to know the diference between function and variable from the start, a var will be let or cont, depending on the write permission and function will be lines started with fn, in c++ you need to read the whole line to know which is which
It's better that rely on the other ones. It's a lesson we learned from BSD. Keep things thigh and inside the same project.
2 роки тому+14
I tested it and I'm not gonna lie: as long as LLVM has to be the brew version and can't use my already system installed LLVM 14, and as long as I need to use bazel as a build system on top of that very specific LLVM, I'm not touching Carbon. I am currently using gcc, MinGW, MSVC and LLVM to compile a C++ project, all with system installed compilers. It's just a broken build system off the bat
Programming languages are tools made to solve a problem. And each programmer may have their own unique preferences for what tool they want to use. The idea of "language successors" is inevitable, but suggesting that new language is supposed to outright replace another is a but "iffy". Of coarse, that's the purpose, but some people may still prefer an older language for whatever reason. Of coarse, I totally love the idea of a new language being built with C++ in mind. the C-family syntax is my favorite. But there are a host of things even within C++ that I was never a big fan of, like header files. And manually managing seperate files for things. I gladly accept the slighly longer "compilation times" that may come with the compiler needing to seperate the source file into seperate "header" and "implementation" files. It makes managing the files easier.
i think the functional/metaprogramming paradigm in modern c++ is where c++ is actually going. not carbon or another language. people shouldn't treat programming languages as trends to be replaced but as actual languages. c++ is here to stay and keep evolving.
@@Far-Reez wherever it has to go. If you think its ever going to go... good luck with that. If it was ever even going to disappear by any chance at all, thanks to nanite, lumen and UE5, C++'s lifetime has been increased by about a few hundred years i might say lol. Good luck getting rid of C++ now xD
@@Far-Reez They keep adding to the language, so it is becoming more and more complicated every version they release. C++11 was a breath of fresh air, though.. the std::atomic for example was a real game changer for low-level concurrency nibbling.. :D
Zig is interoperable with C only and not with C++ which has mangled functions. And currently it allows you to build applications with both C and C++ because of the built-in libclang.
I have a feeling that we're gonna see a lot of Rust vs Carbon. I mean sure people are comparing two languages until this day. But I feel like that topic is gonna matter the most.
Have you heard of C# ??? another language create by a corporation that trying to ride the C bandwagon, and now is used by lots of things that arent related to MS.
That can be said about many languages. The problem is that developers disagree on which parts of the "full language" would need to be in that smaller, cleaner language.
Recently I saw on GitHub that Robert Nystrom (author of some programming books e.g., crafting interpreters), had starred the Carbon repo. Now I know more about it, thanks!
Rust is less permissive and force you to write code in specific way. It is obvious that if something is less permissive you will be able to do just a subset of all possible thinks you can do in more permissive languages. Ok bro your turn
When I'm trying to build on an ARM Cortex M4, if I was using a simple superloop it was fine. But if I'm trying to run an RTOS and threader.... then I need to use C++. Anything that requires a HAL/middleware...needs C++, so by this... it replaced C.
0:43 i have trouble understanding how the code on the right is less understandable than the code on the left. it's probably the best syntax for expressing the use of combinators ive seen so far...
Honestly, the only things C++ need to be fully modern is an official package manager, get rid of header files and make strings not require the fuckin std namespace, and we're golden.
Modules make most of this fairly easy, package manager would be nice to have so long as we're not being locked by the compiler into it, unlike every single solution in the new languages.
I think your misunderstanding the point of header files. But a manager for libraries would be pretty nice.
2 роки тому
You know you can use CMakeLists as a package manager (yes, you can in case you didn't know), there are other package managers such as conan or vcpkg, and the string issue... 'using namespace std::string' will do your trick. It has to stay under std because it is part of the STL, it's not my string, it's not your string, it's the STL's string. And header files are necessary and will stay.
carbon is sadly not ready for production and you cant even compile a file without install bazel .Cant wait till it is mature meanwhile i guess i will stick to c++
My main languages are C++ and PHP. People have been saying that these are dying for the last 10 years that I've been a programmer, but they're just as relevant as ever before. This while other languages have slowly faded away. I don't mind learning a new language, but I don't see myself moving away from C++ anytime soon.
A major thing that immediately makes me not want to use Carbon is it having (seemingly) _only_ generic typing. In a medium to large codebase, this makes it non-obvious what type a variable is at a glance. Which is a problem, because you want to know what the input and output types are within any given block of code, otherwise it is nearly impossible to read and understand without having to keep a constant road map in your head as to what types the variable has been at different points in time. Keeping track of this throughout a codebase and having to keep yet another mental map in your head is both prone to mistakes and difficult.
I still hate Carbon like I hate Rust because of those type specifiers, why are we going back to pre-ALGOL type specifications? Its nowhere near as clean, in C++ I just do: int variable = but for some goddamn reason every single new language has to be var variable : i32 = or let variable : i32 = I don't mind the i32 type, not exactly sure its a big deal but whatever, but what in the hell are we not integrating the type into the declaration, it feels like the syntax added type hints as an afterthought, why do we keep resorting to typescript for things that don't need backwards compatibility?
@@projektplay3382 In a project that requires explicit type declaration in their style, that being majority of the big ones, its obnoxious and stupidly verbose. Also doesn't fix the fact that you have to declare some variable types explicitly still, and it it uses the exact same crap format. Also what was wrong with auto in C++ and var in C#? Implicit type behavior can be built into a pseudo-type without expecting everybody to use it over the much crappier typing specifier syntax. That also makes more sense because var/auto still declares the "type", just that its asking the compiler to handle figuring out what that type is automatically, in C++ we also get plenty of more manual typing features at compile-time, so you can define what you'd like the type to become relative to the work instead of being specific, templates are still more useful on the dev side then generics, having them both would be nice, but I prefer if I'm only to have one to have templates.
@@Spartan322 See, personally I don't mind the syntax of Rust (specially compared to the amount of syntactical confusion you can make with C++... for example the amount of ways in which you can initialize a fundamental type...) but it's fair that you find that part annoying. Personally I still prefer go with Rust (where appropriate) just for the memory safety and overall being a much nicer language to work with with a much more helpful compiler!
Why "fix" something if it's still good? C/C++ is one of the oldest languages, if anything "Java" was supposed to replace C++ because of it's hardware dependency. Therefore, C++ was already "replaced" with Java/C#.
I just watched that video (yesterday evening), its the reason I have been wasting my weekend writing a parser for new language. I agree that C++ could be easily improved. Can it be improved the way that he proposed? With a focus on interoperability and by comitee? Probably not. That has been the problem with some of the languages he mentioned. From a distance they look like successes, from an even slightly close up and honest view languages like TS and Swift are a mess. I have written both professionally incidentally and am fond of them despite it being patently obvious that they have been (in all likelihood) permanently spoiled by trying to get them to play nice with JS and Obj-C/C respectively.
So in first part of video you're saying that we must replace c++ because of it backward-compatibility, in second part you're saying we should use carbon over rust because of c++ backward-compatibility. Looks like mutually exclusive arguments.
Go is designed for different purpose, for developing distributed systems (very concurrency heavy stuff), not for system/high performant software. Rust appeared the same time Go appeared (no relation really) and in Mozilla.
@@dankondrtv Rust was developped for developing the new browser engine of Firefox. Go was developped to bring back the simplicity of C to object oriented programming. Go focuses on network and system programming. Both suit concurrent constraints.
@@StEvUgnIn rust yes and it isn’t against what I said, and Go was developed for its concurrent runtime that simplifies developing networking apps much easier in comparison with c++. Go isn’t good for system development of course, its runtime has overhead and grabs control from developer what isn’t good when you try to be as close to os as possible. At least you can remember that go has garbage collection and c++ and rust not
D already has pretty good C++ interop for the last 20 years and has been used in production by outfits like Remedy Games...but not the Google marketing arm.
It sounds like Carbon is Google’s response to Apple’s Swift programming language. Swift can be mixed with Obj-C/C++ code. Wasn’t the Clang LLVM compiler originally made by Apple for Swift?
I can see how Rust and Carbon could fill different roles. I don't see why start on Carbon, instead of using D-lang or maybe Zig (note: I know less about Zig). And as a long-time Mac user, I can't help but be amused that 'Carbon' was also the name Apple used for the slightly-modernized version of API's originally from the MacOS 9 era. It was a helpful bridge for a few years, and has been pretty much ignored ever since. And that was intentional role of that Carbon, from the very beginning.
C++ is not a successor of C, these are two different languages with different philosophies. C is still widely used so obviously C++ is not a replacement for it. Pretty much the same goes for JavaScript and TypeScript. "use bazel" - okay, I don't have good memories from using bazel "To install carbon use ruby" - what a mess :)
Nah, typescript to javascript is not even close with C++ to C C++ to C actually adds stuff like classes Ts to Js is more like adding guidelines to how you code. Honestly it's more similar to using a linter vs not using a linter Honestly there's not really a comparison for C and C++ relationship with other languages... definitely not js to ts or java to kotlin. Honestly a better comparison would be like using react vs using next.js
Stroustrup intended for C++ to replace C. He still gives talks about how C is unnecessary and how everyone should be using C++ for the things C does. The developer community doesn't agree with him, but that hasn't stopped him yet.
Another waste of time project, if only mfs would just learn the language instead of trying to come up with endless "successors". I hope C++ never goes away. And also the notion that C++ replaced C is incorrect at the very least, both are clearly still used for different things.
i for one am proud c++ doesnt have a package manager, the whole paradigm of you will download libraries over the network and update them all the time and have dependency chains so long you can never audit anything fully is a massive disaster
"C++ replaced C" Here we have a really good speaker that did a lot of really good cppcon talks, just not knowing that you can't replace C, because it will always be used for things like the Linux kernel.
100% agreed, specially stuff such as the linux kernel. How's the rust linux kernel shit going? last i heard it was a fucking broken mess lmao. You just cant replace C. Because using newer languages that add nothing new to the table just means rewriting in a different language, and rewriting in a different language means you can add new errors that werent there before, or have the potential hire programmers who are incompetent af because they think they are gods after watching some fireship video on rust lmao.
@noodlenoggin i love how people just try to say "Rust for embedded systems" or shit like that and im like... bruh, with that binary size, good luck working with limited memory and storage space lol... C is as simple as it can get, its just a simple layer of abstraction over a really well optimized compiler that converts everything into machine code for the specific architecture you are working on... like, you really cant get any better than that. C is literally everywhere in embedded systems and there is no way to replace it, because there is no reason to do so!
@@arunbeckham8384 because it’s different language of course, you can’t just easily add features to c++, as said in video, it’s very legacy heavy, you can check history of coroutines in c++ (Microsoft vs Google) to see how it affects new features and why coroutines in c++20 are so ugly
So, Carbon, made for being a succesor of C++ uses LLVM written in C/C++(if I am not mistaken) and that means that for maintaining Carbon, Google will use C++? I'm not sure if this makes sense
I have seen this argument a few times. I understand the idea behind it, though i disagree that is a bad thing. You can argue LLVM is bad and it should not be used. You can argue LLVM should not be written or should be written in X language. But to not use a tool just because it is written in X language makes no sense. Things you may not have understood or throughout about. Just because they use LLVM now does not mean they always will. They can write a Carbon compiler. Carbon will have tools written in carbon for using LLVMIR. They will not have to interface with C++ if they chose not to. LLVM maintains LLVM code, other then big reports and a few fixes here and there Carbon should not be maintaining LLVM. Carbon can support multiple back ends, nothing wrong with that. LLVM may be updated to add Carbon or other languages internally. There is nothing wrong about using a tool in a different language.
Did you catch Herb Sutter's CppCon 2022 talk "Can C++ be 10x Simpler & Safer"? It sounds like he's been working on something very similar to Carbon. ua-cam.com/video/ELeZAKCN4tY/v-deo.html
Carbon it is more marketing than a viable language. Carbon, like the previous versions, seems to have been designed by technicians, for technicians and not for programmers, even less for system programmers. Any language that does not use some relevant and aesthetic reserved words does not pass the test of time. No serious programmer would waste his time typing "fn" or scrolling through codes with such unsightly terms. An augmented C++ language would be a solution by cleaning up ambiguities and inconsistencies and not a replacement with another language.
Looks like Rust But Corporate™ to me. Yet anothet useless standard... Edit : Besides, we don't even need new languages. C is for embeed systems, Go is C if it was modern C++ is for perfs and backwards comp, Rust is for perfs and security at the cost of compatibility Java is for backwards comp and ease of use, Kotlin is that but actually good and modern. Javascript should be anihilated, typescript is tolerable. Asm works everywhere C# is great for modern windows-oriented typical desktop software code Add a C++ package manager and our list is complete. No need for more useless corporate crap.
asm works everywhere but depends on the architecture* but thats ok tbh, if you need to go as low as asm or machine language, it is expected that you might find some systems with a custom or different architectures or stuff like embedded systems.
If you want a good package manager for C/C++, try Portage. - Overlay system allows anyone with a git server to host their own repositories - USE flags allow you to basically configure build options both individually and across packages - the plethora of settings in make.conf allow you to configure your compile jobs however you want - package management == deployment due to it's build script based nature - literal user source patching for packages It's a beast to get a grip on, but it's so worth it.
@@PixLgams I love Portage, I'm a Gentoo daily user myself :) I meant moreso something that allows you to easily add libraries to a project, think of it as something like NPM or Rust's.
@@fleefie I did not anticipate to find you here, Larry. lol. Either way, although I can understand the call for local dependencies, not all package managers work like that. PIP would be a good example. What really blocks C(++) from receiving a package manager is that it's libraries highly depend on the platform you're developing for. It's not that C++ has no package manager it just has too many of them, all too tied to their platforms to actually take over. It makes sense though, as package management for these systems doesn't have to be limited to merely C.
1:18, prove why Java is easier. Garbage collector is not a reason, since it's bad, clunk, not elegant, and I believe slower than destructor. 1:38, it's half the C++ performance. And C++ can be very defensive, if you code it for that. 2:24, pointless. C++: auto s = "Low Level..."; int32_t x = 5, *p = &x; And C++20 has native optional strong type checking, via concepts. Templates were never the issue, even back to 1998, if you use some smart tags.
I love c++ because of its strict syntax, strict types and control. I have been developing simple graphical app with SFML in c#. I have come across a lot of issues with GC, references, copies which where creating random not traceable NullReference exceptions. While doing the same stuff in c++ I could simply use pointers and everything was fine. There is one thing that is really bad in c++ which is lack of package manager. Nugets in c#, maven in java. That is awesome that in java you can just paste 3 lines of XML and you have access to your libraries meanwhile in c++ writing CMakeLists.txt and struggling with setting environment variables properly.
It's really not that difficult to include packages. On Windows, just use Visual Studio and through a GUI you can add include and library directories. On Linux, you can either compile the library itself and just pass the include and library directories through the command line, configure CMake or Make to do it for you, or install the packages through the distribution package manager (i.e. APT) and use pkg-config to pass in the cflags and libflags to the compiler. You can even blend this in so that it's easier to develop the CMake or Make file and it works seamlessly all the same. It's just not a package manager, so if you wanted to make something that could configure your project easily and automatically download dependencies, you'd need to make a Python script or something.
@@edgeeffect i mean you won't ever (feel free to provide counter examples) accidentally do type punning in c++, it's a pretty explicit cast syntax. The only place where it implicitly casts to a void* (afaik) is in a function call, in which case the function is equipped to handle that as a void*. I might be wrong though, haven't worked with c++ for a while.
@@v01d_r34l1ty I know that I can do that. But still in VS you need to check library documentation or files and list the libs manually (also in Vs if you want to publis project on GitHub it will containe your paths). I know that cmake exists but I am not really good at it - I know the passics but still I can't avoid using direct paths on my pc. Also you need to check docs of each library because it is often different how you link it for each library - for example you need to include some additional libraries etc. I am not hating how it works but as I said - I love maven and nugets - those solutions are simply better. Simply you have to do much more manual work to include libraries
@@edgeeffect I meant what @donkey says. In python or js you don't have types at compile time and in huge projects it might be annoying to debug type mistakes from runtime errors. Also in python and JS when you create class you don't need to create variables but you can just write __self__.variable and it will magically create this variables. I am not big fun of this "it will do itself" approach.
C and C++ *do* have a package manager. In fact, multiple. Here a few examples: - APT - Arduino - Brew - git submodule - MSVC - pacman - Portage - RPM See a pattern? These are mostly system package managers, because they are system programming languages. When you're this low, you can't guarantee all programming infrastructure so having a separate package manager makes sense. It also helps as it keeps the language a standard rather than a service. Just how do you guys expect to write NodeJS once the NPM repositories are down?
2 роки тому+1
Modern CMakeLists can be used as a package manager
CarbonLANGuage Successor of c++ but used clang? Why, Google? Word of successor is too high, lol. There's vcpkg for c++ library manager, but manage by Microsoft. Someone more suggesting me for ziglang rather than this one, but just keep an eye on it.
@@thekeyboardwarrior1018 Are you writing the asm? I assume X86? What is the project for? There is most definitely documentation online but I would suggest opening an iso file and looking at its contents to start. You will see much more then a single executable. If you are only using a single executable in 16bit mode i believe you just need to find what file the VM loads and replace it. Though i have not done this and have to assume a few things so i may be wrong.
@@dynfoxx I am the one writing the ASM The project is for testing and security purposes, it also can convert APK/exe into a code the ASM can read and run
@@thekeyboardwarrior1018 Hmm, do you have code up? This is not my area of expertise but i can take a look if you have it posted somewhere. Are you just starting the project or do you have stuff ready?
“This language sucks so I’m gonna write a modern language and it’s main focus is so you can use it to use the shitty language”…. This is the dumbest idea I’ve ever heard google has already written two languages if they don’t like c++ then why not stop using c++ and use one of those languages.
Well I dare you to even try to refactor Chrome which is entirely written in C++. Modern web browsers are even more complicated than some modern operating systems(thanks Google and W3C for making web standards too complex for their own good). Google focuses on interoperability so that they can refactor chrome step by step and still release updates without getting stuck on rewritting it all. But given how google treats it's projects I'll not be too surprised if I see carbon in 5 years on that Google Graveyard site
they cant stop using C++, because nothing new they'll ever write will add anything substantial that C++ doesnt already have. There simply is no way to be better than C and C++ because they are as simple as it can get, and give you as much freedom as you can get. Its literally the perfect balance between low level and high level for human readability, and somehow people refuse to understand this. Not only that, but you cant just go and expect to rewrite all of the code from years and years worth of coding in just a few days with your new shiny language. Go ahead, i dare ya, rewrite all of google's code with carbon or some shit lmao. Its already pretty fucking broken as it is...
Come hang with me on Twitch! www.twitch.tv/LowLevelLearning
Nice to see Go getting an update after three years.
i hang on tree nit twitch xD 🐒
Who else is stoked to have recruiters hear of Carbon and start listing "3-5 years experience in Carbon" on job descriptions.
The people that worked on Carbon but had to move elsewhere "I mean technically..."
LOLOL
😆
Oh look, the same top comment that's on every Carbon video
Broke: "3-5 years of Carbon
Woke: "3-5 years of C+ (sic)"
That feeling when C was replaced but you are still working in pure C
C was never truly replaced
@@AlFredo-sx2yy I work in telcom, 5G L2, we use only C. L3 uses C++.
@@VeryAwesomeSheep yep, thats why C was never replaced. There's places where its still in use.
There is no reason to replace C honestly. C++ is just clustered, C is much cleaner
C never become a clusterfuck like C++ is
Although it's possible that languages like Zig may become more popular in low level tasks eventually because of their easier to read syntax, integrated build systems and package managers, etc.
C++ never *replaced* C. Lots of programmers continue to use C. I don't even think that was ever the intention of C++.
C++ was supposed to be the fat cap added on C... it never truly replaced it.
That's an absolute misnomer.
One thing I always need to know about when a language is promoted over C++ is, how much control do I have over the language, in that how much is it going to get in the way?
Yes C++ is CAN be very performant, but that is because it doesn't get in the way of the writer. So it's almost entirely down to their skill on how good C++ code will be.
Good point
@@LowLevelTV Hey, thanks.
You want flexibility. And that's what allows programmers to mess up the whole world with their bugs.
@@ohwow2074 Good.
Perhaps but that's at the cost of safety. Rust is amazing as it gets C++ benefits at the cost of taking more time to write code. But you get certain guarantees.
I’d never build a codebase around a google backed language. Too much risk of abandonment
100%
I never forget back in the day when my company migrate from JSF ro Angular2 🤣
learn GO.
@@leeroyjenkins0 Kotlin is made by JetBrains, not Google. Even though Google encourages its use for Android development, I would hardly say that it is "theirs".
I'd normally agree, but this isn't the same as Google services. Look at Go. It's been around quite a while now. These are also open-source projects. Even if Google "abandons" the language, there is nothing stopping the community from taking control anyways
If r/cpp is to believed...this project was born out of Google's frustration over the ISO C++ committee refusing to budge on the ABI issue. The greater meta theory is that this ABI protection stuff is mainly pushed by Microsoft due to their insistence on binary compatibility with older MSVC compilers/Windows versions. Stupid corporate drama over which massive tech company gets to control the language, in other words.
I think we'd have to wait and see if this goes anywhere, though the syntax being so Rust like begs the question on why not just use Rust...
Also promising C++ compatibility without C++ style syntax/templates? Whats the point? Just make a C interface (using the Hourglass pattern for C++) since almost every language in existence will be able to interface with it.
Google points, but about the c++ compat: I guess the point is that you can gradually port existing c++ code bases and improve them by writing new parts in carbon while having no effort of wrapping / porting the existing parts. And the syntax looks to be much cleaner (although different with the "modern" rust like style), so I don't see a problem if you can achieve the useful parts of templates with it
Yet another thing we need right now - keeping up with dozens of ABI versions...
Well, I'd say that every company is pushing it's own agenda. M$ with C++/C#, Google with Go, Carbon, Kotlin, ... Apple with Swift/Objective-C, Java is still hanging in there for non mobile development, Rust is slowly taking over the low level world, even though C is still going strong there, ... And these are all, let's say general purpose programing languages. Let's not even start with the web oriented ones, or some of completely different paradigm like the functional ones... Soo... What I'm trying to say is that there's a lot of crocs but the pond is really not that big.
one of the major reasons rust adoption is slow is because of the small ecosystem. carbon allows you to use the thousands of c++ libs. this is why i think it will have much faster adoption.
@@askeladden450 Why did you have to hit the wall today? WHY?! :(
10 years from now someone will mention the Carbon language only to be greeted by blank stares.
Just like Fuchsia
Sure, standardization makes things less agile. But pre-standardization agility and 'wild west' of language implementations got us in this mess in the first place.
Truth hath been spoken, my friend
Can't wait to write about it in google+ and fork the project into repo at google code.
Knowing google's track record,. I'm sure the project awaits long life ahead of it.
In the meantime I might as well go with Zig. It also has interop with C/C++ as it libclang.
😁👍
Google only have a bad track record with their apps, their programming langs are still active.
or nim, imo a better and more mature language, with more compile backends with interop, or compiling with llvm
Are you aware that Google engineers wrote go and dart?
Weird..
I'm developing in asm/c/c++ for automotive industry..controllers for airbags and other safety/security devices and never heard of any reason why we should switch to something new. I can't even see any advantage of the "successors" for us.
Especially when all of them just copy TS and Swift syntax instead. The readability of these languages pisses me off because nothing is flush and information is never compact.
Google has said the optimal use case is writing Carbon code to interface with large C++ code bases with a more modern design. It sounds like making smaller projects for things like safety sensors isn't really the intended application, especially not right from the beginning. If anything it's more of a project for their own needs at Google that others are welcome to use if they want.
@@Spartan322 This has to be sarcasm
@@saadisave how is fn addTwoNumbers(left : i64, right : i64) -> i64 more flush and readable then int addTwoNumbers(int left, int right)? The extra syntax is unneccessary and just bloats the readability of your code, its already widely recognized that developers read code by symbols and the way its done in C++ is more then necessary to understand what its saying, it doesn't even help type generic syntax either because you just end up with the same problem.
@@Spartan322 the first thing is that you know exacly the size of the variable looking at the types, int is dependent to the platform rhe second is to know the diference between function and variable from the start, a var will be let or cont, depending on the write permission and function will be lines started with fn, in c++ you need to read the whole line to know which is which
Love when every shitlang has its own package repository.
Did somebody say "cargo cult"?
It's better that rely on the other ones.
It's a lesson we learned from BSD. Keep things thigh and inside the same project.
I tested it and I'm not gonna lie: as long as LLVM has to be the brew version and can't use my already system installed LLVM 14, and as long as I need to use bazel as a build system on top of that very specific LLVM, I'm not touching Carbon. I am currently using gcc, MinGW, MSVC and LLVM to compile a C++ project, all with system installed compilers. It's just a broken build system off the bat
If you have an experience with C++, JS, Kotlin over 5 years, then you can claim 5 years experience with Carbon.
Another project for google graveyard?
Programming languages are tools made to solve a problem. And each programmer may have their own unique preferences for what tool they want to use. The idea of "language successors" is inevitable, but suggesting that new language is supposed to outright replace another is a but "iffy". Of coarse, that's the purpose, but some people may still prefer an older language for whatever reason.
Of coarse, I totally love the idea of a new language being built with C++ in mind. the C-family syntax is my favorite. But there are a host of things even within C++ that I was never a big fan of, like header files. And manually managing seperate files for things. I gladly accept the slighly longer "compilation times" that may come with the compiler needing to seperate the source file into seperate "header" and "implementation" files. It makes managing the files easier.
i think the functional/metaprogramming paradigm in modern c++ is where c++ is actually going. not carbon or another language. people shouldn't treat programming languages as trends to be replaced but as actual languages. c++ is here to stay and keep evolving.
Uhm...
Where C++ is actually going?
@@Far-Reez wherever it has to go. If you think its ever going to go... good luck with that. If it was ever even going to disappear by any chance at all, thanks to nanite, lumen and UE5, C++'s lifetime has been increased by about a few hundred years i might say lol. Good luck getting rid of C++ now xD
@@Far-Reez it might not ultimately but this is what i think for now.
@@Far-Reez They keep adding to the language, so it is becoming more and more complicated every version they release. C++11 was a breath of fresh air, though.. the std::atomic for example was a real game changer for low-level concurrency nibbling.. :D
But doesn't Zig already do this? It's already interoperable with C/C++ and it's very fast and easy to use.
Zig is interoperable with C only and not with C++ which has mangled functions.
And currently it allows you to build applications with both C and C++ because of the built-in libclang.
also can do it with nim, as of years ago, with c, c++, or objc (not sure about more than one of those at a time)
I have a feeling that we're gonna see a lot of Rust vs Carbon. I mean sure people are comparing two languages until this day. But I feel like that topic is gonna matter the most.
Carbon will win this war because corporations will love to just put their old code bases on the side and keep them working.
Wait... The build system is google owned as well...? That's a no no
Have you heard of C# ??? another language create by a corporation that trying to ride the C bandwagon, and now is used by lots of things that arent related to MS.
"Inside C++ there is a smaller, cleaner language trying to get out".
That can be said about many languages. The problem is that developers disagree on which parts of the "full language" would need to be in that smaller, cleaner language.
@@garanceadrosehn9691 If it's Turing complete then you can do the minimum, do the rest as libs and done.
We call that language C
Recently I saw on GitHub that Robert Nystrom (author of some programming books e.g., crafting interpreters), had starred the Carbon repo. Now I know more about it, thanks!
Great, when there is a stable version, ecosystem of libraries and community support, frameworks and documentation in 20 years I'll check it out.
The rust community is going to flip when they hear "things that rust can't do"
Rust is less permissive and force you to write code in specific way. It is obvious that if something is less permissive you will be able to do just a subset of all possible thinks you can do in more permissive languages. Ok bro your turn
The rust community is permanently frothing at the mouth typing away in comment sections instead of writing code.
C++ is popular but not quite the successor of C.
It has not "replaced" C at all.
When I'm trying to build on an ARM Cortex M4, if I was using a simple superloop it was fine.
But if I'm trying to run an RTOS and threader.... then I need to use C++.
Anything that requires a HAL/middleware...needs C++, so by this... it replaced C.
0:43 i have trouble understanding how the code on the right is less understandable than the code on the left. it's probably the best syntax for expressing the use of combinators ive seen so far...
C++ never replaced C
Honestly, the only things C++ need to be fully modern is an official package manager, get rid of header files and make strings not require the fuckin std namespace, and we're golden.
Modules make most of this fairly easy, package manager would be nice to have so long as we're not being locked by the compiler into it, unlike every single solution in the new languages.
You want std::string as a built-in string keyword? "Don't pay for what you don't use" - what if I have a better string?
@@Nohbdy_Ahtall class BetterString { }; (Same things on C#)
I think your misunderstanding the point of header files. But a manager for libraries would be pretty nice.
You know you can use CMakeLists as a package manager (yes, you can in case you didn't know), there are other package managers such as conan or vcpkg, and the string issue... 'using namespace std::string' will do your trick. It has to stay under std because it is part of the STL, it's not my string, it's not your string, it's the STL's string. And header files are necessary and will stay.
carbon is sadly not ready for production and you cant even compile a file without install bazel .Cant wait till it is mature meanwhile i guess i will stick to c++
I'd like to know where D Lang fits into this conversation regarding C/C++ interoperability
My main languages are C++ and PHP. People have been saying that these are dying for the last 10 years that I've been a programmer, but they're just as relevant as ever before. This while other languages have slowly faded away. I don't mind learning a new language, but I don't see myself moving away from C++ anytime soon.
Wished the Carbon team would prioritize memory safety a lot higher...
A major thing that immediately makes me not want to use Carbon is it having (seemingly) _only_ generic typing. In a medium to large codebase, this makes it non-obvious what type a variable is at a glance. Which is a problem, because you want to know what the input and output types are within any given block of code, otherwise it is nearly impossible to read and understand without having to keep a constant road map in your head as to what types the variable has been at different points in time. Keeping track of this throughout a codebase and having to keep yet another mental map in your head is both prone to mistakes and difficult.
By generic typing you mean u32 etc?
@@williamdrum9899 more like auto :)
I still hate Carbon like I hate Rust because of those type specifiers, why are we going back to pre-ALGOL type specifications? Its nowhere near as clean, in C++ I just do:
int variable =
but for some goddamn reason every single new language has to be
var variable : i32 =
or
let variable : i32 =
I don't mind the i32 type, not exactly sure its a big deal but whatever, but what in the hell are we not integrating the type into the declaration, it feels like the syntax added type hints as an afterthought, why do we keep resorting to typescript for things that don't need backwards compatibility?
rust compiler can implicitly infer the type though, `let foo = 30` (defaults to i32) or `let bar = true' (bool)
in most of time it's declaring types automaticly and it's look nicely if you using generics and traits
@@projektplay3382 In a project that requires explicit type declaration in their style, that being majority of the big ones, its obnoxious and stupidly verbose. Also doesn't fix the fact that you have to declare some variable types explicitly still, and it it uses the exact same crap format.
Also what was wrong with auto in C++ and var in C#? Implicit type behavior can be built into a pseudo-type without expecting everybody to use it over the much crappier typing specifier syntax. That also makes more sense because var/auto still declares the "type", just that its asking the compiler to handle figuring out what that type is automatically, in C++ we also get plenty of more manual typing features at compile-time, so you can define what you'd like the type to become relative to the work instead of being specific, templates are still more useful on the dev side then generics, having them both would be nice, but I prefer if I'm only to have one to have templates.
Can't agree more!!! I still don't understand why they have to put the type after variable and make programmers need to type more characters.
@@Spartan322 See, personally I don't mind the syntax of Rust (specially compared to the amount of syntactical confusion you can make with C++... for example the amount of ways in which you can initialize a fundamental type...) but it's fair that you find that part annoying.
Personally I still prefer go with Rust (where appropriate) just for the memory safety and overall being a much nicer language to work with with a much more helpful compiler!
All this work on C++ and they’re just making the language simpler and more C-like, but with attempts at memory safety.
It should also allow simple pointer manipulation (no borrowing rules) which is needed for any advanced data structure.
You could access it as a C-style array in C++, but I'm not sure how that would work in Carbon.
Oxidised Fe > Carbon
Why "fix" something if it's still good?
C/C++ is one of the oldest languages, if anything "Java" was supposed to replace C++ because of it's hardware dependency.
Therefore, C++ was already "replaced" with Java/C#.
Java and C3 are a bunch of garbage
Only GO, Rust or Haskell could be that.
I just watched that video (yesterday evening), its the reason I have been wasting my weekend writing a parser for new language.
I agree that C++ could be easily improved. Can it be improved the way that he proposed? With a focus on interoperability and by comitee? Probably not. That has been the problem with some of the languages he mentioned.
From a distance they look like successes, from an even slightly close up and honest view languages like TS and Swift are a mess.
I have written both professionally incidentally and am fond of them despite it being patently obvious that they have been (in all likelihood) permanently spoiled by trying to get them to play nice with JS and Obj-C/C respectively.
So in first part of video you're saying that we must replace c++ because of it backward-compatibility, in second part you're saying we should use carbon over rust because of c++ backward-compatibility. Looks like mutually exclusive arguments.
Carbon is the language that well be talking about in 3 years or more. Not now. For now in the meantime its Rust and still C++.
Google has been trying to replace C++ with Go. It resulted in the birth of Rust and D language.
Go is designed for different purpose, for developing distributed systems (very concurrency heavy stuff), not for system/high performant software. Rust appeared the same time Go appeared (no relation really) and in Mozilla.
@@dankondrtv Rust was developped for developing the new browser engine of Firefox. Go was developped to bring back the simplicity of C to object oriented programming. Go focuses on network and system programming. Both suit concurrent constraints.
@@StEvUgnIn rust yes and it isn’t against what I said, and Go was developed for its concurrent runtime that simplifies developing networking apps much easier in comparison with c++. Go isn’t good for system development of course, its runtime has overhead and grabs control from developer what isn’t good when you try to be as close to os as possible. At least you can remember that go has garbage collection and c++ and rust not
@@dankondrtv By system development, I mean user programming and not operating system nor kernelspace stuff.
@@dankondrtv I am well aware but you can disable garbage collection. Same for D language.
Didn't Microsoft tried the same?
So... big g wants to reolace c++ with something they own... evil intensifies
Sooo... Why does it go away with the syntax of C/C++/Java/C# ... and adopts Rust like syntax?
0:45 c'mon, what is wrong with that? It's easier to read, it might be more performant and safer, do you know there is a bug in the C++98 version?
D already has pretty good C++ interop for the last 20 years and has been used in production by outfits like Remedy Games...but not the Google marketing arm.
It sounds like Carbon is Google’s response to Apple’s Swift programming language. Swift can be mixed with Obj-C/C++ code. Wasn’t the Clang LLVM compiler originally made by Apple for Swift?
This is just funny. C++ never dies because it's a huge super fast language and useful for every situation in back-end. "Wish you huge luck Google"
Those "successor" languages you mention are barely known.
I can see how Rust and Carbon could fill different roles.
I don't see why start on Carbon, instead of using D-lang or maybe Zig (note: I know less about Zig).
And as a long-time Mac user, I can't help but be amused that 'Carbon' was also the name Apple used for the slightly-modernized version of API's originally from the MacOS 9 era. It was a helpful bridge for a few years, and has been pretty much ignored ever since. And that was intentional role of that Carbon, from the very beginning.
I thought C# is the successor of C++
Yeah me 2
C++ is not a successor of C, these are two different languages with different philosophies. C is still widely used so obviously C++ is not a replacement for it.
Pretty much the same goes for JavaScript and TypeScript.
"use bazel" - okay, I don't have good memories from using bazel
"To install carbon use ruby" - what a mess :)
Nah, typescript to javascript is not even close with C++ to C
C++ to C actually adds stuff like classes
Ts to Js is more like adding guidelines to how you code. Honestly it's more similar to using a linter vs not using a linter
Honestly there's not really a comparison for C and C++ relationship with other languages... definitely not js to ts or java to kotlin.
Honestly a better comparison would be like using react vs using next.js
Stroustrup intended for C++ to replace C. He still gives talks about how C is unnecessary and how everyone should be using C++ for the things C does.
The developer community doesn't agree with him, but that hasn't stopped him yet.
This looks interesting, but I find the idea of Google criticizing the ISO hilarious, if not a bit concerning.
Another waste of time project, if only mfs would just learn the language instead of trying to come up with endless "successors". I hope C++ never goes away. And also the notion that C++ replaced C is incorrect at the very least, both are clearly still used for different things.
C++ has never replaced C - it's just a language based on C which for some reason became popular.
because C doesn't have OOP... the closest you'll get is struct. and even then.. .it's not the best compared to C++
Biased but I think rust can be a good successor that being said love hate relationship with c++
i for one am proud c++ doesnt have a package manager, the whole paradigm of you will download libraries over the network and update them all the time and have dependency chains so long you can never audit anything fully is a massive disaster
Will this end like Google+ ? Deja Vu ?
your two examples for “confusing syntax” looked much easier in the C++20 versions…
"C++ replaced C"
Here we have a really good speaker that did a lot of really good cppcon talks, just not knowing that you can't replace C, because it will always be used for things like the Linux kernel.
100% agreed, specially stuff such as the linux kernel. How's the rust linux kernel shit going? last i heard it was a fucking broken mess lmao. You just cant replace C. Because using newer languages that add nothing new to the table just means rewriting in a different language, and rewriting in a different language means you can add new errors that werent there before, or have the potential hire programmers who are incompetent af because they think they are gods after watching some fireship video on rust lmao.
@noodlenoggin i love how people just try to say "Rust for embedded systems" or shit like that and im like... bruh, with that binary size, good luck working with limited memory and storage space lol... C is as simple as it can get, its just a simple layer of abstraction over a really well optimized compiler that converts everything into machine code for the specific architecture you are working on... like, you really cant get any better than that. C is literally everywhere in embedded systems and there is no way to replace it, because there is no reason to do so!
zig or go are actual c successors kinda because they're not interoperable
I love them to update c++ in future instead of killing it.
That's kind of what they're doing, treating Carbon like an extension to C++ instead of a replacement.
@@LowLevelTV awesome 👍 but why to change name to carbon. They can just keep the same name and release new update.
@@arunbeckham8384 not the same language, not the same people, not the same standard.
@@arunbeckham8384 because it’s different language of course, you can’t just easily add features to c++, as said in video, it’s very legacy heavy, you can check history of coroutines in c++ (Microsoft vs Google) to see how it affects new features and why coroutines in c++20 are so ugly
@@dankondrtv oh okay thanks for making me understand. I will check that out.
C is still powerful so…
So, Carbon, made for being a succesor of C++ uses LLVM written in C/C++(if I am not mistaken) and that means that for maintaining Carbon, Google will use C++?
I'm not sure if this makes sense
I have seen this argument a few times. I understand the idea behind it, though i disagree that is a bad thing.
You can argue LLVM is bad and it should not be used. You can argue LLVM should not be written or should be written in X language.
But to not use a tool just because it is written in X language makes no sense.
Things you may not have understood or throughout about.
Just because they use LLVM now does not mean they always will. They can write a Carbon compiler.
Carbon will have tools written in carbon for using LLVMIR. They will not have to interface with C++ if they chose not to.
LLVM maintains LLVM code, other then big reports and a few fixes here and there Carbon should not be maintaining LLVM.
Carbon can support multiple back ends, nothing wrong with that.
LLVM may be updated to add Carbon or other languages internally.
There is nothing wrong about using a tool in a different language.
Me who just started: WAIT, LET ME TELL YOU SOMETHING!
Do you use a tiled wm on a mac? How hard is it to configure? 🤔
I'm comfortable with Rust. I'll pass on Carbon until it matures.
Totally respectable. This is going to be a baby project for a WHILE.
Rust itself still has some maturing to do (eco system).
Carbon at least gonna take a decade or smth
@@sohn7767 we'll be reading about it on Google Graveyard long before that. This isn't gonna last a decade
I thought Rust and Go were competing for being that successor
go is more of a c successor, and yeah rust is the most popular cpp successor.
@@jlacr8056 I think of Go as a better Node.js, because in the end of the day Go still uses garbage collection, so it could never replace C.
Go is language for web and microservices it is not for system programming like C/C++ or Rust
@@andrescamilo7406 I mean, I’ve actually been able to program Go programs to be for my system. Granted, they were smaller programs
Sure we'll rewrite all the game engines with carbon...
"Every major language have a successor. "
No. Python hasn't. Cause it already PERFECT!
Python 2 → Python 3.
It succeeded itself.
@@cpK054L Of course. I think, it become something the way better.
Did you catch Herb Sutter's CppCon 2022 talk "Can C++ be 10x Simpler & Safer"? It sounds like he's been working on something very similar to Carbon.
ua-cam.com/video/ELeZAKCN4tY/v-deo.html
in what I know D programming language was another language that wanted to be the successor of C++, Carbon looks like Rust.
So, Google rejected Max Howell but keeps using Homebrew a project he created? You don't think I am capable to work for you but you admire my work!
Why didn't they try to enhance Go and advance it further on instead of making another language :S
C and C++ is Immortal
One thing i have with C++ in common is never dying so good luck Google
Carbon it is more marketing than a viable language. Carbon, like the previous versions, seems to have been designed by technicians, for technicians and not for programmers, even less for system programmers. Any language that does not use some relevant and aesthetic reserved words does not pass the test of time. No serious programmer would waste his time typing "fn" or scrolling through codes with such unsightly terms. An augmented C++ language would be a solution by cleaning up ambiguities and inconsistencies and not a replacement with another language.
"But wait.... what about Rust?" .... I liked that.
Sounds like c++ with extra steps... Always 🌞...
A bigger mess.
Want to work for Google....!?
No thanks
It's definitely clunky but it's also BRAND new lol
Looks like Rust But Corporate™ to me. Yet anothet useless standard...
Edit : Besides, we don't even need new languages.
C is for embeed systems, Go is C if it was modern
C++ is for perfs and backwards comp, Rust is for perfs and security at the cost of compatibility
Java is for backwards comp and ease of use, Kotlin is that but actually good and modern.
Javascript should be anihilated, typescript is tolerable.
Asm works everywhere
C# is great for modern windows-oriented typical desktop software code
Add a C++ package manager and our list is complete. No need for more useless corporate crap.
asm works everywhere but depends on the architecture* but thats ok tbh, if you need to go as low as asm or machine language, it is expected that you might find some systems with a custom or different architectures or stuff like embedded systems.
If you want a good package manager for C/C++, try Portage.
- Overlay system allows anyone with a git server to host their own repositories
- USE flags allow you to basically configure build options both individually and across packages
- the plethora of settings in make.conf allow you to configure your compile jobs however you want
- package management == deployment due to it's build script based nature
- literal user source patching for packages
It's a beast to get a grip on, but it's so worth it.
@@PixLgams I love Portage, I'm a Gentoo daily user myself :)
I meant moreso something that allows you to easily add libraries to a project, think of it as something like NPM or Rust's.
@@fleefie I did not anticipate to find you here, Larry. lol.
Either way, although I can understand the call for local dependencies, not all package managers work like that. PIP would be a good example.
What really blocks C(++) from receiving a package manager is that it's libraries highly depend on the platform you're developing for. It's not that C++ has no package manager it just has too many of them, all too tied to their platforms to actually take over. It makes sense though, as package management for these systems doesn't have to be limited to merely C.
@@PixLgams Oh well, that makes sense actually. Thanks for the explaination !
1:18, prove why Java is easier. Garbage collector is not a reason, since it's bad, clunk, not elegant, and I believe slower than destructor.
1:38, it's half the C++ performance. And C++ can be very defensive, if you code it for that.
2:24, pointless. C++:
auto s = "Low Level...";
int32_t x = 5, *p = &x;
And C++20 has native optional strong type checking, via concepts. Templates were never the issue, even back to 1998, if you use some smart tags.
Well, next comes C++++
C#
I love c++ because of its strict syntax, strict types and control. I have been developing simple graphical app with SFML in c#. I have come across a lot of issues with GC, references, copies which where creating random not traceable NullReference exceptions. While doing the same stuff in c++ I could simply use pointers and everything was fine. There is one thing that is really bad in c++ which is lack of package manager. Nugets in c#, maven in java. That is awesome that in java you can just paste 3 lines of XML and you have access to your libraries meanwhile in c++ writing CMakeLists.txt and struggling with setting environment variables properly.
Uuuum.... excuse ne?! Strict types?!
Maybe "lax strict-ish types" until you can't cast to a void pointer anymore. ;)
It's really not that difficult to include packages. On Windows, just use Visual Studio and through a GUI you can add include and library directories. On Linux, you can either compile the library itself and just pass the include and library directories through the command line, configure CMake or Make to do it for you, or install the packages through the distribution package manager (i.e. APT) and use pkg-config to pass in the cflags and libflags to the compiler. You can even blend this in so that it's easier to develop the CMake or Make file and it works seamlessly all the same. It's just not a package manager, so if you wanted to make something that could configure your project easily and automatically download dependencies, you'd need to make a Python script or something.
@@edgeeffect i mean you won't ever (feel free to provide counter examples) accidentally do type punning in c++, it's a pretty explicit cast syntax. The only place where it implicitly casts to a void* (afaik) is in a function call, in which case the function is equipped to handle that as a void*.
I might be wrong though, haven't worked with c++ for a while.
@@v01d_r34l1ty I know that I can do that. But still in VS you need to check library documentation or files and list the libs manually (also in Vs if you want to publis project on GitHub it will containe your paths). I know that cmake exists but I am not really good at it - I know the passics but still I can't avoid using direct paths on my pc. Also you need to check docs of each library because it is often different how you link it for each library - for example you need to include some additional libraries etc.
I am not hating how it works but as I said - I love maven and nugets - those solutions are simply better.
Simply you have to do much more manual work to include libraries
@@edgeeffect I meant what @donkey says. In python or js you don't have types at compile time and in huge projects it might be annoying to debug type mistakes from runtime errors.
Also in python and JS when you create class you don't need to create variables but you can just write __self__.variable and it will magically create this variables. I am not big fun of this "it will do itself" approach.
C and C++ *do* have a package manager. In fact, multiple. Here a few examples:
- APT
- Arduino
- Brew
- git submodule
- MSVC
- pacman
- Portage
- RPM
See a pattern? These are mostly system package managers, because they are system programming languages.
When you're this low, you can't guarantee all programming infrastructure so having a separate package manager makes sense. It also helps as it keeps the language a standard rather than a service. Just how do you guys expect to write NodeJS once the NPM repositories are down?
Modern CMakeLists can be used as a package manager
cpp will never die, as gamedev still depends on cpp.
what will follow dart and go?
Rust isn't designed to be compatible with C++. But there's no problem. LLVM makes all work, so we can simply use C++ code from Rust
CarbonLANGuage
Successor of c++ but used clang? Why, Google?
Word of successor is too high, lol.
There's vcpkg for c++ library manager, but manage by Microsoft.
Someone more suggesting me for ziglang rather than this one, but just keep an eye on it.
Please talk about Ecosia they are a search engine that plants trees
how to install it in window 10 and like play with it a little i try do download it but i have no idea how
I think it will be ready in 4 years like what happened with Go
Well, they made D to address these issues but it went _nowhere._
C++ is very complicated and has baffle syntaxes
What's the problem with using Rust or Odin over Carbon?
No, I'm serious. I'd like to ask Chandler Carruth that question.
C++ did not replace C though.
What next generation languages are there?
Fetlang
Can you make a video on how to turn an asm file into a bootable image?
Bootable for what? There are videos out there but you would need to be more specific.
@@dynfoxx bootable for a virtual machine in an .iso format
@@thekeyboardwarrior1018 Are you writing the asm? I assume X86?
What is the project for?
There is most definitely documentation online but I would suggest opening an iso file and looking at its contents to start.
You will see much more then a single executable. If you are only using a single executable in 16bit mode i believe you just need to find what file the VM loads and replace it.
Though i have not done this and have to assume a few things so i may be wrong.
@@dynfoxx I am the one writing the ASM
The project is for testing and security purposes, it also can convert APK/exe into a code the ASM can read and run
@@thekeyboardwarrior1018 Hmm, do you have code up?
This is not my area of expertise but i can take a look if you have it posted somewhere.
Are you just starting the project or do you have stuff ready?
If zig doesn't do it then nothing else will
“This language sucks so I’m gonna write a modern language and it’s main focus is so you can use it to use the shitty language”…. This is the dumbest idea I’ve ever heard google has already written two languages if they don’t like c++ then why not stop using c++ and use one of those languages.
Well I dare you to even try to refactor Chrome which is entirely written in C++. Modern web browsers are even more complicated than some modern operating systems(thanks Google and W3C for making web standards too complex for their own good). Google focuses on interoperability so that they can refactor chrome step by step and still release updates without getting stuck on rewritting it all. But given how google treats it's projects I'll not be too surprised if I see carbon in 5 years on that Google Graveyard site
they cant stop using C++, because nothing new they'll ever write will add anything substantial that C++ doesnt already have. There simply is no way to be better than C and C++ because they are as simple as it can get, and give you as much freedom as you can get. Its literally the perfect balance between low level and high level for human readability, and somehow people refuse to understand this. Not only that, but you cant just go and expect to rewrite all of the code from years and years worth of coding in just a few days with your new shiny language. Go ahead, i dare ya, rewrite all of google's code with carbon or some shit lmao. Its already pretty fucking broken as it is...