Comments by "" (@pierreollivier1) on "NDC Conferences" channel.

  1.  @dmdjt  Be careful, with all that logic, the "Skill issues" folks are going to come here and say that C++ is perfect and easy and that the sole reason why you want another language is because of "Skill issues". When in reality C++ is the absolute worst programming language in existence (in terms of design). It's so bad, that it's a text book example for pl designer of what not to do. I think the reason so many people are fighting tooth and nails to defend C++ is because of all those years they have invested in learning things that are not transferable to other language. Programming is already hard, but on top of that when you master C++ there is not much you can transfer to another language. Because debugging C++ is 20% debugging your logic, 80% debugging your language knowledge. That's unlike any other language out there. This is an undeniable proof of poor design, if C++ was correctly designed you would spend most of your time debugging logical errors, but no instead you have to remember that this overload, does this but this one is slightly different, oh and this is not a function but actually a macro, and this template will produce this type, but not if it's a reference, or a universal reference, and the forwarding doesn't work if you do that, which means this template 20 function down the road, uses this overload instead of this one, but now because of the casting rules you get this instead of that, how but this lambda is actually doing that instead of this. It's just an incredible mess, where you are constantly triggering UB if you are not careful, where Error handling is really hard to achieve, and where all the "Zero Cost" abstractions actually have a big cost, outside of the iterator, all those smart-pointers aren't cheap in the slightest. And they also have their own quirks and logic that you have to remember and this creates just an exponential amount of cognitive load, but people will still say "skill issue" but I'm sorry if your language requires 20y of experience, before it becomes easily usable, it's a language problem not a skill problem.
    10
  2. Zig would be a great replacement for C++.
    7
  3.  @SVVV97  none of the languages mentioned are safe either. There is no such things as "safe software" what's important is the tooling, and the discipline, better languages helps regardless of whether they are interpreted by a jit, or have a borrow checker. I would consider Zig safer than a lot of "safe" languages, because it's very simple in the sense you can inspect and test everything. I would still use Rust for something that needs to be safe imperatively, but it's not bulletproof far from that.
    6
  4.  @testtest-qm7cj  That's true, but the real problem with C is simply that it's type system is non-existent, that compilers defaults are terrible, and although UB existed and was used for a reason, There is no reason why modern languages should not actually defined those UB. On top of that the tooling around C is bad, making it even harder to actually make safe code. This is why Rust is so awesome, it provides a strong type system, a powerful suit of static analysis tools through the borrow checker / lifetime annotation system. The defaults in Rust are sane defaults. But the things I've just mentioned are not something unique to Rust, what they are at their core is good tools. Which is why I think Zig is actually a very safe language too, it's not as safe as Rust that's for sure. But it doesn't need a borrow checker and static lifetime annotations to get there. What Zig needs to reach Rust level of safety is simply to provide the tools to ensure that the code is correct and safe. Because the true measure of a language safety potential is not just that it can be safe. C code can be made as safe as Rust, same goes with C++ or Assembly, the reason they are not considered safe, is simply because there is very few tools inside or outside those languages to ensure correctness and safety, and their defaults assumptions are also terrible. Which means that realistically to make safe and correct code in those languages you have to invest a ton more time into proper infrastructure, testing, etc. Which is tedious and means you can't ship as fast, so most companies simply skipped this part. But Zig already provides a lot of tools to ensure safety and correctness, and more importantly those tools are very easy to use and they fit perfectly with the language, if you add that Zig is very strongly typed, and comes with the sanest defaults, has very simple syntax/semantic, provides unit testing, fuzzy testing, has allocators which provides protections against, double free, use after free, protection against any UB because Zig doesn't accept any UB. You end up with a mix where it's actually quite hard to make unsafe code out of the box. It's not perfect and it will improve in the future. But the point is simply that Yes with Rust you are 99% guaranteed that the code you wrote is valid and safe. And with Zig it might be only 80%, but because of every tools provided and how easy they are to use, ironing out the last 20% is actually quite easy. So in practice you can expect safer code than C despite the fact that both languages are relatively similar. Because again safety is not a feature of a language itself, it's a feature of the tools the language comes with to ensure safety (compiler, fuzzer, unit testing, memory sanitizers, sane defaults, not allowing UB to be used by the compiler, bound checking, protection against use after free, double free, use of uninitialized memory, use of null pointer etc.)
    2
  5.  KushLemon  I'm not placing it in the same category, I'm just saying Zig is the only low level language which will be able to achieve Rust safety guarantees in practice with some effort. So it's not as safe as Rust out of the box, but with the tooling provided you can prove your code is safe. Because all Rust does is simply provide a language, that can only be used through the tooling proving its safety. Zig provides the tools, but doesn't enforce that you use them. Which is simply a different approach, but you still have the tools to make it safe.
    2
  6.  @dmdjt  yes this is just brushing the surface of the pain points with C++. This is just the tip of the iceberg.
    1
  7.  @eransabala9564  Exactly, and we are still lacking basic modules, like we got std::identity before we got, std::AddressV4, or std::Socket, like wtf, why are we missing a network module, but we have the most useless crap in every part of the std. It really doesn't make any sense.
    1
  8.  @testtest-qm7cj  Having said that if I were to make some code where I need to be 100% it's safe, I would indeed be more confident to achieve that in Rust. But unlike C I wouldn't discard Zig to achieve that goal, it would probably require some thinking ahead and some really good testing (unit testing, fuzzing, simulation, etc etc) but it's not that hard to get there, and so unlike C it would be reasonable to achieve that goal in a timely manner. Because again that's the main reason C isn't considered safe, it's not because it can't be safe it's simply because it can't be achieved in a timely manner in most scenarios.
    1
  9.  @AGeekTragedy  Oh for sure, I wouldn't consider it as Safe as Rust. But my point is simply to say That 1) Rust isn't 100% safe, and 2) Zig can realistically be used to make software that you can prove to be safe with tooling provided by the language, in a reasonable amount of time.
    1
  10.  KushLemon  Also just for context, I work in the defense industry in Europe and my job is literally to rewrite some of our C/C++ code to Zig right now. And I have some real world experience, I'm also proficient in Rust, and I was free to choose which stack I wanted, I rewrote the networking stack to Rust because it has to be safe, but the rest of it I wrote it in Zig, because it's hard real time performance. The code is well tested, I've made a dedicated simulator which is able to simulate thousands of years worth of CPU, and I use the fuzzing tester provided by Zig too, which is able to also provide thousands of random inputs concurrently, which in turns allow you to generate, test coverage. The "safety" is actually doable in a very reasonable amount of time, and I know it because I've done it.
    1
  11.  @toby9999  True but the point is C++ doesn't help you at all, I'm a C++ developer so you can say skill issue if you want, my point still stand, making fast and correct C++ all the while keeping a maintainable and extendable code base is hard. Sure it's hard in any language, but C++ doesn't help you at all, It's error prone, super slow to compile, terrible tooling, defaults, I rewrote part of our stack from one project to Zig, took me no time, the code base size has reduced, trivial to build, cross-platform, trivial to test and ensure it works correctly, can it be done in C++ sure, did it make sense to make it in C++ ? no. It's not rocket science, management asked me to try to rewrite it, I did it, it passes with flying colors, offers more out of the box, and it's easier to work with, mind you I was pretty much the only one who knew Zig at the time, and everyone around me are C/C++ embedded developers, they are not your average JS kiddo, yet they all find it better and easier to work with.
    1