I stand corrected, thank you. As for RISC V, is there a chip with that on yet?-because I thought it was just an extension feature. I knew s390x did but I never really think of that system to be used outside specific mainframes. No modern SPARC machine has f128 support as of 2004. What are the instructions on ARM64 for the f128 arithmetic?
I haven't used C++ since 1998 and have mostly been writing PHP scripts for the past 20+ years; Carbon isn't something I'm likely to find any use for. But I watched this after seeing the CppNorth Carbon intro video, and it was fascinating. I'm always in awe listening to someone who obviously understands computer languages and programming on a much deeper level than I do even after more than 3 decades of programming in various languages (Fortran, C, C++, Smalltalk and Pascal for example). Thanks for 90 minutes of geeky entertainment! :D
PHP for 20+ years? Sounds rough, but I hope you've found a way to enjoy it. I did C#, JS, SQL and web frameworks for 10 years and I was pretty disengaged after the first few years. It wasn't until last year when I rediscovered my love for programming through how much simpler and understandable low-level programming is - I had always wrongly assumed it was futile and less productive. There's less help from others, sure, but when you get familiar with the basic debugging tools like reading disassembly, performance profiling, circular buffers, memory arenas, thread job queues, rigid-to-unsettled architecture layering, low-level programming is much easier (in larger projects) than confusing web stuff tbh. It's mostly the unnecessarily complicated graphics API's that suck, but at least they barely change (one can dream of a day where each GPU vendor makes their own direct API instead).
Never heard of Odin language till now. Will check it out. Enjoyed the over view of Carbon Language. I'm definitely excited over the potential of Carbon Language.
I find Odin more productive than other alternatives and also its syntax is memorable. I wish in the future we can write concurrent programs in Odin as easy as Golang
I took a look at the Odin code on the repository and I am really impressed by the flexible and intuitive ways of iterating through arrays. It's often awkward in these sort of languages. The walrus operator is better for assignment too imo, let equals sign be equals. Odin looks pretty promising. There is another language in the alpha stage Peregrine, it's a statically typed python made to be easy without any loss of performance. It looks promising too. But I think it will be mostly used by python programmers if it ever reaches 1.0 All in all kudos to the creator of Odin, he has done a great job so far.
I'd beg to differ... I've managed to come to "reasoning why auto as a return type is bad" part for now and it's getting harder and harder to go and waste time with researching Odin deeper. Both Chandler and this guy have the same issue: they are smart but their ego is far greater than their knowledge so I'd ban both from going even near a keyboard. And that's how you get so many new languages that are more or less a one trick pony that don't warrant a new language but "it's too hard to extend something that already exists" (which wouldn't be a problem if such experimental lab languages wouldn't get so much praise from random people that they become a muddy-the-watter-headache). So in the end this video is quite nice to show two languages for which I don't see any use at the same time... But yeah... For Odin I still have to look at to form an opinion which will perhaps be positive (for Carbon that ship has sailed almost a year ago when I last looked at it). But hey... To each their own...
@@jackmordaunt5410 Like I said - to each their own :) Maybe there's some random Java worshiper here that would disagree that Java made more damage than sensible moves due to it's existence :) But since our programming thought patterns differ, it's possible that the new languages are the next best thing since sliced bread :D Tough luck that they came a bit late and just cause more damage with field fragmentation than they do good but hey... At least some people get salaries while working on their should-still-be-private-due-to-immaturity-and-one-little-difference-compared-to-others hobby project ;)
This was very interesting, thanks for the video! I decided to check out Odin after seeing `.xy`. I'm currently creating a C transpiler for the language I have in mind. I did switch back and forth between C and C++ more than 6 times. For lack of generic programming and namespaces in C, and templates and concepts just not working with const qualified types in C++. I might just write it in Odin!
Found this after the CppNorth talks. My only previous awareness of Odin was from Andrew Kelly's shoutout at Handmade Seattle, and I'm glad I sat through this. The CppNorth's presenters' academic hand-ringing pale in comparison to Bill's tactical experience from developing a production language. For him, languages are a tool. For them, they disagree with the previous committee, so they're forming their own. Wonder what kind of design decisions they'll come to? Last 30 minutes were the best.
I read a tweet and immediately searched in youtube to get broader aspect and found your video. Maybe I should start following your channel to get more latest info
I am implementing and this video is super useful. I love hearing your thoughts on various programming constructs, and why some might be better than others. Super useful as I try and discover the best syntax for my language.
I watched the video to hear something about this Carbon language, but instead I realized that Odin is fantastic for my purposes, and in general. I am currently using Go and I like it. (I am not a programmer, but a scientist who wants to make custom tools for my projects, that's why I am using programming, but I also wanted to know a highly performant, safetype, general purpose, non-OOP language, easy to learn, and so I chose Go over Julia or Python) Now, with Odin, I don't need to write my own matrix package in Go (although I've written quite a bit of it already) . So nice to have it built into the language itself. Element-wise operations on arrays are a candy :D Q: How would you rate Odin's performance compared to Go on one hand, and Rust, on the other?
I apparently really need to look into Odin. It looks like it may fit a niche I am really interested in. So far, c++ (c-style-ish) is the language I regularly fall back to despite extensive rust programming experience. I also think zig is nice, but it just doesn't satisfy me.
I was around in the initial stages of Odin, although forgot about it as I discovered Rust. I'm sure I was subscribed to this channel at one point but apparently not anymore. Then this video popped up, and think I might have a look again! Good impressions video! Very informative.
great overview of BOTH languages, is great that something is happening in the C++ world, I'm NOT excited about C++ 20 or 22 or 25, but this could be a good direction, hopefully they make it SIMPLER and not Rust like, in the mean time, I'm enjoying Odin and will be for a while, thanks Bill
@@joshhoover1202 you got that right, why would I care about something 4 to 5 years from now, 20 is not even released yet, 23 would be what? 2026, 2027? :D
@@varomix 20 is released and 23 is effectively completed. I have spent most of the day writing code that is uses things from 23 and is compiled with the c++23 standard flag.
@@joshhoover1202 that's great, still that fixes none of the issues with memory handling, RAII, rule of five, is just too much baggage, maybe you are good with that, I am not and clearly, since they are making an alternative, other people aren't
15:10 I would guess the arbitrarily sized integers can help a lot with efficient serialization and networking code. You can do bit masks, bit fields etc. but I could see how this is more error-prone and painful than just having fields packed like that into types that can be reused in different places. Something like that can be (with some extra effort) handled by the compiler that is generally great for accounting tasks like that. At the same time it would take an enormous effort to handle this with a generic library. It would probably even require some insane features in the generics to make it possible to handle by a library. Yes it doesn't map to set of opcodes, registers on the CPU, but it does map to actual bits in a message sent over the net or stored to disk. As for 256-sized types, I would guess it's something that's useful for cryptography?
I actually like the Swift-but-C++ approach, but it's sad they got things like namespaces and visibility wrong. Also, why name it 'choice' when you can name it 'enum' and get familiarity? I hope the language will be heavily updated in the future. It has great potential, but right now the execution is terrible...
We need some language similar to what Kotlin did to Java... You can literally write java code Inside Kotlin and use all it's lib. Rust is doing great but when I try to use some c/c++ lib it's really hard to bind. There are ton of C++ lib already exist and it's impossible rewrite everything in Rust or Zig or Golang or any other ..
If the type system is bad in C then you have to make sacrifices and inherit problems from C and C++. Some of the problems in C++ is because it was compatible with C.
I like the way you've done the language comparison here. Obviously this was prompted by the announcement of Carbon but do you think you might do similar style comparisons vs any other languages, for example Nim?
i'd like a combination of destructor RAII and defer - the destructor on classes might make it feasible to construct various smart pointers and the later will be for arbitrary resource cleanup where don't want the fuss and boiler plate overhead of devsing a destructor-based class clean up of said resource
it's nice to see my art side and love, and my technical programming interests side touch on youtube ( this makes sense but doesn't happen that often). EmberGen is a really impressive software although I don't use it myself (yet)
Sounds like another incremental "improvement" of an existing language instead of a genuine innovation that actually solves a problem WELL. Not trying to sound ungrateful for the load of other languages that have been made over the last 10+ years, but this is just a trend I've noticed. Soon enough, there's gonna be an Odin clone because some team got tired of the "problems" they saw in the language, so they made a new language with more tangible issues than the original language it was based on.
And I would welcome people making their own languages to a certain extent. Odin isn't a incremental improvement on C or C++ though, and is quite radically different in many ways, especially its philosophy. It's solving real problems that other languages struggle to or even cannot even do.
@@GingerGames And that radical innovation in Odin is simply awesome! Thank you very much for your wonderful contributions to the programming language culture. Truly a wholesome inspiration for PL designers everywhere.
I definitely prefer that people either make incremental improvements to the existing thing, or make substantially useful and new changes to a new thing, rather than making a new thing that has very small incremental improvements. That said, this is often impossible because "improvement" is extremely subjective and most projects will veto many "obvious improvements" for a number of important reasons (maintainability, compatibility, core values, etc.) as well as unimportant reasons (arbitrary beliefs, unfounded opinions, they just don't feel like it, etc.)
@@dandymcgee Case in point for that solid insight, "obvious" improvements like the KAIL Selector from 1975 were not in industry because it strayed too far away from common convention. Who'd want to rework all the language syntax just to retrofit something wacky yet awesome like that?
the design goal for Carbon is to capture the group of projects that cannot feasibly move to Go, Rust etc., so that explains a lot of the decisions they make or are going to make.
14:30 Arbitrary bit-width integers are useful for serialization, working with binary formats, or in situations where compact in-memory representation is more important than performance. Whether they map nicely to hardware is not really relevant.
It is relevent, but I am also not a huge fan of them in general. They are a viral type (in that they "infect" everything). It is never "just" adding a feature to a language, and arbitrary bit width integers are one of those pesky things people don't realize become a problem until later on.
Is there a single RISC V machine that physically exists with 128-bit float support? As for the IBM stuff, I've never personally used onr and it's not really a high priority for us yet in Odin. BUT if people want it, we can try and support it! But if the only machines that support 128-bit floats _natively_ and _exist_ are IBM, old PowerPCs, VERY old SPARC (20+ year old), and some rare MIPs, then it is safe to assume that it's not really a good idea to have it as a core language feature in my opinion.
@@GingerGames I'm uncertain whether those extensions are used, and I tend to agree that support for IBM's big iron is out of scope for most languages. With its current rarity, it certainly shouldn't be priority, but it may be worth exercising care not to exclude it.
I love the "type on the left, usage on the right", but is there a reason why varargs are done only on the left? For example, with print :: proc(args: ..any) --- arr := []int{1, 2, 3} print(..arr) is it simply easier to parse, or what's the reason?
There a few reasons for this: variadic parameters are not a type, so the rule isn't broken. It's clearer when it's in front than at the end. It prevents common mistakes with people trying to use .. as a range (only ..< and ..= is valid). It's common to do that in other languages (i.e. familiarity).
Name a machine today in common use that supports either of those natively. So any "future-proofing" makes little sense, especially since adding the constructs would be easier to do when actually needed and supported by hardware natively.
@@GingerGames Please don't get me wrong - I'm not trying to defend it. I'm just trying to figure out what the motivation for those types is, and wondering if maybe that's what they're trying to do by putting them in there. I completely agree that it's all very strange.
@GingerGames maybe it for implementing cryptographic stuff easier, since they often deal with 256bits? Or maybe they already deal with SIMD internally anyway and chose to expose it for some reason. But yeah, it's weird. My last guess would be that they got scared at the state of IPv6 (because the lack of a 128bit Integer is imo one of the reason why we today are in this dual mess) and want to make REALLY sure to prevent something similar. Aka, programmer ptsd. But I know some machines with 128bit floats.
I didn't see you recommend Rust, what's your opinion on it ? great video btw, these comparaison are the one that will get odin to the general public faster .
For the Odin switch statement, you mentioned you would only have the two states and leave the nil being handled by 'case:'. Is that because nil is a possible value for any variable, or being the union was optional?
Hey Bill could you go into more depth on the tuple vs multiple parameters subject? You mentioned this several times in the past but I cant remember if you actually explained what the difference is. If theres some video where you discuss this let me know.
Nice thanks for your comments. May I ask a question about thr designt choice of the for loop? I like that there is only one loop type, but I wonder why you did not use "foreach" for the "for in" loop and the normal "for int i..." loop for the rest. (So many for xD)
Other than the declaration syntax and a few minor things, they are quite different languages. You can search for Odi vs Jai for a quick overview, or ask someone who has used both. You'll find out quick they are not the same.
i don't know know if having built in matrix types and maps makes your language better it's all about the building blocks. Carbon will go much further than Odin in the long run.
@@chengcao418 I don't actually care about potential chips, but actual chips. And in practice, I doubt it will be widely implemented because it's probably not that useful in practice. And even if a RISC-V chip exists, as I was corrected in the comments by other people, other than z390 or archaic MIPS and SPARC chips, there are no native 128-bit floating point chip support .
I don't get why Odin has slices, it seems like a convelutet way to have an array, and in the few hours i have used it, i had problem converting from/to dynamic array and slices. Why not just have constant size arrays and dynamic arrays?
Slices a runtime _view_ into an "array" which may or may not be allocated dynamically nor be able to append to. This is why there are distinctions between the arrays in Odin. If you only had constant sized arrays or dynamic arrays, you would not be able to write much generic code efficiently when the length of the array is only known at compile time and when you do not need to copy the memory all the time.
This might sound like a silly rhetorical question but why would you not just go for big floats at that point if you need even more precision? And I have high doubts any mainstream hardware will support it any time soon.
What do you think of 'Bits Inside Rene' s (RU-vid) opinion? To vaguely summarize, he says 'dont reinvent the wheel'. That Google should have spent the resources fixing C++ or supporting Rust development. Unfortunately, he did not give much feedback on the language itself, like you did.
Since when writing performant code in Rust is unsafe? You write unsafe to express some invariant that the compiler doesn't/can't know. It has nothing to do with performance. Rust, without unsafe, is as fast as anything out there.
This rant about undefined behavior is a straman argument, the spec clearly states that in performance builds, there are no overflow checks to minimize the overhead, in development & hardened builds the overflow checks are the default behavior. As for this being "only exists in c++", is just plainly wrong, any lang can have overflow errors...
Having undefined behaviour in performance builds is still the existence of UB. And overflowing of arithmetic can be well defined, but that behaviour could be a logical error in the code itself rather than operational behaviour which is undefined.
@@jakobpovsic5504 overhead compared to what? Because if you are checking the for the error of an overflow, then that's a branch on very check, which is a huge overhead compared to not having a check and assuming 2's complement behaviour.
I understand it's your project and the easiest point of comparison for you, but I felt like you talked about Odin way too much here. Something I'm unfamiliar with being compared with something else I'm unfamiliar isn't very helpful, especially when this is meant to be a c++ replacement.
It's non-related teams making different tools for their own personal needs. The more languages the better. There doesn't need to be a single language to rule over everything.
I dont like c. But here's the thing, I am very productive in it. I think the reason is because c is minimalistic and simple. Comparing c to odin, odin has way too many types, selective data structures built into the kernel, etc... Carbon on the other hand, is simple and minimilistic. Whats your take?
I use odin for several months and for me is much simplier than C for many cases. Sane slices sintax, array operations for default. I found Odin with lower friction than C, much lower. And the sintax is very simple and clean.
I have the impression that Carbon tends to Zig side of the force (high verbosity, very structured, syntax and types very explicity (semicolons, parentesis)). I also worked with Zig for some time and I found harder to use than C
When you say "selective data structures built into the kernel" do you mean the standard dynamic array, hash table, slices, and tagged unions? AFAIK those are the only "built in" data structures (meaning they have custom syntax), which really isnt they much, and you'd end up wanted to implement some version of them anyway. Everything else is standard library, which could be used or discarded. I've found Odin to feel more productive than C for me, it has fewer gotchas and a more expressive type system. I'm also afraid that maintaining comparability with C++ will keep Carbon from ever being minimalistic and simple, but time will tell. It feels like a step in the right direction, at any rate
EDIT: I hope the Carbon devs take this video to earn how to improve some aspects of the language. There's potential in this new language, let's not forget it's just v0.1 (like Pre-Alpha levels of early in development) so many things could and WILL change. If this new language does reach the goals google is talking about, several areas in the CS world could see improvements like coding less in time. Taking Game Development as example: Many game devs out there are stuck with one or another language because of the engine they use, and many times the engine uses only C++. If we combine this with how complex game development is, we have very long development times while they also have to keep legacy code because of several reasons like the engine itself being rather old, prior games, old libraries for games, old code that can be reused for specific purposes, etc. If they can keep all the C++ code they already have but they start using a language that is easier to understand and allows for faster coding, then the devs could meet the deadlines more easily and to deliver less buggy games. This could also result in devs being less overworked ('cause we all know game devs work like slaves) but it would depend on the company.
It's a carbon copy of some of the lesser features of Rust. ..which to be fair is good idea, as most "C++ programmers", i.e. the people that call themselves that, are too dumb for the more advanced ones anyway. So it's a win-win. Good pitch for Odin though. I literally knew nothing of Odin and now after watching the video I have some basic understanding why I might want to use it instead of Rust or Zig in some cases. Native complex calculus and operational math primitives do come handy from time to time. I do like some of the Pascal like syntax readability.
When I see everything Capitalized in a language, I just tune out, tbh... I like syntax that flows through my fingers, and doesn't require me to press shift a million extra times. And then you have functions syntax-highlighted in the exact same color and casing as class constructor calls. PascalCase/camelCase are harder to read and harder to write, and have zero advantages. Somehow they still became a massive trend...
Let put the Edit first: I have no idea what are these 2 languages, so this could be quite fair. Only according to this video, Odin is quite math and computational, while Carbon is quite glue and giant project friendly. They are designed in totally different purposes. Also, I disagree with what you said about the a.xyz * b.yzx. Carbon shares some philosophy with c++, and this feature should be done with std library rather than language feature. In fact c++ consists of 2 major parts, the built-in language features and the std library. They are both specified in specifications. Carbon probably does this with std library if it really does this in the future. By the way, c++ has complex in its std library which people rarely know about. I agree with you about the complexity. Complexity is really a harmful side production of all the features people want. About the impl. This is probably only for the built-in functions which can be called with +, -, ->,
You CANNOT implement swizzling at the user-level, it must be a language level feature for it to even work correctly. You are forgetting stuff like this `v.yxz = ...` having to work correctly too for all cases. As for my comment on `namespace`, C++ namespaces are a hack and a proper package system (like Odin or Go etc) are much better choices. I can understand they are supporting the C++ way because they need to be ABI compatible but otherwise, it is a worse approach. And regarding the constraints, if you need such a complex system to do all of those constraints, you might have other problems which need solving first since you shouldn't require many constraints in the first place. The && thing I mentioned was JUST a minor thing about error reporting of a short circuiting expression, or at least trivial reporting.
@@GingerGames With c++ philosophy, the swizzling should be done like: c = std::mul_xyz_yzx(a, b); But the problem is not about how to implement it, it's about this is not what c++ is for. Since you mentioned, Odin has built-in max, min functions, and also a lot math features. C++ doesn't, because it's not what c++ is for. About the constrains, this feature probably helps well for the library devs but helps only a bit for most of us. So, the example is only to show my idea. Odin probably doesn't need it. It's based on the c++ philosophy.
@@hanyanglee9018 Odin isn't oriented around math and computation, surprisingly. We are in many ways Game and Application Oriented, as you can tell with EmberGen. But my point was that Odin has features which are better fit than if you just had a generalized operator overloading approach. A general tool can rarely be useful for a specific problem. As you can guess, I am not a huge fan of the "Modern C++" philosophy and the requiring loads of typeclass constraints in general is a sign you have just got a awfully architected code base to begin with.
@@GingerGames Yeah, thanks for the comment. I thought the idea over and over again after I read your comment yesterday and I came up with an idea of, if namespace helps prevent name pollution, then should language feature be limited in scopes? If a.xyz is accepted by the grammar, then all the x, xy, xx, xxx, xxxx, xyz, rgb, are all reserved as keywords, or in some scopes these are occluded by language feature. Just like the name pollution, the std::move from algorithm is occluded by the std::move from utility or some other header. This scope of feature is not mentioned at all, at least I've never heard about it. Idk if this could help with anything.
@@hanyanglee9018 They are NOT keywords in Odin nor do they need to be. The swizzling shorthand syntax is only possible for arrays and simd vectors of length
having interop with c++ is a fantastic idea to upgrade a language to a better, modern language. this is the main benefit of Zig which gives a significant improvement over C and the interop makes it an ideal choice to have source-level access to all your C code while writing in a significantly better language going forward. carbon in my opinion does not seem to be a significant improvement over C++. it doesn't seem to me to be any sort of improvement at all. i see no justification for a C++ programmer to switch to it with the idea of having source-level access to all their c++ code.
as an experienced c++ dev, I would happily switch over if they deliver what they promise ->Out of the box package manager (biggest win) ->Massive decrease in complexity (which is present in c++ due to legacy reasons) ->Simpler generics/templates. As someone who works primarily with c++ templates and concepts, carbon's proposal sounds miles more simpler and productive. ->Inheritance that actually makes sense ->better memory and const safety (will have to see how it actually turns out tho) ->Much more friendlier errors ->More readable syntax ->Syntax that's is more consistent with modern languages like rust and typescript Honestly, with the minimal learning curve and being able to use all the c++ libs I love, I see absolutely no reason not to switch over.
I do not think that such a rough critique of Carbon is fair at this moment. The language has just been announced and none of its features or syntax is final, now it is just an early concept. Slow compilation is something that can be vastly optimized in the future (and can be expected to be much faster than C++). In my opinion such a language is highly needed. There is so much code written in C++ and Carbon can give it a new life... Nobody will rewrite everything to Rust, Zig or Odin. There are so many developers who can choose only to stay with antique C++ or hope for something like Carbon.
Being critical at an early stage means there is a better chance that things can improve for everyone. I have no problems with people being critical with Odin, especially when they have good points! I have also never suggested nor stated that people should rewrite codebases in another language. If that codebase works, keep it. The point about Carbon is that it's clearly meant for the needs of Google where it has MASSIVE C++ codebases where new projects must use the existing C++ code and cannot be written from the start using another language. It's pretty obvious that the creators of Carbon would rather use Rust if they could but they cannot because of this legacy integration problem. I wish for the best for them in their endeavour.
@@GingerGames There are many companies which have massive C++ codebases, not just Google. In fact, every company which I have worked in, could vastly benefit from Carbon if the expectations get fulfilled. And there are massive libraries used by many, e.g. Qt, which would be great to be used with a modern language.
@@vladimirkraus1438 Would those companies actually require _bidirectional_ interoperability? I'd argue even those big ones would benefit from just having unidirectional interoperability (when starting new projects), and many languages already support this when dealing with C++ (D is a very old example of this). My worry about Carbon in its current state (which I do keep repeating in this video) is that it's not great and needs a lot of work before I would recommend it to anyone, and I am not talking about the experimental nature of it but the design of the semantics of the language itself. And now that the actual lecture has been released on RU-vid (which I might need to do another video on), Chandler Carruth explicitly states that this is just an idea of what a successor to C++ might be. I hope for the best for Carbon, and truly do.
i don't think so cuz indentation craps and that kind of things programmers hate . cuz we need to measure it everywhere which is boring and annoying as f
I liked it until he started talk how slow this is. Which might be the case, but it wasn't show how was this compiled to begin with. Seems like he should've skipped this bit.
No matter how its compiled any hello world program should not take 3 minutes. It just shouldnt and if theres so much code that needs to be compiled for it to take 3 minutes than the standard library implementation is very bad
@@krystofjakubek9376 I think it's premature to base any findings on this still yet an "experiment" - I doubt the effort would be to create a slow compiler.
You do realize that those "strange" struct literals are exactly C/C++ syntax, so something people going from there to Carbon don't have to re-learn, right?
I do realize this very well, but it also misunderstands why they are written that way to begin with in C and C++. It has to be `{.x = 123}` in C and C++ because `x = 123` is an expression. But because the rest of the syntax in Carbon is different enough from C++, stating making it easier to transition is a moot point. And I was also criticizing the inline struct (not class) syntax too which differs between the literals with a colon and an equals. e.g. defining a struct type using this syntax `{.name: String, .count: i32}` rather than something like struct{name: String, count: i32}` which would be more intuitive, but maybe they are trying to make structs pseudo-POD whilst `class` can have all the fancy stuff.
On the hexadecimal floats ... I think they should have picked a hex exponent, too, but I think it is still much more sensible and useful than your 0hxxx notion. The whole idea, at least for Carbon/C/C++, is to have a representation that doesn't lose bits, but is otherwise independent on how the float is actually implemented, and yours seems to be the exact opposite. For example, you can convert a single precision float on one hardware into this hex representation, and assign the result to a double on a different hardware, and you'll get the exact same value. That won't work with your version, which I also find exceptionally cryptic, unless dealing with floating point numbers on the bit level is your daily bread and butter, which describes very, very few developers, I'd estimate.
> independent on how the float is actually implemented That completely misunderstands the entire point of having 0hxxxx float literals. They are extremely useful for writing algoriths that require a SPECIFIC constant for a SPECIFIC sized floating point number. And those low level algorithms (which many programmers may never use, but I do write these) require specific bit layouts which may not be easily represented with the hexadecimal float literal (or comprehended). You NEVER required a C-style hexadecimal float literal for a generic-width float (which is what you are arguing) because you can use a decimal literal to accurately represent the number. As for the representation of floating-point numbers, Odin explicitly requires them to adhere to IEEE-754 (and I bet Carbon does too).
ya, its equally weird as fun or pub - function and public is okay ... BIASED, as I like java, just java, latest features, on-the-fly compilation/execution of single source with many classes and refs to jar libs folder for simple jdk+fx javafx tools, no build system, javafx gui hello world in a second, everywhere down to raspberry pi, just launch special extension source file :-) (yes, that was my effort to push these things to limits during re-learning java after years elsewhere, mostly c# - net maui isnt ready, javafx is ready and with gluon/graalvm using AOT compilation to native... with harder interop on ios/android then, ya) ... but I am here just peeking for something prettier down to AVR/ARM/RISCV MCUs, having arduino weird c/c++ mixture, not liking rust syntax nor any newage totalitarian code of conduct...
Regarding constness, unless Odin has solved memory aliasing then const is one of the most important ways to tell the compiler to not read the same thing again and again from memory. You indeed talk about Odin's default const function parameters being an important optimization, but you do not also consider that constness in other places would also similarly help the compiler with optimizations.
@@GingerGames You are right about restrict, it is indeed another way to persuade compilers to optimize memory accesses, but you are not right about const. It works, not great, but it definitely helps the C++ code that i'm working with, *more* than restrict does.
@@elefteriosstamatogiannakis7024 I can literally quote Chandler Carruth if you want. `const` does virtually nothing in terms of optimization because of the ability cast it away at any time.
@@GingerGames Interesting, i didn't knew about that person. He does 3d physics, i do too and my experience differs :) (Edit) Delightfully you are right :) . I tested the const behavior of MSVC by removing constness from different (non-function parameters) parts of the BeamNG physics core and for most of the parts there was no performance change apart from one part. In the main computational core, there was a performance *increase* of around 0.5% which is a surprise :) . Thank you for teaching me something :)
They should stop recreating the wheel; why not just use Rust? However, I hope that some Chromium code is rewritten for better performance or security. I am not too satisfied with the performance of the major browsers, could be better, especially in the rendering department. But it seems, that it's a time for experimentation; people trying new things to see what sticks, and what doesn't. Not really great for developers that just want something they can depend on in a few years that will be still commonly used etc. Also, there's the issue of fragmentation of code bases; for crying out loud, just looking at how many fricking languages some projects use sounds like a bad idea. Something great will come out of this. It's just annoying for now :/
If you don't care about maximizing performance, undefined behavior is easy to avoid. UB is not inherently bad though. By leaving the behavior undefined and acknowledging that you shouldn't do X, a contract of sorts is formed between the developer and the language. The programmer agrees to not do specific things, and the language uses this assurance to cut corners. This is often called the "worse is better" philosophy, and you can't argue with its success, as software designed under this philosophy spreads like a _virus,_ and improves over time. Unix, C, most of the software that exists and is relied upon today is built on this philosophy. And to those who give it the time of day, a modern C compiler is actually a very effective software development tool capable of as much safety and error detection as any other TheRightThing language that proclaims safety. Don't knock UB just because it makes things harder. UB enables software that rivals the performance of an assembly language while still being portable. It's not just questions like "what should the compiler do if a signed int overflows", it's also questions like "what happens when an out-of-bounds pointer is dereferenced" and "should it be the compiler/runtime's responsibility to protect against that". UB says no, and lets the compiler assume that these things can't happen. So sure in the early days a badly programmed application could crash a whole OS, but the nature of Worse Is Better is that the technology improves over time. Nowadays, you don't _need_ your compiler to protect your OS, because the OS can protect itself. Anyone who has experienced a segmentation fault knows this first hand. But something that people don't really pay attention to is the fact that the compilers improve, too. C compilers these days are VERY sophisticated and are capable of warning about most causes of UB. From options like -Wall -Wextra to -fstanitize=address, the tools have improved tremendously. It's easier than ever to write safe, portable C code that compiles with -O3 and works reliably. Take writing to a string literal, for example. You can assign strings to be `const char *` for that extra layer of protection in case you later forget it was read-only and the compiler will treat violations as an error. I advise anyone programming C to enable all warnings and take all warnings seriously. If your compiler spits out warnings and you ignore them and proceed to complain about bugs, that's on you. By the way, C23 (the next standard in the ISO C spec) will be requiring two's complement signed representation.
UB is inherently bad and only exists because of the legacy of C and C++. It is not inherent to a design of a language and has little to do with "optimizations" here (no matter how many people assert this as if it is even true). Compiler writers do "exploit" UB and "optimize" around, to which I don't believe that is any form of optimizing whatsoever and an absolute danger. I do care about maximizing performance a hell of a lot but I do also want my code to do what I expect it to do, and when writing in C and C++, it is nigh impossible to write code which does not invoke some form of "UB". I do not knock it because it makes things "harder" but rather there is no good reason it needs to exist in modern languages because every instance of "UB", you can literally define anything you need be it at the language level, compiler level, platform level, or vendor/core-library level. You need rules of the game to even actually optimize something to begin with. If you have no rules, you are not "optimizing" are just producing literal garbage: Garbage In Garbage Out.
NULLs are definitely a billion dollar mistake. It's the main reason so much software crashes nowadays. The issue is that programmers are not forced to check if they can become NULL. Carbon is definitely right here, Odin is wrong. Rust's Option is perfect because it will optimise to a null pointer for the None case. Hopefully, Carbon has the same optimisation.
Odin's `Maybe(^T)` is identical to `Option` in Rust in terms of semantics and optimizations. I think the notion that “null” is a billion dollar mistake is well overblown. NULL/nil is just one of many invalid memory addresses, and in practice most of invalid memory address are not NULL. This is related to the drunkard’s search principle (a drunk man looks for his lost keys at night under a lamppost because he can see in that area). I have found that null pointers are usually very easy to find and fix, especially since most platforms reserve the first page of (virtual) memory to check for these errors. In theory, NULL is still a perfectly valid memory address it is just that we have decided on the convention that NULL is useful for marking a pointer as unset. Many languages (including Odin) now have support for maybe/option types or nullable types (monads), however I am still not a huge fan of them in practice as I rarely require them in systems-level programming. I know very well this is a “controversial” opinion, but systems-level programming languages deal with memory all the time and can easily get into “unsafe” states on purpose. Restricting this can actually make things like custom allocators very difficult to implement, along with other things.
@@GingerGames My point isn't that null dereferencing crashes are not easy to spot or fix. This fact is of little use after software is released. When it crashes on a user's machine, you're not going to be there to fix the issue. And my point isn't that NULL isn't a perfectly valid memory address for representation. The issue is mixing the NULL representation with a valid reference. These should not be part of the same type. They should be distinct types despite the fact that on the CPU it's represented as a zero pointer. This means that you can't pass a null reference to code that expects a non-null reference (or vice versa). That's the billion dollar mistake. And I don't think it's overblown at all. A huge proportion of RELEASED software crashes due to dereferenced null pointers. If the code used Option (or the Odin equivalent), then such an occurrence is an impossibility. Congratulations, you've wiped out most of the crash bugs. This is because you won't be able to dereference `None` and hope the compiler passes. Now all you have to worry about is dangling pointer issues caused by pointer aliasing. Something that is impossible in Rust too. C++ and similar languages will let you blow your foot off here if you're not careful because it has a poor model for ownership.
@@cthutu there is a huge misunderstanding here. The solution to the NULL pointer problem is not better pointers/references but to not use pointers but use a better tool: handles. Handles are better than pointers. Handles can be smaller, have generational counters on them, and other metadata. The can be ensured to be safe to use at runtime due to the explicit checking. They don't have any of the ownership issues too. NULL pointers are not a problem to be "solved" since the better solution is to not use anything like pointer/reference.
@@GingerGames again I disagree that the solution isn't better pointers/references. The reason I think that is based on my experience with rust. Here I have references that are safe. No aliasing, dangling pointers or null dereferencing. But still a simple pointer. No need for higher abstractions such as handles. Handles are a good solution for C++ because of C++ and its poor type system.
@@cthutu Handles have nothing to do with the a poor type system. I highly recommend you read floooh's article on the topic "Handles are the better pointers". Handles separate the resource reference from the resource memory address, and allow for a lot more benefits than a reference could ever give. People in Rust use handles all the time too!!!!
This is the never-ending story about replacing C or C++, seriously! Is this a joke? The Linux kernel, the scientific software layers and libraries, the critical systems... the several million lines of C++ code to be rewritten/recast or re-engineered in this new thing...Good luck re-writing the whole f**ng world 😂 and what's the catch with that ugly syntax ? CarbonCON in a Carbon free world...! 😂
Well one of the goals of carbon is that you dont have to rewrite whole codebase but use them both. Also believe it or not c++ is not “that” used in scientific software
@@coderdfc4048 For well objective reasons I definitely do believe that C++ is heavily used in scientific software well, I see that every time I compile a heavy open-source scientific software (and its underlying dependencies 90% of them in C++), to name just a few on the fly: MOOSE framework, Deal.ii, nektar++, Elmer, openfoam, Trilinos, petsc in C, SALOME, GetFEM++, MFEM, FREEFEM, DUNE... Object oriented c++ is heavily used in these high performance computing codes, and this list is a tiny little < 1% one. As you may already know Sandia Livermore Idaho national labs and the majority of research institutions across the world use C++ as their main programming/problem solving language. Other languages are either used for preprocessing, post-processing or rapid prototyping and data visualization.
@@elguapo3436 my mistake, i should not have generalised. I have been working in aerospace industry for past 10 years, and i have been an intern at cern a couple of times while I was a student, and i have rearly seen any c++ code. Most of the code is written in java, python, mathlab, lua, fortan, ada. I think only less than 10% of the code i touch is c++. But i guess it depends on where you work and in what area you work.
