It’s obvious who carbon is for - it’s for people like me. I program in c++ because the libraries I’m using are in c++. I had to learn c++ this year, and while I already know dozens of languages, including C, learning to write C++ safely has been a huge time sink. To program well in C++ , learning smart pointers and move semantics and rvalues , the weird template language, memorize all the gsl conventions, pick a style guide (like google’s), constantly fight circular references with forward declarations and virtual destructors, decide if I use exceptions ? C++20? Man, now I’m pretty good at the language and even kind of like it! But I WISH I could have skipped this process and just used a better language ! And still use c++ libraries transparently. I wish I could use carbon!
Now I get the struggle more with this explanation, but only if they used normal C style var/func declaration that already was perfect instead of unnecessary : and -> and wrong names like Array, why not name it List as everyone knows it? Static arrays are useful sometimes too, it's not meant to be Python, it's meant to replace C++. Not a good start at all in my opinion. I like the idea but I wish other people that could name things and design syntax better worked on it.
@@sara_m I don't like the wrong names, but I think the declaration syntax is mostly good. Thankfully, the language is not even close to set-in-stone right now. I'm not certain that var/func is necessary. It feels like making the programmer hold the parser's hand and I would presume that the colon syntax avoids things like the most vexing parse already. I was convinced when C++ added the arrow syntax for return types that it should be done that way in a successor language.
@@grimfang4 well, idk.. but generally I don't like the way Google designs stuff, let's hope they'll make better choices in the future. Also initialization doesn't have to support type var(something), like C# and other C-like languages. Edit: btw the -> in C++ is optional and doesn't require a lot of extra typing, I just think the fn and -> for every function is another inconvenience added rather than improvement, so is extra typing for variable decl. Just makes it harder. Like how typing public/private is an absolute pain in other languages compared to C++ public:/private:. Like $ is the sole reason I hate PHP because of how much pain it is to type each variable (an extreme case). The : makes some sense in python for example, it's optional and there's no mandatory 'var' so not much unnecessary typing on keyboard.
@@sara_m well, us two are in very different camps here I rather type more than less (if the stuff I type gives additional information) one example of this is that I dislike type inference, it makes the code harder to read imo and languages which let you initialize new variables via just assignment without a special keyword (like var or something else) are a pita to deal with because they just create so many completely unnecessary problems long term
What Google seems to be saying is that if you have the ability to do a clean rewrite in Rust, then you do that. The problem is that many companies have large legacy C++ codebases and it's not always seamless to mix Rust and C++ code in a slow incremental manner. Calling Rust from C++ seems to be fine, but the issue seems to be calling C++ from Rust, which suddenly forces the C++ code to be rewritten to obey the much stricter rules of the Rust borrow checker, else it forces Rust to make all its C++ calls from inside an unsafe block, which negates the main advantages of Rust memory safety. So Carbon seems to have been designed as a language that can directly transpile to C++. Sort of like how Typescript and Javascript are related, for legacy codebases wanting incremental migration.
If you like the safety benefits of Rust, you should prefer to compromise them for C++ interop rather than throwing them away entirely for another language.
@@PremierSullivan The problem here is that they HAVE TO have C++ interoperability and Rust does not allow it. It is not a matter of choice for people at Google or any other team that work with legacy code. That is whom they are telling to go for Rust to; people that had this chance to have a choice (i.e. people that are just starting a new project from scratch).
I think ffi is nice in theory, but Google has a lot of c++ and it is not written c-style. So when it comes to incrementally changing to another language like rust, you have a big problem. Writing rust code that regularly interacts with non c-style c++ leads to bad rust code. So unless you rewrite in large chunks with clean interfaces, migrating is not reasonable. I think some language probably could do this better, maybe Odin. But also, could Google realistically contribute to Odin and change it to match their needs. Most likely, you would not want the Google team to suddenly swoop in and want significant sway over your language. As an aside, if they would be doing significant work bootstrapping a language like Odin to their needs, why not just make their own even more targeted language, it isn't that much more work (when thinking in Google scale and timelines). My hopes for carbon compared to c++ are: - correct defaults - less ways to do things - reasonable safety without the hassles that rust gives you - amazing interop with c++ so it can be used in more places seamlessly - more cohesive tooling - better syntax - faster build times Of course the language is super new and just an experiment right now, but a lot of these pieces should be achievable. Then it creates a way to incrementally improve from c++. But for just about everyone who isn't just interested in carbon for the hell of it, the language is not meant to be useful. It is truly just targeted at large corporation who feel stuck with c++. I am hoping it does well enough that I can use it whenever I would have used c++ for something.
This big corporations messed C++ in the first place wanting unendig stream of new futures. That's why C++ is one big mess. Do you think they can fix it? I can bet everything I have on this: If Carbon will be stable enough and get adopted on a bigger scale, developers will start requesting new futures and in 5 to 15 years it will become the same or even bigger mess than C++. At some point you have to say: this is the language and there will be no more new futures, just like GingerBill did with Odin and Andrew Kelly is planning with Zig. Otherwise you end up with total mess. People are suprised why anyone uses C this day, this language is 50 years old. People use it for few resons: 1) Programs written in C can run on every electronical device under the sun 2) It has so many 3rd party and stable libraries for almost anything you can imagine 3) You don't need doctorate to write programs in C You can learn all futures of C, Zig or Odin in less than 2 weeks. You can't do that in 2 years with C++.
@@wiktorwektor123 Amazing discussion ! Recently I was messing with Raku Language, after many many years of knowing the Perl family, I've deiced to give Raku a try. Whenever trying a new language I ask a fundamental question: What unique, idiosyncratic characteristic does this language brings to the table ? What 'X' does best that maybe only 'X' can do well ? Raku has facilities for creating DSL (Domain Specific Languages), and I've watched a video from Uncle Bob, where he discusses about decades of experience with dozens of languages and he speaks about those DSL as always having a niche even further into the future. So, I think that programming languages would be more 'future proof' if they had meta-language system to design DSL very easily inside them. Old LISP hackers would maybe say that LISP had this in the 60's but this level of metaprogramming in LISP has a learning curve that is really steep. I think that the trick is how to put DSL creating tooling inside a language without it acquiring what I call "the curse of the feature rich languages" C++ and Raku are really feature rich languages, the curse lies in the fact that languages that has "everything plus the kitchen sink" inside them, are really hard to completely 'grok' in full, and they give you so much freedom that everybody turn out following completely different patterns and one language becomes many with possible incompatible libraries.
Great video!!! Warning this is maybe off-topic.I really like what I have seen of Odin, although Im a fan of C++, and love OOP(not fanatic, but pragmatic OOP) I have to admit that Odin is a fine piece of work from what I've seen. The syntax is clean, easy to read and has the most import tools afaik. What I love about OOP is the ability to raise the level of abstraction, humans are natural classifiers so OOP is in my perspective is a lot about code organization as well as the other benefits. The more procedural data-oriented way is also a very good paradigm for different reasons. The disadvantage to bundling data with code is that you lock you functions into a specific type. This means potentially loss of modularity and ability to make generic reusable code. Sometimes you just need to do transformation on data. All paradigms, languages and tools in general are compromises, so it's just about finding the right tool for the job(cliche I know). Sorry for the off-topic, just been watching a few videos here on Odin and wanting to comment. Once again kudos to gingerBill Odin looks very promising, I think it has a bright future.
there's a crowd of people that work in C++ that, since the blizzard of releases and features from C++11 onward, just want something like a compile option --prohibit-legacy-cruft and --use-sane-defaults (C++ has a myriad of keywords that must be sprinkled profusely in the code as noise where should have just been the default case) Something like Carbon is probably for that crowd, or is at least intended for them. They need to co-exist with C++ and ball and chain legacy code bases
It's a big language in that it offers a lot of libraries (batteries included). It is a very small language in terms of feature set compare to so many modern languages. 😄
Look at this from the perspective of Kotlin vs Java and suddenly Carbon vs C++ makes sense. This is for devs and big orgs who want the power, wisdom, and safety of established C++ libraries with nicer syntax and ecosystem of a modern lang. You talk about performance, but the main draw of Dart and Go is not performance as much as it is readability. It costs a ton to develop in C++. Carbon not there yet, but we can realistically expect that Google will keep pushing.
sean baxter creator of the circle programming language fully implemented a c++ fronted by himself built on top of llvm. also adds a lot of extensions and proposals from the c++ commitee not part of c++ today
It seem one of the main reasons for creating Carbon is for companies with large code bases and parallel compiling: "Fast and scalable builds that work with your existing C++ build systems"
Yeaaaah. Unsure if anyone will read this, but Ill slap down some comments. So, Im a bit of a weirdo. Come from games (25 years): gameplay, graphics, networking, tools. Ive seen C+ (blessed subsets of C++) work really well for fast dev of fast programs. I like duck typing, and partial template specialization and all those sorts of things I also love languages, the weirder the better. Smalltalk, Clojure, Scheme, Scala, Idris, Erlang , etc are all awesome and have great things to share. The rise of the Better C compilers is really neat too. Could talk for hours on those, but for right now, I love seeing folks experimenting in that space. So, all that to say, I have NO idea who Carbon would be for, or why it is how it is. My approach to the same language (A globally usable C+) would be pretty radically different I think. Then again, games, and in particular gameplay, has pretty radically different needs than most folks, and nothing EXCEPT The Tomorrow Corporation folks, are really solving our needs.
I can tell you who is it for: It is for me :) It took me nearly 20 years to understand C++ and I'm pretty sure after years of debugging and customer support that I would not like to use it anymore for new projects. Especially because there are so many traps where new devs just run into too easily. Odin an Nim are unfortunately not widely used - which reduces the amount of usable existing code to use and increases the likelyhood to discover new traps :/ Carbon on the other hand is a good candidate to be used widely in some years. Sometimes it is not the best thing to use the best existing language but just to choose one that solves your problem and might keep solving it a few years later.
@@dmitriidemenev5258 I didn't want to complain about Rust. Rust is OK. It's main purpose is guaranteeing memory security. It is great to have that, but it is a bit annoying for everything else. It isn't easy to write and it is also hard to have a FFI for C/C++ or python. I was a bit shocked when trying to perform simple string concat or file path operations with Rust. This was even more complicate than in C++. And the memory concept forces you to perform strange operations. I'm not saying that Rust is bad - I could live with Rust. Rust is just far away from being fun and Carbon looks more like something I am looking for.
I think It is a language for people like me, I use C++ in my day to day but work in both huge codebases and embedded systems, wrapping a library is really a pain, and maybe later you are going to switch, and incur the wrapping cost again, the idea is to file by file remove C++ from our codebases, to a richer set of features without a lot of baggage we get from C++, sure not all of it but a lot, the smaller amount the better.
Carbon designers say “use rust if you can”; carbon is for people who need to extend their existing c++ source bases. Rust adoption has been held back by lack of C++ interop IMO (swift gets further in Apple land because it can use all their frameworks and be mixed)
please make a video on your implementation on defer in c++ it was magic when i first saw it, it would be really cool to have some more insight on different ways of resource management (mutex,db etc) and defer, and your thoughts on it, and how you came to implement this weird thing.
@@GingerGames yes i meant kind of a follow up video on this topic i loved that article and the actual code for that implementation was very scary, i am always curious how do people get to this level, still great stuff.
This seems to be a language for people who are "stuck" with C++ but don't want to use C++. Similarly to how people who deal with web stuff are stuck with Javascript, but Javascript is garbage, and so Typescript was created, not as a full on replacement, but as something that's semantically similar but incrementally better.
No video YET, but a good example of how powerful it is is that you can use all of the amazing vendor packages that Odin offers (SDL, GLFW, Metal, PortMidi, MiniAudio, OpenGL, STB family, etc) and the entire build system is as simple as `odin build .`
It seems to do what classes did for JS. Even though JS classes are not "real" classes in that they are syntactic sugar for prototypes, they have made the language easier to use and teach and is now the dominate way to use the language. I think the same could be said of Carbon and C++. At some point, people at Google will only need to learn C++ if they want to dive into a system, otherwise, "just use carbon."
@@GingerGames it can be used from C++ as well, as long as you put the code in a function and use C++ types. You have to call NimMain() from the C++ main() too.
I would use it if they didn't go with the bike shedding fad of `noun adjective` instead of the more reasonable `adjective noun` declaration syntax that doesn't need messing with.
Myself, I would like to learn how to make a language and build upon it, but it seems like its still some sort of trade secret people dont want to share.
0:16, you should really make a small video about Odin. 5-10 minutes just showing its features, 20-30 explaining them a little bit. It's hard to face a playlist of 3 hours videos each, just to take a glance over it. Your language won't ever get popular this way. I'll have the guts to get along with at least 1 of your videos, only because I'm curious about how something could be better than C++ (I lack imagination for that). 3:07, it seems they are too much worried about C++ type deduction. _"Even using (C++20) _*_concepts_*_ you still won't have _*_generics_*_ " (template from Java/C#)_ - Carruth, C++ committee member, working on Carbon. Personally I don't have issues about this, and love C++ fast/concise typing. Changing its features just because "people are not able to manage them properly", unfairly blaming the language, is the same wrong vision that made Java a so bad and ugly language. 8:00, I think it's nice to experiment, and C++ libraries don't interfere in the language, as it has been seen in higher level ones. 11:04, it's too early to be worried about it. It's just in an experimental phase. The language is way easier than C++ for being read by a compiler - _of course, it asks for the programmer's help, by messing the type deduction_ . 14:21, whaaat?! I think C++ is following the leading path. It has plenty of undefined behaviour opportunities, but that is for good reasons. Other than that, some traps. But it's the price for conciliate low and high levels, with all flexibility the language has. 17:25, I can't give thumbs up for this, because I don't agree with your opinion about C++, and because you failed to notice that Carbon already is destined to has its followers: people who are desperate about C++ type deduction. PS: try to improve your diction. You smash words too much.
You cannot introduce any substantial language in 5-10 minutes. I have a 45 minute introduction video on Odin (on this channel), as well as a written overview on the official Odin website.
Kindly, you asked several times who Carbon is for. It is stated by the Carbon team rather clearly: programmers who want a better C++ BUT who have a large C++ codebase that they cannot readily abandon. I would think that to be the majority of C++ programmers. Precious few people are in position to make the clean break that Rust would require.
When this video was made, there was not much information on this topic as there is. And there are many languages out there that do allow for importing C++, such as D or Nim, meaning projects can still use the existing code base. The bidirectionality requirement is very much a Google issue and not necessarily a normal one that even large companies.
@@GingerGames I understand. Yet, the interoperability in the case of Kotlin-Java has been an absolute boon for Android and Cloud developers, would you not say?
@@hassandavis the foundations of C and C++ are bad to begin with, and not necessarily comparable with the things based off the JVM. And the things C++ are used for can be very different domains to Java. I wish the Carbon team well and hope for the best for the language.
@@GingerGames I think you miss my point here :-) Of course, C++ has nothing to do with the JVM. I mentioned Kotlin as an example of a language that supersedes another by providing ample interop. For may teams, maybe even most teams, being able to move to a language in a piecemeal and seamless fashion is crucial. It appears that is one of the primary aims of Carbon. And that would make Carbon inherently useful for the common C++ usage scenario.
At around 8:35 you mentioned it being possible to make a reasonable C compiler yourself. I was wondering if there were resources you could recommend on how someone would get started in this space? As a hardware engineer I've never been particularly enthused about using C or subsets of C++ for embedded, but that's the only tooling we get support for. Always thought if someone could just make a better version of C and have vendors adopt it it'd be fantastic. Great thing about modern micros is that if there's support for 32 bit ARM architectures you could technically use any language. Even Rust open source community has made an effort porting over STM32 libraries, but the memory safety in Rust makes register manipulation a bit awkward.
If you want a resource to write a C like compiler yourself you should check out the videos of PerVognsen (Bitwise) here on UA-cam, especially the ones about the Ion compiler
Here's a good idea, C++ is getting ever larger and larger, more bloated and more complex, seemingly by the day...I know lets take some of that Rust syntax and make a blend of Rust and C++, but it's C++ enough for backward compatibility. I don't think that's going to confuse anyone that codes in C++ at all hmm...Or maybe you could start from scratch based on modern language design/requirements on modern hardware. Let legacy software be written in C++ as even COBOL is used today for some systems (because it would be a massive headache to re-write and debug).
@@GingerGames I see. I think I have a limited understanding of the different arch terms. The Arm Cortex-M series are the ones I am referring to. For example, STM32F446RE has a Cortex-M4. I do not expect there to be all the libraries, but I should be able to link with the existing ones since they are all written in C, so long as Odin has support for these processors. Which is probably a big ask. Thanks for the videos and I will checkout Odin!
@@luz_reyes_676 I apologize for the minor confusion. Odin is targeting high performance modern systems, so even if some embedded system _might_ work, it is not its target platform domain. We will be supporting 32-bit and 64-bit platforms only (which I know most ARM chips do support (if you ignore the Thumb stuff)).
Tried carbon, took me 1hour to get it running on windows (so much stuff to install) And then runned the hello world, litterally 198s (~3mins) for it to compile and run... (i5 10th gen, 8go ram) This isn't practical at all, I don't even imaging compiling and running big programs with it.
Btw, can Odin work with MinGW's linkers or LLVM's lld linker on Windows? On the site it is told that I need to install Visual Studio build tools to try out Odin.
I really wanted to say "It is for me" but some of the details you pointed out really turned me off. Like even worse compile times than C++, separate definition and declaration, needing to explicit in the wrong places (don't get me wrong, I prefer do be explicit with something that can shoot me in the foot and C++ has much of that implicitly). I do very much like the interop in both directions, that would allow for a gradual transition to something more sane than C++. Maybe they can improve the build times (crucial), but I am not so hopeful for some of the verbose design (The "returned val" with the extra "return" killed me).
Performance. Part of that is speed but there is more to performance. If you want speed you can dive off a cliff or mounting going really fast that way. But if you want performance you need more then just relying on gravity to carry you up to when gravity and wind resistance equalize, that is if you dived off a high enough place and reach that limit of speed. And do all this safely since that was the point right? To outpace the air resistance you need allot more then gravity to get over the GRAVITY'S pull downwards to earth equalization. Obviously. But whatever good is speed going to be if getting to a high place is such a struggle and not encountered for or being focused on being a priority when built? Having no real way up the hill but it is built that way for safety. Having fancy brakes to stop you from going backwards but also not helping going up the hill. Snags sometimes trying to push upwards! But it is realistic to not overdo it and we can work on air resistance and get speed that way! Heck we might not need such a huge hill working on air resistance! This is Rust. Maybe we should make the thing heavier and so in that way we can faster fall! Or maybe just maybe we can make sure the speed censor is 100% safe! We want it not to be unsafe! What you mean it is written in C? NO NO UNSAFE RUST. While Rust is being pushed up a hill for ages or really being carried up by some insane strong people, others are on flat ground and are just getting the same speed without having to first work out how to get up the hill by braking there back. Or maybe they work just as hard for no good reason and still not doing much better then the based RUST users that carry the language up that hill to GET BASED FAST. *splat. Others go sideways and maybe still reaches the speed without needing to be worried about the air to ground fast approaching after getting up the dam hill and diving off. O what whas thaa *SPLAT. Forgets what just happened and starts all over agen to solve this problem of speed but "safely". Ignoring the blood on the ground. Or how making something complicated heavy or less of a drag to get speed and safely is really hard if you do it badly. Or even if done well the hill is still there. And no way we can have a engine do the work they are unsafe! It is bad to pollute! Popularity and fads rule! But sure C++ and the like might hit a pothole or a wall. And some might struggle to win over air resistance or even come close to that point. Or when it is sold to costumer the wheels falls off since you forgot to fix the nuts and bugs. They where not there when you sold it! Maybe time passing started to wear it into a unsafe state? Might need to be maintained? Maybe shit happens but do not require to make sure EVERYTHING IS SAFE and still not being safe to work with. Or in reality rely on a nurse to fix the brain bleeding. :c Some might even have a hard time getting into motion or like C++ have no dam brakes and need a to trash the gearbox and clutch in hopes of going anywhere. Unsafe and it cost something for that speed. But hey sometimes air resistance can be not given a dam about and just go slow but perform well in outer ways. Like not pushing up a hill or wasting energy trying to reach fast speeds. Just be slow and you can change stuff on the go and you do not need to stop and it keeps just going. You can jump off and walk besides it and still catch up to it going along even. Can jump off without braking your bones if it is going to hit a wall etc etc. Still not safe but I mean the speed is instead focused on other things to make it workable. But the hill push and ground fast approaching sounds no fun to be around. Rather try the gearbox grind or just that slow thing that eats Pythons it can catch up to. Or what about building something that can fly and also go sideways up and down? Like a plane to the heavens? Not maybe safe but what the hell it is safest way to travel by statistics. Maybe a helicopter dropping towards earth might be a compromise to get that Rust safety and performant? Going up into the air and then cutting the engines to reach speeds? Common Rust you can do it! DO IT! Performance going up being a focus! And the execution being really fast as the speeds are so dam fast that it solves the problem first time around! Execution complete! Safely. C++ refuses to change and keep the rotten brakes falling apart since they do not stick or slow the speed down as they are now. So you are forced into taking it slower just to avoid danger. Or trying to cope with the gearbox grinding you have to sacrifice speed even if you do not want or really see it happen upfront. Imagen trying to fix the brakes and they stick! No no no! Or some people do not realize where they are anymore so we need to have 6 sets of brakes to make sure everyone are ok? Or worse the 100 different emergency "fixes" brakes fixing something not related to the brakes or even C++, they just stops working or SOMETHING stops working!!! AAAaa! Sounds like Java. And Java is. well. More of the same.
no, it isn't. Typescript has a whole ecosystem around it since nearly the beginning and it adds some bells on whistles on top of JS. Kotlin changed syntax heavily and its toolset is different than java, even if it can import java libs. the compiler is different and JetBrains is investing a lot into making it deliver the promise of Java ("code once, run everywhere") Carbon doesn't seem to add anything to c and c++ nor flip the book on its head (like rust).
@@dukemagus Right. Maybe it is "simplicity" take like Go. Then google can hire and learn enginiers faster to write "ala c++" firmly standing on existing c++ libs?
as someone with first-hand experience in AAA game engine dev I would definitely NOT be excited to add some random new Google language to our build system and having to slowly migrate stuff by somehow working with these two languages side-by-side. If you don't work towards rewriting literally everything you'll always be stuck with 2 languages and if you do manage to rewrite everything - a couple million lines of c++ code over 20+ VS projects, god have mercy - you're stuck with this new language that barely improves anything as its just as unsafe, slow to compile etc. I bet some companies won't even consider a new language like Carbon because it would make job/hiring requirements more difficult as well
How hard is it to create a new programming language? Why not just fix the ones we already have? Is that too hard? I don't know anything about creating a programming language. Just asking.
The really big problem with fixing a language is not the technical part. It’s the fact that a change can’t break existing code. Imagine code for a life support system for example and c++ would change what ”new” is doing? To make sure that the chage didn’t break the code, you’d have to go through the whole codebase and make sure that it still works as expected and there are no subtle bugs. Now imagine all the of lines of c++ that exist in the world, many of them which just cannot fail. That’s the hard part. Adding new things to a language is much easier, because that won’t break old code. But the new feature has to be so good that it won’t have to be changed in the future, because that is hard (see above). :)
Interesting I did not know Odin. But anyway we are using D which already solves much of a problem that carbon works on soving. But anyway google makes a new langueus every second week
8:20 Sean Baxter implemented his own C++ front-end for Circle lang. I think, what's really hard to implement is the back-end. If I not mistaken, Odin also still uses LLVM back-end.
It's not unidirectionality that is the issue, it's bidirectionality that is. This means that the type system of your language must be 100% compatible with C++ both ways. I was quite clear in what I said.
You got to ask what happens if Google succeeds in this effort, too! Then wouldn't there exists a new potentially Google IP that dominates the programming space? Also tooling for c/c++ Is definitely in a ripe space for squatting ATM.
He misspoke, because he just contradicted himself before getting 35 seconds into the narration. "It's a big language now. . . . It's a very small language." He should fix the audio or annotate his video with a correction, because I doubt he meant his words to come out that way if he had thought carefully before speaking.
Well, think again. A language can be big in X and small in Y e.g PHP is a big language and also a small language. Big in the sense that it has a large community and powers more than half of the web. Small, unlike python or Javascript, it can only be use on a web server. He may have said that intentionally.
Who is Carbon even for? Well, it sounds like it is for me... I am Qt application developer and I wish I could abandon C++ and use some more modern language. Just natively, without any hassle with bindings.. :)
@@error-42 If you tried to compress a video with a modern codec (vp9 etc) at high compression ratio which is what youtube seems to be doing, you'd be surprised by how fast youtube compresses videos... It's more painful than waiting for a big C++ project to compile
Yeah, seems like an in-house solution to an in-house problem, seemingly not even that useful in Google's case. The name is also pretty forgettable, maybe naming your language after something that has a whole subdiscipline of chemistry to it is not that good of an idea
Deliberately or not, when you fail to disclose that it's the company you work for that's uses Odin professionally it looks like you're trying to pull a fast one
gingerBill's biggest by far claim to fame is that he is the creator of the Odin programming language and a glance at the channel will tell you that. It's primarily what he's known for among developers, it's not dishonest to assume a viewer would know or would figure it out quickly
@@tuatarian6591 I don't believe you've read my comment. My point is that in this video, where he talks about a company using Odin for a product, the company he mentions is the company he is the senior programmer for
After learning rust, this seems primitive. You are trying to pull back the entire community into the past (One generation back). Rust actually is not just about memory safety, but it's an evolution on many fronts.
The C11 standard specification is ~650 pages. The C++14 standard specification is ~1250 pages *BUT* ~600 of those pages are about the standard library. So the standard specification for the core language itself is virtually the same size as C11's. And the C++20 standard contains ~1100 pages for the various standard library modules and ~600 pages for the core language.
Complexity can't really be measured with page counts, right? Are those concise or sparse specs? It doesn't even matter though. The point is that C++ is huuugely more complex than C. I think we can all agree with that...
@Eleanor Bartle Yeah, it does. It's also worth keeping in mind that C++ inherits pretty much all of the C standard library (, , , , , , etc etc). It's definitely a more complex core language (and has a much more feature-rich standard library), so the standard specification is definitely far from lean; but I think that all things considered, it's surprisingly terse.
And you're wrong. Who is a subject pronoun. Whom is an object pronoun. The trick to know when to use "who" or "whom" is whether you can replace the "whom" with a "him". "Him is it for?" does make sense, therefore it is "Who".
Dude...it serves the same purpose for C++ developers as Kotlin does for Java...this isn't hard...and it isn't even a formal syntaxes nor has its own compiler yet.
"Making things so hard for everyone, including yourself"
This rings so true for modern economies and things made by big corporations.
It’s obvious who carbon is for - it’s for people like me. I program in c++ because the libraries I’m using are in c++. I had to learn c++ this year, and while I already know dozens of languages, including C, learning to write C++ safely has been a huge time sink. To program well in C++ , learning smart pointers and move semantics and rvalues , the weird template language, memorize all the gsl conventions, pick a style guide (like google’s), constantly fight circular references with forward declarations and virtual destructors, decide if I use exceptions ? C++20? Man, now I’m pretty good at the language and even kind of like it! But I WISH I could have skipped this process and just used a better language ! And still use c++ libraries transparently. I wish I could use carbon!
Now I get the struggle more with this explanation, but only if they used normal C style var/func declaration that already was perfect instead of unnecessary : and -> and wrong names like Array, why not name it List as everyone knows it? Static arrays are useful sometimes too, it's not meant to be Python, it's meant to replace C++. Not a good start at all in my opinion.
I like the idea but I wish other people that could name things and design syntax better worked on it.
@@sara_m I don't like the wrong names, but I think the declaration syntax is mostly good. Thankfully, the language is not even close to set-in-stone right now. I'm not certain that var/func is necessary. It feels like making the programmer hold the parser's hand and I would presume that the colon syntax avoids things like the most vexing parse already. I was convinced when C++ added the arrow syntax for return types that it should be done that way in a successor language.
@@grimfang4 well, idk.. but generally I don't like the way Google designs stuff, let's hope they'll make better choices in the future. Also initialization doesn't have to support type var(something), like C# and other C-like languages.
Edit: btw the -> in C++ is optional and doesn't require a lot of extra typing, I just think the fn and -> for every function is another inconvenience added rather than improvement, so is extra typing for variable decl. Just makes it harder. Like how typing public/private is an absolute pain in other languages compared to C++ public:/private:.
Like $ is the sole reason I hate PHP because of how much pain it is to type each variable (an extreme case).
The : makes some sense in python for example, it's optional and there's no mandatory 'var' so not much unnecessary typing on keyboard.
@@sara_m well, us two are in very different camps here
I rather type more than less (if the stuff I type gives additional information)
one example of this is that I dislike type inference, it makes the code harder to read imo
and languages which let you initialize new variables via just assignment without a special keyword (like var or something else) are a pita to deal with because they just create so many completely unnecessary problems long term
Employers: "Needs 5+ experience in carbon" lol
How do you get experience points in carbon?
Actually, it's 15+ years of experience for a language that existed only 12 hours ago 🤡
Technically we’ve been exposed to Carbon since birth sooooo I mean I think we’re good 🤣
"Needs 5+ experience in carbon" could be hacked by "look at my project in Carbon!".
Thank me later ;-)
What Google seems to be saying is that if you have the ability to do a clean rewrite in Rust, then you do that. The problem is that many companies have large legacy C++ codebases and it's not always seamless to mix Rust and C++ code in a slow incremental manner.
Calling Rust from C++ seems to be fine, but the issue seems to be calling C++ from Rust, which suddenly forces the C++ code to be rewritten to obey the much stricter rules of the Rust borrow checker, else it forces Rust to make all its C++ calls from inside an unsafe block, which negates the main advantages of Rust memory safety.
So Carbon seems to have been designed as a language that can directly transpile to C++. Sort of like how Typescript and Javascript are related, for legacy codebases wanting incremental migration.
If you like the safety benefits of Rust, you should prefer to compromise them for C++ interop rather than throwing them away entirely for another language.
@@PremierSullivan The problem here is that they HAVE TO have C++ interoperability and Rust does not allow it. It is not a matter of choice for people at Google or any other team that work with legacy code. That is whom they are telling to go for Rust to; people that had this chance to have a choice (i.e. people that are just starting a new project from scratch).
I think ffi is nice in theory, but Google has a lot of c++ and it is not written c-style. So when it comes to incrementally changing to another language like rust, you have a big problem. Writing rust code that regularly interacts with non c-style c++ leads to bad rust code. So unless you rewrite in large chunks with clean interfaces, migrating is not reasonable.
I think some language probably could do this better, maybe Odin. But also, could Google realistically contribute to Odin and change it to match their needs. Most likely, you would not want the Google team to suddenly swoop in and want significant sway over your language. As an aside, if they would be doing significant work bootstrapping a language like Odin to their needs, why not just make their own even more targeted language, it isn't that much more work (when thinking in Google scale and timelines).
My hopes for carbon compared to c++ are:
- correct defaults
- less ways to do things
- reasonable safety without the hassles that rust gives you
- amazing interop with c++ so it can be used in more places seamlessly
- more cohesive tooling
- better syntax
- faster build times
Of course the language is super new and just an experiment right now, but a lot of these pieces should be achievable. Then it creates a way to incrementally improve from c++. But for just about everyone who isn't just interested in carbon for the hell of it, the language is not meant to be useful. It is truly just targeted at large corporation who feel stuck with c++. I am hoping it does well enough that I can use it whenever I would have used c++ for something.
This big corporations messed C++ in the first place wanting unendig stream of new futures. That's why C++ is one big mess. Do you think they can fix it? I can bet everything I have on this:
If Carbon will be stable enough and get adopted on a bigger scale, developers will start requesting new futures and in 5 to 15 years it will become the same or even bigger mess than C++.
At some point you have to say: this is the language and there will be no more new futures, just like GingerBill did with Odin and Andrew Kelly is planning with Zig. Otherwise you end up with total mess.
People are suprised why anyone uses C this day, this language is 50 years old. People use it for few resons:
1) Programs written in C can run on every electronical device under the sun
2) It has so many 3rd party and stable libraries for almost anything you can imagine
3) You don't need doctorate to write programs in C
You can learn all futures of C, Zig or Odin in less than 2 weeks. You can't do that in 2 years with C++.
@@wiktorwektor123 Amazing discussion ! Recently I was messing with Raku Language, after many many years of knowing the Perl family, I've deiced to give Raku a try.
Whenever trying a new language I ask a fundamental question: What unique, idiosyncratic characteristic does this language brings to the table ? What 'X' does best that maybe only 'X' can do well ?
Raku has facilities for creating DSL (Domain Specific Languages), and I've watched a video from Uncle Bob, where he discusses about decades of experience with dozens of languages and he speaks about those DSL as always having a niche even further into the future.
So, I think that programming languages would be more 'future proof' if they had meta-language system to design DSL very easily inside them.
Old LISP hackers would maybe say that LISP had this in the 60's but this level of metaprogramming in LISP has a learning curve that is really steep. I think that the trick is how to put DSL creating tooling inside a language without it acquiring what I call "the curse of the feature rich languages" C++ and Raku are really feature rich languages, the curse lies in the fact that languages that has "everything plus the kitchen sink" inside them, are really hard to completely 'grok' in full, and they give you so much freedom that everybody turn out following completely different patterns and one language becomes many with possible incompatible libraries.
Great video!!! Warning this is maybe off-topic.I really like what I have seen of Odin, although Im a fan of C++, and love OOP(not fanatic, but pragmatic OOP) I have to admit that Odin is a fine piece of work from what I've seen. The syntax is clean, easy to read and has the most import tools afaik. What I love about OOP is the ability to raise the level of abstraction, humans are natural classifiers so OOP is in my perspective is a lot about code organization as well as the other benefits. The more procedural data-oriented way is also a very good paradigm for different reasons. The disadvantage to bundling data with code is that you lock you functions into a specific type. This means potentially loss of modularity and ability to make generic reusable code. Sometimes you just need to do transformation on data. All paradigms, languages and tools in general are compromises, so it's just about finding the right tool for the job(cliche I know). Sorry for the off-topic, just been watching a few videos here on Odin and wanting to comment. Once again kudos to gingerBill Odin looks very promising, I think it has a bright future.
If methods are mostly about code organisation, you'll love Odin's package system and many of its other features.
@@GingerGames It does have a package manager? Like pip cargo ect ?
As someone looking into adopting rust for business purposes I look forward to your (hopefully) future video about what its faults are! :)
there's a crowd of people that work in C++ that, since the blizzard of releases and features from C++11 onward, just want something like a compile option --prohibit-legacy-cruft and --use-sane-defaults (C++ has a myriad of keywords that must be sprinkled profusely in the code as noise where should have just been the default case)
Something like Carbon is probably for that crowd, or is at least intended for them. They need to co-exist with C++ and ball and chain legacy code bases
0:28 "It's a big language, and it's a very small language" :D made me laugh
It's a big language in that it offers a lot of libraries (batteries included). It is a very small language in terms of feature set compare to so many modern languages. 😄
Look at this from the perspective of Kotlin vs Java and suddenly Carbon vs C++ makes sense. This is for devs and big orgs who want the power, wisdom, and safety of established C++ libraries with nicer syntax and ecosystem of a modern lang. You talk about performance, but the main draw of Dart and Go is not performance as much as it is readability. It costs a ton to develop in C++. Carbon not there yet, but we can realistically expect that Google will keep pushing.
sean baxter creator of the circle programming language fully implemented a c++ fronted by himself built on top of llvm. also adds a lot of extensions and proposals from the c++ commitee not part of c++ today
He didn't use llvm. Thought it had too much technical debt, too hard to modify, etc. Wrote it from scratch.
@@ladnir quite sure llvm is used clang Is not used
@@kevindelnoye9641 I see, for the backend codegen...
It seem one of the main reasons for creating Carbon is for companies with large code bases and parallel compiling: "Fast and scalable builds that work with your existing C++ build systems"
Yeaaaah. Unsure if anyone will read this, but Ill slap down some comments.
So, Im a bit of a weirdo. Come from games (25 years): gameplay, graphics, networking, tools. Ive seen C+ (blessed subsets of C++) work really well for fast dev of fast programs. I like duck typing, and partial template specialization and all those sorts of things
I also love languages, the weirder the better. Smalltalk, Clojure, Scheme, Scala, Idris, Erlang , etc are all awesome and have great things to share.
The rise of the Better C compilers is really neat too. Could talk for hours on those, but for right now, I love seeing folks experimenting in that space.
So, all that to say, I have NO idea who Carbon would be for, or why it is how it is. My approach to the same language (A globally usable C+) would be pretty radically different I think.
Then again, games, and in particular gameplay, has pretty radically different needs than most folks, and nothing EXCEPT The Tomorrow Corporation folks, are really solving our needs.
Carbon isn't exciting yet, but I'm happy better C and C++ Interop languages are rising up, not unlike Odin.
I can tell you who is it for: It is for me :)
It took me nearly 20 years to understand C++ and I'm pretty sure after years of debugging and customer support that I would not like to use it anymore for new projects. Especially because there are so many traps where new devs just run into too easily.
Odin an Nim are unfortunately not widely used - which reduces the amount of usable existing code to use and increases the likelyhood to discover new traps :/
Carbon on the other hand is a good candidate to be used widely in some years.
Sometimes it is not the best thing to use the best existing language but just to choose one that solves your problem and might keep solving it a few years later.
What about Rust?
@@dmitriidemenev5258
I didn't want to complain about Rust. Rust is OK. It's main purpose is guaranteeing memory security. It is great to have that, but it is a bit annoying for everything else. It isn't easy to write and it is also hard to have a FFI for C/C++ or python. I was a bit shocked when trying to perform simple string concat or file path operations with Rust. This was even more complicate than in C++. And the memory concept forces you to perform strange operations. I'm not saying that Rust is bad - I could live with Rust. Rust is just far away from being fun and Carbon looks more like something I am looking for.
Found your channel because it's the first video I found on Carbon lang. sub'd
I think It is a language for people like me, I use C++ in my day to day but work in both huge codebases and embedded systems, wrapping a library is really a pain, and maybe later you are going to switch, and incur the wrapping cost again, the idea is to file by file remove C++ from our codebases, to a richer set of features without a lot of baggage we get from C++, sure not all of it but a lot, the smaller amount the better.
It's for people like me who don't want to use C++ cause the hieroglyphics scare me
some many common sense in such a small video. FYI Nim is doing a lot of right things, specially to reuse c++ code base
except white space sensitive
@@_slier nothing wrong with whitespace
Carbon designers say “use rust if you can”; carbon is for people who need to extend their existing c++ source bases. Rust adoption has been held back by lack of C++ interop IMO (swift gets further in Apple land because it can use all their frameworks and be mixed)
I like the star wars font in the thumbnail
So your conclusion is carbon is the wrong step in the right direction?
Short answer: yes.
please make a video on your implementation on defer in c++ it was magic when i first saw it, it would be really cool to have some more insight on different ways of resource management (mutex,db etc) and defer, and your thoughts on it, and how you came to implement this weird thing.
I have an article on it on my website (gingerbill then followed by a dot then followed by an org) and it's called "A Defer Statement For C++11"
@@GingerGames yes i meant kind of a follow up video on this topic i loved that article and the actual code for that implementation was very scary, i am always curious how do people get to this level, still great stuff.
This seems to be a language for people who are "stuck" with C++ but don't want to use C++. Similarly to how people who deal with web stuff are stuck with Javascript, but Javascript is garbage, and so Typescript was created, not as a full on replacement, but as something that's semantically similar but incrementally better.
Would love to see videos on rust!
Those are the same companies that need their own build system because the standard ones don’t work at their scale right?
Correct.
Do you have a video on Odin’s foreign library system?
No video YET, but a good example of how powerful it is is that you can use all of the amazing vendor packages that Odin offers (SDL, GLFW, Metal, PortMidi, MiniAudio, OpenGL, STB family, etc) and the entire build system is as simple as `odin build .`
It seems to do what classes did for JS. Even though JS classes are not "real" classes in that they are syntactic sugar for prototypes, they have made the language easier to use and teach and is now the dominate way to use the language. I think the same could be said of Carbon and C++. At some point, people at Google will only need to learn C++ if they want to dive into a system, otherwise, "just use carbon."
Damn! Hello World, 60 seconds? I wonder how big the binary is
experimental language - what u expect
@@_slier there are plenty of "experimental" research languages that aren't ass like that
nim can already interact with c++ or c, it works and it is real today.
The question is whether it can do bidirectional interoperability with ease, not just unidirectional.
@@GingerGames it can be used from C++ as well, as long as you put the code in a function and use C++ types. You have to call NimMain() from the C++ main() too.
I would use it if they didn't go with the bike shedding fad of `noun adjective` instead of the more reasonable `adjective noun` declaration syntax that doesn't need messing with.
Myself, I would like to learn how to make a language and build upon it, but it seems like its still some sort of trade secret people dont want to share.
0:16, you should really make a small video about Odin. 5-10 minutes just showing its features, 20-30 explaining them a little bit. It's hard to face a playlist of 3 hours videos each, just to take a glance over it. Your language won't ever get popular this way. I'll have the guts to get along with at least 1 of your videos, only because I'm curious about how something could be better than C++ (I lack imagination for that).
3:07, it seems they are too much worried about C++ type deduction. _"Even using (C++20) _*_concepts_*_ you still won't have _*_generics_*_ " (template from Java/C#)_ - Carruth, C++ committee member, working on Carbon. Personally I don't have issues about this, and love C++ fast/concise typing. Changing its features just because "people are not able to manage them properly", unfairly blaming the language, is the same wrong vision that made Java a so bad and ugly language.
8:00, I think it's nice to experiment, and C++ libraries don't interfere in the language, as it has been seen in higher level ones.
11:04, it's too early to be worried about it. It's just in an experimental phase. The language is way easier than C++ for being read by a compiler - _of course, it asks for the programmer's help, by messing the type deduction_ .
14:21, whaaat?! I think C++ is following the leading path. It has plenty of undefined behaviour opportunities, but that is for good reasons. Other than that, some traps. But it's the price for conciliate low and high levels, with all flexibility the language has.
17:25, I can't give thumbs up for this, because I don't agree with your opinion about C++, and because you failed to notice that Carbon already is destined to has its followers: people who are desperate about C++ type deduction.
PS: try to improve your diction. You smash words too much.
You cannot introduce any substantial language in 5-10 minutes. I have a 45 minute introduction video on Odin (on this channel), as well as a written overview on the official Odin website.
Bill what’s your opinion of c#? Is it a broken language? Is it as good as it is going to be?
Oh that shit was built for me m8....
gimmegimmegimmegimme
cette chanson est incroyable
Kindly, you asked several times who Carbon is for. It is stated by the Carbon team rather clearly: programmers who want a better C++ BUT who have a large C++ codebase that they cannot readily abandon. I would think that to be the majority of C++ programmers.
Precious few people are in position to make the clean break that Rust would require.
When this video was made, there was not much information on this topic as there is.
And there are many languages out there that do allow for importing C++, such as D or Nim, meaning projects can still use the existing code base. The bidirectionality requirement is very much a Google issue and not necessarily a normal one that even large companies.
@@GingerGames I understand.
Yet, the interoperability in the case of Kotlin-Java has been an absolute boon for Android and Cloud developers, would you not say?
@@hassandavis the foundations of C and C++ are bad to begin with, and not necessarily comparable with the things based off the JVM.
And the things C++ are used for can be very different domains to Java.
I wish the Carbon team well and hope for the best for the language.
@@GingerGames I think you miss my point here :-)
Of course, C++ has nothing to do with the JVM.
I mentioned Kotlin as an example of a language that supersedes another by providing ample interop.
For may teams, maybe even most teams, being able to move to a language in a piecemeal and seamless fashion is crucial.
It appears that is one of the primary aims of Carbon.
And that would make Carbon inherently useful for the common C++ usage scenario.
@@hassandavis you missed my point! Hahaha 😂
At around 8:35 you mentioned it being possible to make a reasonable C compiler yourself. I was wondering if there were resources you could recommend on how someone would get started in this space?
As a hardware engineer I've never been particularly enthused about using C or subsets of C++ for embedded, but that's the only tooling we get support for. Always thought if someone could just make a better version of C and have vendors adopt it it'd be fantastic. Great thing about modern micros is that if there's support for 32 bit ARM architectures you could technically use any language. Even Rust open source community has made an effort porting over STM32 libraries, but the memory safety in Rust makes register manipulation a bit awkward.
@Eleanor Bartle Thanks, I'll check it out!
If you want a resource to write a C like compiler yourself you should check out the videos of PerVognsen (Bitwise) here on UA-cam, especially the ones about the Ion compiler
I'm no book worm so take this with a grain of salt but I really liked "A Retargetable C Compiler: Design and Implementation"
Here's a good idea, C++ is getting ever larger and larger, more bloated and more complex, seemingly by the day...I know lets take some of that Rust syntax and make a blend of Rust and C++, but it's C++ enough for backward compatibility. I don't think that's going to confuse anyone that codes in C++ at all hmm...Or maybe you could start from scratch based on modern language design/requirements on modern hardware. Let legacy software be written in C++ as even COBOL is used today for some systems (because it would be a massive headache to re-write and debug).
Will Odin support arm processors, for example M0 that are often found in embedded systems?
Odin already supports the Apple M1 (ARM64) chip natively.
@@GingerGames I see. I think I have a limited understanding of the different arch terms. The Arm Cortex-M series are the ones I am referring to. For example, STM32F446RE has a Cortex-M4. I do not expect there to be all the libraries, but I should be able to link with the existing ones since they are all written in C, so long as Odin has support for these processors. Which is probably a big ask. Thanks for the videos and I will checkout Odin!
@@luz_reyes_676 I apologize for the minor confusion. Odin is targeting high performance modern systems, so even if some embedded system _might_ work, it is not its target platform domain. We will be supporting 32-bit and 64-bit platforms only (which I know most ARM chips do support (if you ignore the Thumb stuff)).
@@GingerGames Alright. Ill see if its possible for specific board. Thanks!
Tried carbon, took me 1hour to get it running on windows (so much stuff to install)
And then runned the hello world, litterally 198s (~3mins) for it to compile and run... (i5 10th gen, 8go ram)
This isn't practical at all, I don't even imaging compiling and running big programs with it.
Btw, can Odin work with MinGW's linkers or LLVM's lld linker on Windows? On the site it is told that I need to install Visual Studio build tools to try out Odin.
It can but it usually preferred to use MSVC's linker in general for Windows development. `-use-lld` is way to enforce lld usage.
Okey, thanks, I'll try that.
I really wanted to say "It is for me" but some of the details you pointed out really turned me off.
Like even worse compile times than C++, separate definition and declaration, needing to explicit in the wrong places (don't get me wrong, I prefer do be explicit with something that can shoot me in the foot and C++ has much of that implicitly).
I do very much like the interop in both directions, that would allow for a gradual transition to something more sane than C++.
Maybe they can improve the build times (crucial), but I am not so hopeful for some of the verbose design (The "returned val" with the extra "return" killed me).
What do you mean Rust is not focused towards performance? Overall, it is on par with C++ for speed.
Performance. Part of that is speed but there is more to performance. If you want speed you can dive off a cliff or mounting going really fast that way. But if you want performance you need more then just relying on gravity to carry you up to when gravity and wind resistance equalize, that is if you dived off a high enough place and reach that limit of speed. And do all this safely since that was the point right?
To outpace the air resistance you need allot more then gravity to get over the GRAVITY'S pull downwards to earth equalization. Obviously. But whatever good is speed going to be if getting to a high place is such a struggle and not encountered for or being focused on being a priority when built? Having no real way up the hill but it is built that way for safety. Having fancy brakes to stop you from going backwards but also not helping going up the hill. Snags sometimes trying to push upwards! But it is realistic to not overdo it and we can work on air resistance and get speed that way! Heck we might not need such a huge hill working on air resistance! This is Rust. Maybe we should make the thing heavier and so in that way we can faster fall! Or maybe just maybe we can make sure the speed censor is 100% safe! We want it not to be unsafe! What you mean it is written in C? NO NO UNSAFE RUST.
While Rust is being pushed up a hill for ages or really being carried up by some insane strong people, others are on flat ground and are just getting the same speed without having to first work out how to get up the hill by braking there back. Or maybe they work just as hard for no good reason and still not doing much better then the based RUST users that carry the language up that hill to GET BASED FAST. *splat.
Others go sideways and maybe still reaches the speed without needing to be worried about the air to ground fast approaching after getting up the dam hill and diving off. O what whas thaa *SPLAT. Forgets what just happened and starts all over agen to solve this problem of speed but "safely". Ignoring the blood on the ground. Or how making something complicated heavy or less of a drag to get speed and safely is really hard if you do it badly. Or even if done well the hill is still there. And no way we can have a engine do the work they are unsafe! It is bad to pollute! Popularity and fads rule!
But sure C++ and the like might hit a pothole or a wall. And some might struggle to win over air resistance or even come close to that point. Or when it is sold to costumer the wheels falls off since you forgot to fix the nuts and bugs. They where not there when you sold it! Maybe time passing started to wear it into a unsafe state? Might need to be maintained? Maybe shit happens but do not require to make sure EVERYTHING IS SAFE and still not being safe to work with. Or in reality rely on a nurse to fix the brain bleeding. :c
Some might even have a hard time getting into motion or like C++ have no dam brakes and need a to trash the gearbox and clutch in hopes of going anywhere. Unsafe and it cost something for that speed. But hey sometimes air resistance can be not given a dam about and just go slow but perform well in outer ways. Like not pushing up a hill or wasting energy trying to reach fast speeds. Just be slow and you can change stuff on the go and you do not need to stop and it keeps just going. You can jump off and walk besides it and still catch up to it going along even. Can jump off without braking your bones if it is going to hit a wall etc etc. Still not safe but I mean the speed is instead focused on other things to make it workable.
But the hill push and ground fast approaching sounds no fun to be around. Rather try the gearbox grind or just that slow thing that eats Pythons it can catch up to. Or what about building something that can fly and also go sideways up and down? Like a plane to the heavens? Not maybe safe but what the hell it is safest way to travel by statistics. Maybe a helicopter dropping towards earth might be a compromise to get that Rust safety and performant? Going up into the air and then cutting the engines to reach speeds? Common Rust you can do it! DO IT!
Performance going up being a focus! And the execution being really fast as the speeds are so dam fast that it solves the problem first time around! Execution complete! Safely.
C++ refuses to change and keep the rotten brakes falling apart since they do not stick or slow the speed down as they are now. So you are forced into taking it slower just to avoid danger. Or trying to cope with the gearbox grinding you have to sacrifice speed even if you do not want or really see it happen upfront. Imagen trying to fix the brakes and they stick! No no no! Or some people do not realize where they are anymore so we need to have 6 sets of brakes to make sure everyone are ok? Or worse the 100 different emergency "fixes" brakes fixing something not related to the brakes or even C++, they just stops working or SOMETHING stops working!!! AAAaa! Sounds like Java. And Java is. well. More of the same.
@Eleanor Bartle I am also not sure.
Maybe it is like TypeScript and JavaScript or Kotlin/Sacala and Java ?
Full backward compatibilty it huge step for success
no, it isn't. Typescript has a whole ecosystem around it since nearly the beginning and it adds some bells on whistles on top of JS.
Kotlin changed syntax heavily and its toolset is different than java, even if it can import java libs. the compiler is different and JetBrains is investing a lot into making it deliver the promise of Java ("code once, run everywhere")
Carbon doesn't seem to add anything to c and c++ nor flip the book on its head (like rust).
@@dukemagus Right. Maybe it is "simplicity" take like Go. Then google can hire and learn enginiers faster to write "ala c++" firmly standing on existing c++ libs?
its for llvm
as someone with first-hand experience in AAA game engine dev I would definitely NOT be excited to add some random new Google language to our build system and having to slowly migrate stuff by somehow working with these two languages side-by-side. If you don't work towards rewriting literally everything you'll always be stuck with 2 languages and if you do manage to rewrite everything - a couple million lines of c++ code over 20+ VS projects, god have mercy - you're stuck with this new language that barely improves anything as its just as unsafe, slow to compile etc. I bet some companies won't even consider a new language like Carbon because it would make job/hiring requirements more difficult as well
Idk if i trust this guy about Odin. I mean, he doesn't even have 20+ years of experience with it.
How hard is it to create a new programming language?
Why not just fix the ones we already have? Is that too hard?
I don't know anything about creating a programming language. Just asking.
It's not hard to make a language, but it is very hard to make a good one.
Fixing the ones we have assumes that you only need to make minor changes.
The really big problem with fixing a language is not the technical part. It’s the fact that a change can’t break existing code. Imagine code for a life support system for example and c++ would change what ”new” is doing? To make sure that the chage didn’t break the code, you’d have to go through the whole codebase and make sure that it still works as expected and there are no subtle bugs. Now imagine all the of lines of c++ that exist in the world, many of them which just cannot fail. That’s the hard part.
Adding new things to a language is much easier, because that won’t break old code. But the new feature has to be so good that it won’t have to be changed in the future, because that is hard (see above). :)
Interesting I did not know Odin. But anyway we are using D which already solves much of a problem that carbon works on soving. But anyway google makes a new langueus every second week
And that's great that you are using D! I hope for the best for you!
8:20 Sean Baxter implemented his own C++ front-end for Circle lang. I think, what's really hard to implement is the back-end. If I not mistaken, Odin also still uses LLVM back-end.
It's not unidirectionality that is the issue, it's bidirectionality that is. This means that the type system of your language must be 100% compatible with C++ both ways. I was quite clear in what I said.
@@GingerGames Chill bro. This isn't a class, you aren't a prof, and this commenter isn't a student. Chill.
@@KleptomaniacJames you're assuming I'm only writing comments just for the OP and not for others reading the comment section.
7:59 corps messed with cpp to add bloat in it to have oligopoly on cpp compiler & now are complaining about it being bloated
5:49 c is broken
You got to ask what happens if Google succeeds in this effort, too! Then wouldn't there exists a new potentially Google IP that dominates the programming space? Also tooling for c/c++ Is definitely in a ripe space for squatting ATM.
Oh gawd, what arrrrrre they doing?
He misspoke, because he just contradicted himself before getting 35 seconds into the narration. "It's a big language now. . . . It's a very small language." He should fix the audio or annotate his video with a correction, because I doubt he meant his words to come out that way if he had thought carefully before speaking.
Well, think again. A language can be big in X and small in Y e.g PHP is a big language and also a small language. Big in the sense that it has a large community and powers more than half of the web. Small, unlike python or Javascript, it can only be use on a web server.
He may have said that intentionally.
Who is Carbon even for? Well, it sounds like it is for me... I am Qt application developer and I wish I could abandon C++ and use some more modern language. Just natively, without any hassle with bindings.. :)
360p gang
It seems UA-cam needed time to process the video or something... It is 1080p now.
@@error-42 If you tried to compress a video with a modern codec (vp9 etc) at high compression ratio which is what youtube seems to be doing, you'd be surprised by how fast youtube compresses videos... It's more painful than waiting for a big C++ project to compile
Yeah, seems like an in-house solution to an in-house problem, seemingly not even that useful in Google's case. The name is also pretty forgettable, maybe naming your language after something that has a whole subdiscipline of chemistry to it is not that good of an idea
Deliberately or not, when you fail to disclose that it's the company you work for that's uses Odin professionally it looks like you're trying to pull a fast one
gingerBill's biggest by far claim to fame is that he is the creator of the Odin programming language and a glance at the channel will tell you that. It's primarily what he's known for among developers, it's not dishonest to assume a viewer would know or would figure it out quickly
It might be a wrong assumption, but not dishonest
@@tuatarian6591 I don't believe you've read my comment. My point is that in this video, where he talks about a company using Odin for a product, the company he mentions is the company he is the senior programmer for
Google don’t care about anything. Rust is woke.
After learning rust, this seems primitive. You are trying to pull back the entire community into the past (One generation back). Rust actually is not just about memory safety, but it's an evolution on many fronts.
The C11 standard specification is ~650 pages. The C++14 standard specification is ~1250 pages *BUT* ~600 of those pages are about the standard library. So the standard specification for the core language itself is virtually the same size as C11's. And the C++20 standard contains ~1100 pages for the various standard library modules and ~600 pages for the core language.
Complexity can't really be measured with page counts, right? Are those concise or sparse specs? It doesn't even matter though. The point is that C++ is huuugely more complex than C. I think we can all agree with that...
@Eleanor Bartle Yeah, it does.
It's also worth keeping in mind that C++ inherits pretty much all of the C standard library (, , , , , , etc etc).
It's definitely a more complex core language (and has a much more feature-rich standard library), so the standard specification is definitely far from lean; but I think that all things considered, it's surprisingly terse.
As a reverse engineer and a hobbyist game hacker, having no pointer arithmetic is kind of a big downside of using Carbon.
Whom* is it for.
And yes, I am fun at parties.
And you're wrong. Who is a subject pronoun. Whom is an object pronoun. The trick to know when to use "who" or "whom" is whether you can replace the "whom" with a "him".
"Him is it for?" does make sense, therefore it is "Who".
*What is it even for ?
you made a mistake
Where is the mistake? It's a tool for people therefore, who is it even for?
@@GingerGames nvm
@@jinxscript 🥺
can someone tell me why do we have to use "fn" to define a function ?
with this ugly syntax , they claim this is a successor of c++ 🤣
maybe ugly is relative
Dude...it serves the same purpose for C++ developers as Kotlin does for Java...this isn't hard...and it isn't even a formal syntaxes nor has its own compiler yet.