it's lovely how people keep writing C for their C++ compiler and then complain about C++ safety. std::string is a prefectly safe string implementation with optional runtime checks, but for some reason on these talks people pretend it does not exist.
did you watch the talk? the speaker gave several reasons why they used zig instead of C, and it is easily interpreted how C++ fits into the same box C does on the points provided.
Ok but who wants to start a FOSS project in C++ in 2024 ? like really you are going to get all the 0.1x d1ckhead that try to be smart, and they will all argue pointlessly about the 30 different ways you can do it in C++ and how each ways differ slightly and impact performance in subtle ways, but that's all going to change in the next C++ release but actually is going to come back in the next next standard, because now your going to have the new my ass pointer combined with std::over_complicated_mess and what not, like it's pure misery just to imagine, like I'm not even advocating for Zig or Rust, and yes C++ can be a safe language, but not for people with a will to live happy. C++ is great on a small scale when you are on your own, or work with talented people, but almost all the FOSS project in C++ are dead, or they take forever to compile or ship features. Like no joke you can't contribute to LLVM, unless you have an AWS rack on your desk.
if you're saying that C++ is by design unsafe because it's backwards compatible with C, then zig is just as much unsafe because it's also just as compatible with C.
It's not the same C++ is just some makeup to make C look like it's a proper language, Zig is already a better language than C++. Zig can compile C/C++, it can link to it, and use it's calling convention and ABI to speak to it, but there is a strong type system in Zig that prevents a lot of the issues you get in C/C++. C++ does add some features and provides means to write safe code, but it's not enforced as much by the semantic because it has to basically also be somewhat of a superset of C. Zig or Rust don't have to concern themselves with being backward compatible, they just need to provide ways to interrops with the FFI of C/C++
@@pierreollivier1 did they add C++ interop to Zig? can it now compile std::map? i noticed a trend that whenever anybody mentions this mythical "C/C++" , means they have no idea what C++ actually is.
@@Alexander_Sannikov It’s literally my job to write C and unfortunately deal with C++ too, so yeah I know what it is it’s basically like typescript for javascript, they just put more random bs on top of it to make it look like your doing something important. And yes Zig does compile both C/C++ but to be honest they just use clang so it’s not like they wrote a compiler for it per say. They just use a modified clang and integrated it with their build system.
@@pierreollivier1 thats some bs right there, C++ is not just makup for C, modern c++ has evolved beyond that (modern as in c++23). And sure the unsafe stuff is there for backwards compatibility and there are 10 different ways to do the same thing again for backwards compatibility, but no one is forcing you to use those usafe or bad ways. You can always choose a modern and safe way of doing things in C++, just need to learn what's available.
He probably needs to bootstrap the languag, but wants to avoid bugs in the bootstrapped compiler. It took a decade or so before Microsoft was able to build a .Net compiler in C#. I don't build compilers, but I suspect it's very common to cobble together a few tools to bootstrap a language until it's mature before rewriting the compiler in the language of choice. I did try Linux from Scratch once and it's pretty similar where you bootstrap the system with some janky tools before building the production Linux system.
I think* I've seen another video where Richard said that he didn't have any plans to have Roc be self-hosting. I think he has a particular set of domains in mind within which he is design Roc to be a natural choice compilers just isn't one of them. * It's possible I'm confusing him with the Elm guy. I think it applies to both.
This all is to be determined with production use of zig, it is extremely skeptical that it would reach rust's safety and bug-free nature. Writing unsafe/safe mix code in rust is extremely hard, much harder than c/c++/zig but not sure if it is much harder than writing high quality code in c/c++/zig. So feels like people who say Rust is a pain in the a** for no good reason, or that it is limiting their productivity might not be right. All that being said, I have been writing production rust code for 6+ years now and I have grown to hate rust for writing high performance code over the years, maybe zig is the right way, but it seems very very unlikely because there is no borrow-checker/ownership and no real alternative
You met the concepts of ownership and borrowing when you hit that unfathomable garbled string bug in your game in C++ as a teenager. Only C++ does not know anything about that and did not help you,
(slightly off topic) I don't know why everyone keeps saying Zig is simple. Over the years I've done a bit of x86 assembly, C, Java, JS, Haskell and Lisp, and yet, there's just something about Zig that keeps on biting me because it never works the way I expect.
I think it is a competitive statement . Simple compared to c++ and rust. That said, zig is still young and changing. Overall, it has a pretty simple to learn core with less sharp edges than C.
How would you implement hardware primitives when targeting LLVM? You can either generate llvm bytecode directly or have an existing compiler do that for you. If it's something self-contained like floating point arithmetic and you want to do the same thing as zig, use zig.
We don't implement a float in zig. We do implement `Dec` in zig. That is a fixed point decimal type that is more useful for correctness of certain classes of code.
@@RiwenX yeah, well if you need to ask….. then you are probably already neck deep in the rust koolaide, so no amount of logical discussion will bring any light to the question
many people praise rust's "safety" until they realise that you can't do anything without unsafe code and their unsafe code is full of UB. Rust has a very good marketing team... it's all those people who can't call free after a malloc and check for boundaries... and they are a lot.
I'm not one to gatekeep but if you legitimately "can't do anything without unsafe" in rust then you probably don't know how to program in the language lol hard to blame that on the tool itself!
@@mikkelensI agree with that. When I see an "unsafe" call in a rust project I always think "hey, look at this idiot, he is using the wrong tool", then I look at the rust standard library, it's also ridden with unsafe calls, then I look 99.997% of the rust projects and every single one of them is polluted with unsafe, and most of the time UB code. Me? I do everything safe, years of experience, know my tools, valgrind, gdb, cppcheck, perf, μUnit, etc. It's those damn rust idiots who paint their unsafe garbage as safe and they can't even finish a project without creating unsafe code. If I was CTO or something and I saw some idiots calling unsafe, I'd fire them on the spot. unsafe rust belongs to garbage. use the tool correctly or you are using the wrong tool.
@@anonymousalexander6005 Unsafe Rust is ridden with UB, so on top of the regular tools, you have to add Miri and then satisfy Miri for your code to get analyzed. C's UB is not because the language or the standard didn't bother to define it, but it's because it is platform specific. In C, no matter what you do, will run on all those hundreds of tools that are out there and they can tell you what went wrong or not. Some of them are platform specific or from platform vendors and check UB. Even safe Rust is unsafe, as there is safe Rust code out there producing segfaults. When you are part of a religion, facts don't matter, what matters is that you believe it's safe, therefore it's safe.
@@mikkelens I've read multiple blog posts/saw videos that as soon as you do something that goes against the borrow checker as a principle (global object cache, "safe" multithreading meaning you know it's safe, but BC doesn't know that), unsafe Rust in a pain in the butt. Replacing those ugly unsafe parts with Zig makes sense
there is a whole bunch of correct programs that are not possible to be written in safe Rust. Unsafe Rust sucks balls. So if you want to write one of those, you would replace unsafe Rust with Zig or Odin, and voila, it works :) Good example would be the most famous unsafe algo - fast inverse square root from Quake engine. Look it up :)
love his "2x video speed" energy
Watching at faster speed to get 6x speed energy 😅
Fantastic that you’ve put this online!!
😅 I like how this was NOT a talk about Roc lang. 😂
Zig 🤝 Rust
Rust and Zig might be the new C++ and C (rust is not to zig what c++ is to c) to continue their legacy to further
Do you mean rust and zig combined is the future?
@@AyushVachhani yep zig gives you full control where as rust gives many feature and make you do things its way just kind of like c c++
@@ulrich-tonmoy nice take.
If I understand correctly what was done, it was moving the "unsafe" Rust code from the core compiler to zig addon. Like with nodejs/etc and FFI.
This talk has been featured in the last issue of Tech Talks Weekly newsletter 🎉 Congrats!
rust + zig = rig
zist
Rustig
rust + zig = rust + #![feature(allocator_api)]
rug
it's lovely how people keep writing C for their C++ compiler and then complain about C++ safety. std::string is a prefectly safe string implementation with optional runtime checks, but for some reason on these talks people pretend it does not exist.
thank you
and also many other features of modern C++ that make it muuuuuch safer (smart pointers etc)
did you watch the talk? the speaker gave several reasons why they used zig instead of C, and it is easily interpreted how C++ fits into the same box C does on the points provided.
Ok but who wants to start a FOSS project in C++ in 2024 ? like really you are going to get all the 0.1x d1ckhead that try to be smart, and they will all argue pointlessly about the 30 different ways you can do it in C++ and how each ways differ slightly and impact performance in subtle ways, but that's all going to change in the next C++ release but actually is going to come back in the next next standard, because now your going to have the new my ass pointer combined with std::over_complicated_mess and what not, like it's pure misery just to imagine, like I'm not even advocating for Zig or Rust, and yes C++ can be a safe language, but not for people with a will to live happy. C++ is great on a small scale when you are on your own, or work with talented people, but almost all the FOSS project in C++ are dead, or they take forever to compile or ship features. Like no joke you can't contribute to LLVM, unless you have an AWS rack on your desk.
@@RustIsWinning can't wait for it lol
Looking forward to this talk 🔥
sometimes running into problems is the problem. It means the road is less traveled or even unpaved.
7:30 Elm mentioned!
@@Solid_Fuel "The name is... elm mentioned!"
if you're saying that C++ is by design unsafe because it's backwards compatible with C, then zig is just as much unsafe because it's also just as compatible with C.
Yeah and it is
It's not the same C++ is just some makeup to make C look like it's a proper language, Zig is already a better language than C++. Zig can compile C/C++, it can link to it, and use it's calling convention and ABI to speak to it, but there is a strong type system in Zig that prevents a lot of the issues you get in C/C++. C++ does add some features and provides means to write safe code, but it's not enforced as much by the semantic because it has to basically also be somewhat of a superset of C. Zig or Rust don't have to concern themselves with being backward compatible, they just need to provide ways to interrops with the FFI of C/C++
@@pierreollivier1 did they add C++ interop to Zig? can it now compile std::map?
i noticed a trend that whenever anybody mentions this mythical "C/C++" , means they have no idea what C++ actually is.
@@Alexander_Sannikov It’s literally my job to write C and unfortunately deal with C++ too, so yeah I know what it is it’s basically like typescript for javascript, they just put more random bs on top of it to make it look like your doing something important. And yes Zig does compile both C/C++ but to be honest they just use clang so it’s not like they wrote a compiler for it per say. They just use a modified clang and integrated it with their build system.
@@pierreollivier1 thats some bs right there, C++ is not just makup for C, modern c++ has evolved beyond that (modern as in c++23). And sure the unsafe stuff is there for backwards compatibility and there are 10 different ways to do the same thing again for backwards compatibility, but no one is forcing you to use those usafe or bad ways. You can always choose a modern and safe way of doing things in C++, just need to learn what's available.
He probably needs to bootstrap the languag, but wants to avoid bugs in the bootstrapped compiler. It took a decade or so before Microsoft was able to build a .Net compiler in C#. I don't build compilers, but I suspect it's very common to cobble together a few tools to bootstrap a language until it's mature before rewriting the compiler in the language of choice. I did try Linux from Scratch once and it's pretty similar where you bootstrap the system with some janky tools before building the production Linux system.
I think* I've seen another video where Richard said that he didn't have any plans to have Roc be self-hosting. I think he has a particular set of domains in mind within which he is design Roc to be a natural choice compilers just isn't one of them.
* It's possible I'm confusing him with the Elm guy. I think it applies to both.
Roc has no plans to self host. Rust is a correct language for the compiler. Zig would be another great choice. Roc isn't the right choice.
This all is to be determined with production use of zig, it is extremely skeptical that it would reach rust's safety and bug-free nature.
Writing unsafe/safe mix code in rust is extremely hard, much harder than c/c++/zig but not sure if it is much harder than writing high quality code in c/c++/zig. So feels like people who say Rust is a pain in the a** for no good reason, or that it is limiting their productivity might not be right.
All that being said, I have been writing production rust code for 6+ years now and I have grown to hate rust for writing high performance code over the years, maybe zig is the right way, but it seems very very unlikely because there is no borrow-checker/ownership and no real alternative
@@ozgurakkurt9770 Just curious, why do you hate it? Is it for high performance code specifically? What language do you prefer?
You met the concepts of ownership and borrowing when you hit that unfathomable garbled string bug in your game in C++ as a teenager. Only C++ does not know anything about that and did not help you,
(slightly off topic) I don't know why everyone keeps saying Zig is simple. Over the years I've done a bit of x86 assembly, C, Java, JS, Haskell and Lisp, and yet, there's just something about Zig that keeps on biting me because it never works the way I expect.
I think it is a competitive statement
. Simple compared to c++ and rust. That said, zig is still young and changing. Overall, it has a pretty simple to learn core with less sharp edges than C.
i just checked the repo for the roc compiler… Why is there a float implementation in zig? isn’t it supposed to be a hardware primitive?
How would you implement hardware primitives when targeting LLVM?
You can either generate llvm bytecode directly or have an existing compiler do that for you.
If it's something self-contained like floating point arithmetic and you want to do the same thing as zig, use zig.
We don't implement a float in zig. We do implement `Dec` in zig. That is a fixed point decimal type that is more useful for correctness of certain classes of code.
Is the video speeded up? lol
I've seen this video before. Why is it now 3 days ago??? Anz it's at 2x. Anyway nice talk
Heaven and Hell ;)
Which one is which?
@@RiwenX yeah, well if you need to ask….. then you are probably already neck deep in the rust koolaide, so no amount of logical discussion will bring any light to the question
@@steveoc64 In all fairness that's just projection. You sound like a cultist
@@steveoc64Hey, I just wanna know your opinion.
@@steveoc64 Oh wow, what a well reasoned point. Definitely doesn't make you look like an absolute tool
many people praise rust's "safety" until they realise that you can't do anything without unsafe code and their unsafe code is full of UB.
Rust has a very good marketing team... it's all those people who can't call free after a malloc and check for boundaries... and they are a lot.
I'm not one to gatekeep but if you legitimately "can't do anything without unsafe" in rust then you probably don't know how to program in the language lol
hard to blame that on the tool itself!
@@mikkelensI agree with that. When I see an "unsafe" call in a rust project I always think "hey, look at this idiot, he is using the wrong tool", then I look at the rust standard library, it's also ridden with unsafe calls, then I look 99.997% of the rust projects and every single one of them is polluted with unsafe, and most of the time UB code.
Me? I do everything safe, years of experience, know my tools, valgrind, gdb, cppcheck, perf, μUnit, etc. It's those damn rust idiots who paint their unsafe garbage as safe and they can't even finish a project without creating unsafe code.
If I was CTO or something and I saw some idiots calling unsafe, I'd fire them on the spot. unsafe rust belongs to garbage.
use the tool correctly or you are using the wrong tool.
@@mikkelens his skill isues.
@@anonymousalexander6005 Unsafe Rust is ridden with UB, so on top of the regular tools, you have to add Miri and then satisfy Miri for your code to get analyzed.
C's UB is not because the language or the standard didn't bother to define it, but it's because it is platform specific.
In C, no matter what you do, will run on all those hundreds of tools that are out there and they can tell you what went wrong or not. Some of them are platform specific or from platform vendors and check UB.
Even safe Rust is unsafe, as there is safe Rust code out there producing segfaults.
When you are part of a religion, facts don't matter, what matters is that you believe it's safe, therefore it's safe.
@@mikkelens I've read multiple blog posts/saw videos that as soon as you do something that goes against the borrow checker as a principle (global object cache, "safe" multithreading meaning you know it's safe, but BC doesn't know that), unsafe Rust in a pain in the butt.
Replacing those ugly unsafe parts with Zig makes sense
TLDR a dude tried to cut corners while building a new programming language and ended up having to use two new languages. Jesus...
A yes, rust, the language you use when you want to cut corners.
Why tf would anyone combine Rust and Zig. Are we that bored? *Are we trying to solve problems or sing Kumbaya?*
There's actually a nice talk about exactly that question. GoThere Composiums or something like that
@@maxmustermann5590Can't find the talk anywhere. Where is it exactly?
@@SimGunther your browser built a special keyboard shortcut just for the talk, you can press F5 and it will instantly take you there
there is a whole bunch of correct programs that are not possible to be written in safe Rust. Unsafe Rust sucks balls.
So if you want to write one of those, you would replace unsafe Rust with Zig or Odin, and voila, it works :) Good example would be the most famous unsafe algo - fast inverse square root from Quake engine. Look it up :)