Nim is the best among all C++ Contenders if you look at feature interactions and productivity. Rust only if you have to prioritize large amount of safety for software that one way or the other can directly influence people's physical safety. A in depth comparison between Zig and Nim would be a video I truly enjoy.
It's really not about the best. It's about deciding on one thing and going with it so we can move on. Creating more languages that never gain traction is counter productive. Traction meaning real production use and qualifying for paid jobs.
@@origamibulldoser1618 Believe me both Zig and Nim are not new languages...so stability will not be much of an issue. Zig is surely going to gain a lot of traction after it gets to 1.0 as a C maintenance candidate. They have "maintain it with Zig" slogan and that's wat's gonna happen with C. It's going to go into maintanance mode while future development is going to be in Zig because it has already a much better build infrastructure than C itself for projects written in pure C. Nim is after C++ market share mostly and that will be more difficult since Rust exist there and a lot of cult following and hype is making people choose Rust quite often these days . Yes it has advantages but not for productivity or exploratory type programming. Rust is productive in the sense that the restrictive programming model forces you to make correct software from the start and that is going to be slower but you get overall productivity in the long term because you will have to deal with significantly less maintenance in the long run because the amount of bugs is way way lower than you would get from C++. If i was making safety critical software then yes I would also choose Rust. For everything else I would just choose Nim. In Nim you get much simpler language than both Rust and C++ and even D. so for exploratory and productive programming in a very fast language, Nim is the sweet spot because you get like 80% productivity from Python ,fast compile times and significantly faster feedback loop once the incremental compilation project they are currently focusing for Nim 2.0 will be finished and you can get almost dynamic language like feedback cycles because of the very fast incremental compilation added to an already very fast compiler. Once Nim finishes implementing proper incremental compilation, I don't see anymore a reason for people using Julia instead of Python. Nim will be a much better alternative. The popularity argument for finding jobs is a good argument if you just want to be hired. If you are your own boss, you don't care about that and can Use Nim and Zig because they are compelling for your use case because of providing just enough safety with increased productivity and modern features and build infrastructure. Of course, both Zig(if you're an expert in C or c++ you can probably learn the full Zig language and it's features in max a month.) and Nim also have the advantage of being simpler languages and you can master them together with your colleagues faster than attempting to do the same thing in Rust or Modern C++.
@@encapsulatio The point I was trying to make was it matters less which improvement on C++ we pick, so long as we pick one. :) I'm sure Nim is fine, rust is fine and zig is fine, to the extent that they solve the same things C++ does in terms of abstraction level (Rust I believe does not fill all of C++'s shoes)
WebAssembly is a language. You can code in it directly if you want. I gave it a try. It's not fun but you can. Similar to Java it's both a language and a VM. But it's a much lower-level language intended as a compile target, much like assembly language or machine code.
no one argued otherwise, it simply is not an assembly language, it's a bytecode and a virtual machine and it's not really coupled to the web it just so happens that that's where it's intended to run. but ig as with all things you can change your semantics and context and change how something is called in computer science
Interesting talk, but no-hidden control flow doesn't make reading the code easier at all. No sane people would say a.add(b.minus(h).multiply(d.divide(i.add(j))).add(e)).add(c.multiply(f.minus(g.divide(j)))) is easier to read than a + (b - h) * (d / (i + j)) + e + c * (f - g / j)... It may make understanding how the code is executed at low level easy to understand, or easier even to implement a compiler (wink wink) but not easier to understand what the programmer wants to achieve.
In all my years writing code I've written very few calculations as complex as that one. Maybe that use case is more common for you. I commend you for converting the whole thing to long form! I think the goal with zig is that overloading operators like you suggest can do hidden things under the hood. It doesn't make sense for a divide operator, /, to produce any side effects, but if I can overload the divide operator, then I can make it do anything! Write to a file, send a web request. Of course that's a contrived example, but zig's intention is to eliminate false assumptions programmers are making by reducing hidden control flow.
you can write that as you wrote in the more concise version in zig, no hidden control flow is not about writing verbose stuff like you did, it's about not hiding certain aspects of how the program works, like in C you never know whether a program will allocate memory internally, in zig you do cause it asks you for an allocator, in C you never know whether an overflow might happen, in zig you have ways to mitigate this, in C there are macros that will do very weird magic stuff and you might not know what's happening, in zig you have comptime, so there are no macros it's just functions evaluated at compile time and it's very easy to know what they're doing, this goes on and on
I live and breath JS/TS and I don't like getters and setters at all. If I have a logic as involved as your example, I will for sure give it a scope and use intermediate variables to document the process. Never will I do `((a.b) = c.[d.e])[f] = g.h`, invoking a bunch of getters and setters. It will be very concise to write, and in 2-3 years when someone else comes along and sees it, I will get tracked down and murdered by him.
Python Decimals are a pleasure to use, I work with financial applications and implementing formulas with it feels very natural and readable. I am usually able to send the Python code to the analysts and they usually can read it. That's only possible because Python has operator overload, a feature that's missing in so many languages.
Nim is the best among all C++ Contenders if you look at feature interactions and productivity. Rust only if you have to prioritize large amount of safety for software that one way or the other can directly influence people's physical safety.
A in depth comparison between Zig and Nim would be a video I truly enjoy.
It's really not about the best. It's about deciding on one thing and going with it so we can move on. Creating more languages that never gain traction is counter productive. Traction meaning real production use and qualifying for paid jobs.
@@origamibulldoser1618 Believe me both Zig and Nim are not new languages...so stability will not be much of an issue. Zig is surely going to gain a lot of traction after it gets to 1.0 as a C maintenance candidate. They have "maintain it with Zig" slogan and that's wat's gonna happen with C. It's going to go into maintanance mode while future development is going to be in Zig because it has already a much better build infrastructure than C itself for projects written in pure C.
Nim is after C++ market share mostly and that will be more difficult since Rust exist there and a lot of cult following and hype is making people choose Rust quite often these days .
Yes it has advantages but not for productivity or exploratory type programming.
Rust is productive in the sense that the restrictive programming model forces you to make correct software from the start and that is going to be slower but you get overall productivity in the long term because you will have to deal with significantly less maintenance in the long run because the amount of bugs is way way lower than you would get from C++.
If i was making safety critical software then yes I would also choose Rust.
For everything else I would just choose Nim.
In Nim you get much simpler language than both Rust and C++ and even D. so for exploratory and productive programming in a very fast language, Nim is the sweet spot because you get like 80% productivity from Python ,fast compile times and significantly faster feedback loop once the incremental compilation project they are currently focusing for Nim 2.0 will be finished and you can get almost dynamic language like feedback cycles because of the very fast incremental compilation added to an already very fast compiler.
Once Nim finishes implementing proper incremental compilation, I don't see anymore a reason for people using Julia instead of Python. Nim will be a much better alternative.
The popularity argument for finding jobs is a good argument if you just want to be hired.
If you are your own boss, you don't care about that and can Use Nim and Zig because they are compelling for your use case because of providing just enough safety with increased productivity and modern features and build infrastructure.
Of course, both Zig(if you're an expert in C or c++ you can probably learn the full Zig language and it's features in max a month.) and Nim also have the advantage of being simpler languages and you can master them together with your colleagues faster than attempting to do the same thing in Rust or Modern C++.
@@encapsulatio The point I was trying to make was it matters less which improvement on C++ we pick, so long as we pick one. :) I'm sure Nim is fine, rust is fine and zig is fine, to the extent that they solve the same things C++ does in terms of abstraction level (Rust I believe does not fill all of C++'s shoes)
WebAssembly is a language. You can code in it directly if you want. I gave it a try. It's not fun but you can. Similar to Java it's both a language and a VM. But it's a much lower-level language intended as a compile target, much like assembly language or machine code.
no one argued otherwise, it simply is not an assembly language, it's a bytecode and a virtual machine and it's not really coupled to the web it just so happens that that's where it's intended to run. but ig as with all things you can change your semantics and context and change how something is called in computer science
Excellent, thanks Rafal
Thanks!
Interesting talk, but no-hidden control flow doesn't make reading the code easier at all. No sane people would say a.add(b.minus(h).multiply(d.divide(i.add(j))).add(e)).add(c.multiply(f.minus(g.divide(j)))) is easier to read than a + (b - h) * (d / (i + j)) + e + c * (f - g / j)... It may make understanding how the code is executed at low level easy to understand, or easier even to implement a compiler (wink wink) but not easier to understand what the programmer wants to achieve.
Agree if you just need understand the idea, it will clear if you want to understand the program.
In all my years writing code I've written very few calculations as complex as that one. Maybe that use case is more common for you. I commend you for converting the whole thing to long form! I think the goal with zig is that overloading operators like you suggest can do hidden things under the hood. It doesn't make sense for a divide operator, /, to produce any side effects, but if I can overload the divide operator, then I can make it do anything! Write to a file, send a web request. Of course that's a contrived example, but zig's intention is to eliminate false assumptions programmers are making by reducing hidden control flow.
you can write that as you wrote in the more concise version in zig, no hidden control flow is not about writing verbose stuff like you did, it's about not hiding certain aspects of how the program works, like in C you never know whether a program will allocate memory internally, in zig you do cause it asks you for an allocator, in C you never know whether an overflow might happen, in zig you have ways to mitigate this, in C there are macros that will do very weird magic stuff and you might not know what's happening, in zig you have comptime, so there are no macros it's just functions evaluated at compile time and it's very easy to know what they're doing, this goes on and on
I live and breath JS/TS and I don't like getters and setters at all. If I have a logic as involved as your example, I will for sure give it a scope and use intermediate variables to document the process. Never will I do `((a.b) = c.[d.e])[f] = g.h`, invoking a bunch of getters and setters. It will be very concise to write, and in 2-3 years when someone else comes along and sees it, I will get tracked down and murdered by him.
Python Decimals are a pleasure to use, I work with financial applications and implementing formulas with it feels very natural and readable. I am usually able to send the Python code to the analysts and they usually can read it. That's only possible because Python has operator overload, a feature that's missing in so many languages.