Student here! Currently trying to learn how to create a programming language (maybe not from scratch, but at least with great tooling and stuffs) and your channel is really helping me see how other languages are working, and, if I finally start creating my own, what behavior I would like. Thanks again for your work! Subbed!
I really like the Wolfram Language. I know it's proprietary, but nothing else even comes close for working with data, visualization, complex transformations, etc. Very slow but accurate, powerful, and expressive!
In zig there's also some stdlib alternatives that allow you to do error handling on overflow/underflow in std.math, like add, sub, div, mul, which all return error unions instead of panicking. There's also mulWide, which returns an integer type which has enough bits to hold the largest values of both operands' types. Also also, there's "cast", which returns an optional for if the argument can't cast into the specified type without overflowing.
Subbed! Great video. I'm currently considering what to do in the fin language. It cares more about safety than speed (controlling vehicles) but also can't just panic. How to achieve and be ergonomic? Great info. Didn't know about new c23 features or c3 language. Cheers!
I'd say most of the times saturating is also a bad thing. Might even be worse because your program might not be acting as you expect it and it's hard to understand why (while in wrap-around it's usually a bit more obvious)
@@inkryption3386 I know I know, I'm arguing that I don't see any case where you'd want it. You might opt for it with the rationale "well, if things unexpectedly overflow, I want them to at least not be so different that they wrap around", and I'm saying that if that's the mindset, it seems to me like it's worse just because it will make the unexpected outcome's source harder to understand (possibly).
The Pony behavior is so much better than the one in Rust. I think, Rust shouldn't have any functions which panic by default anymore. Everything should return a result or similar. Especially after there is the question mark operator. Maybe in Rust 2 ;)
Doing this would force you to do unwrap or something else whenever you add two numbers. I think panicing at it only in debug mode is ok since you’re never going to publish in it
@@tjgdddfcn For some time I always compiled in Release mode since the compiliation time is not so much higher, but the runtime speed was a lot lower. So I published a few versions of some program which had this bug.
4:52 That might already be possible using generics. The underlying type won't be i127 anyway, but probably still a i128 in cases like these. Or the generic would use tuples for the inner types. Probably not viable in most programming languages. I don't think, the Rust generics are close to being powerful enough without a lot of repetition, maybe C++ templates and for sure one of the Scopes macros.
I am trying to use long long (guaranteed at least 64 bits) or int64_t everywhere for computation and parameter passing. The small overhead on 32-bit platforms can mostly be ignored, and you virtually never gonna get wrap-around problems. Its annoying that libraries insists on using unsigned for sizes, as *signed op unsigned* gives *unsigned* as result, which is unintuitive.
Makes sense. I have one project where I purposely using 32-bit ints because I *think* it's never going to be an issue for my use case, and then I get to store half the memory and make better use of cache for large arrays. But I have no idea if it will matter in performance in reality. Maybe if I get far enough, I can switch the typedefs to 64-bit and see if there's a noticeable difference.
well, people use unsigned for sizes because that's what they are. i still have to see a vector of length -4. this adheres to the principle "make impossible state unrepresentable"
You know, from my perspective its really funny to watch Software programmers struggling with variables overflow while I, a Firmware programmer, am so used to deal with variables and registers overflow from working with 8 or 16 bits MCUs that this kinda o thing is not even perceived as a problem to me anymore.
Also, in Python 3 and Ruby, I don't think bigints count as a separate type from smaller ints. Just a more efficient handling when they're small. I think Python 2 had a distinct "long" type for bigints, though, even if they added the automatic promotion at some point in the evolution.
Languages in a high-school drama... C++ : As always, you will never pay a cycle for ubsan and boost mp math when you're not using them even at compile time. Rust : I personally choose to buy a Volvo XC and I'm using it. Huh, You won't believe those people's cheap by default "philosophy". Duh! C++ : Why are you that angry all the time? Rust: I just hate hackers that keep selling gazillion zero-days and get rich quick, not you guys TBH. Zero-day: Don't look at me. Blame it on capitalism and free market. Communism: You see? That's why the people must be kept in a lockdown forever. They well deserve it. Communism Propaganda: Creating youtube news channels while suppressing press freedom under sovereignity are not related and not hypocrite at all. Be logical, guys.
@@inkryption3386 Exactly how propaganda is supposed to work in the mind. One must find Marx is never worse than the rest ever in every aspect. They are almost flawless to the subject so to speak. It's a sole reason to protect the party at any cost. That's simply logical to the subject.
@@JohnWilliams-gy5yc I think you're perhaps confusing authoritarianism with Marxism, and Marx with Stalin/Lenin. At any rate, the same shit happens in capitalism, people worship figures of authority, they're just not always state-sanctioned.
@@inkryption3386 Yeah, you're right. Marx can solely exists in reality without any forms of authoritarianism. How come I missed it. I'm sorry that I'm too confused to understand that facts. Your view is completely logical without any artificial influence. I'm impressed. Thanks for correcting me.
The biggest lie in systems languages like Rust/C++/Zig or anything using LLVM is that they're fast. Yes, you go fast by being inexact. Basically you're giving slightly wrong results, that's the magic of 'native' languages.
@@patryk_49 That's a cope isn't it? You're justifying the sacrifice in behavior of the computing environment. For example, weak memory models. And ironically most Undefined Behaviors are not defined, they're by omission. Some of them are what's called "implementation detail" The LLVM IR suffer less from that, but it also has its undefined behaviors like aliasing of memory pointers. Documenting a bug doesn't make it less of a bug in design. It's a matter of perspectives.
@@electric26 Because that's an implementation detail of IEE754. There are overflows, C++/LLVM IR pretend they don't exist. Why on earth would you disable overflow checking? It's a failure of abstraction. That's the lie. One of the lies C++ and native languages tells you. They are literally trading off precision for performance. They're not fast.
In Rust, you can also use the `Wrapping` type to get wrapping arithmetic with regular operators like `+`, `-` instead of using explicit method calls.
that's really cool, didn't know this one!
Student here! Currently trying to learn how to create a programming language (maybe not from scratch, but at least with great tooling and stuffs) and your channel is really helping me see how other languages are working, and, if I finally start creating my own, what behavior I would like.
Thanks again for your work! Subbed!
In C# there are keywords `checked` and `unchecked` to create a code region or wrap you expression with
I really like the Wolfram Language. I know it's proprietary, but nothing else even comes close for working with data, visualization, complex transformations, etc. Very slow but accurate, powerful, and expressive!
As an aside, while I didn't demo it, you can get specific bit sizes (and more) on your ints in C or C++ using stdint.
Also, here's the link to the C3 blog post shown in the video: c3.handmade.network/blog/p/7656-c3__handling_casts_and_overflows_part_1
@@vextechexcept that it isnt actually overflow proof and has caused thousands of exploits due to accidental rounding
In zig there's also some stdlib alternatives that allow you to do error handling on overflow/underflow in std.math, like add, sub, div, mul, which all return error unions instead of panicking. There's also mulWide, which returns an integer type which has enough bits to hold the largest values of both operands' types.
Also also, there's "cast", which returns an optional for if the argument can't cast into the specified type without overflowing.
also lossyCast which is a saturating cast, so lossyCast(u8, 300) → 255
there are also the compiler builtins of @addWithOverflow etc which allow you to check if an overflow happened at runtime
@@jobat_ yeah, the std.math functions are implemented in terms of them as appropriate.
Very interesting video as usual, Context Free.
You should do videos on concurrency models. Would love to see a comparison between Go, Elixir, and Clojure in this space.
Superb Channel. Thanks!
Subbed! Great video. I'm currently considering what to do in the fin language. It cares more about safety than speed (controlling vehicles) but also can't just panic. How to achieve and be ergonomic?
Great info. Didn't know about new c23 features or c3 language. Cheers!
Nice, you also mentioned C3.
Wow, I like the saturating operator in Zig!
It's perhaps one of my favorite niche and useful things that I didn't realize I needed
I agree, it's extremely useful.
I'd say most of the times saturating is also a bad thing. Might even be worse because your program might not be acting as you expect it and it's hard to understand why (while in wrap-around it's usually a bit more obvious)
@@carlosmspk how can it be a bad thing if it's the behaviour you want. It's not enabled by default, it's explicitly opt-in.
@@inkryption3386 I know I know, I'm arguing that I don't see any case where you'd want it. You might opt for it with the rationale "well, if things unexpectedly overflow, I want them to at least not be so different that they wrap around", and I'm saying that if that's the mindset, it seems to me like it's worse just because it will make the unexpected outcome's source harder to understand (possibly).
in BQN the ints would turn into floats automatically
The Pony behavior is so much better than the one in Rust. I think, Rust shouldn't have any functions which panic by default anymore. Everything should return a result or similar. Especially after there is the question mark operator. Maybe in Rust 2 ;)
Doing this would force you to do unwrap or something else whenever you add two numbers. I think panicing at it only in debug mode is ok since you’re never going to publish in it
@@tjgdddfcn For some time I always compiled in Release mode since the compiliation time is not so much higher, but the runtime speed was a lot lower. So I published a few versions of some program which had this bug.
I wonder the usefulness of having integers with, say, 37 bit size, instead of 64
Now what about how every language and calculator handles modulus differently?
What do you do when you get that secondary, negative remainder?
4:52 That might already be possible using generics. The underlying type won't be i127 anyway, but probably still a i128 in cases like these. Or the generic would use tuples for the inner types.
Probably not viable in most programming languages. I don't think, the Rust generics are close to being powerful enough without a lot of repetition, maybe C++ templates and for sure one of the Scopes macros.
I am trying to use long long (guaranteed at least 64 bits) or int64_t everywhere for computation and parameter passing. The small overhead on 32-bit platforms can mostly be ignored, and you virtually never gonna get wrap-around problems. Its annoying that libraries insists on using unsigned for sizes, as *signed op unsigned* gives *unsigned* as result, which is unintuitive.
Makes sense. I have one project where I purposely using 32-bit ints because I *think* it's never going to be an issue for my use case, and then I get to store half the memory and make better use of cache for large arrays. But I have no idea if it will matter in performance in reality. Maybe if I get far enough, I can switch the typedefs to 64-bit and see if there's a noticeable difference.
And I'm pretty convinced 16-bit is likely too small for my use case, which is why I'm sticking to 32 so far.
well, people use unsigned for sizes because that's what they are. i still have to see a vector of length -4. this adheres to the principle "make impossible state unrepresentable"
math would never
You know, from my perspective its really funny to watch Software programmers struggling with variables overflow while I, a Firmware programmer, am so used to deal with variables and registers overflow from working with 8 or 16 bits MCUs that this kinda o thing is not even perceived as a problem to me anymore.
4:50 that's exactly what dynamic languages like python and JS do... They increment the type if they sense overflow
Thanks for the comment! To clarify, I meant statically sized. As in i3 + i4 has static type i5, and functions could be generic in int size.
That's not true in JS, it uses 64-bit floats even for integer values and operations.
@@SolarLiner Good point as well. Bigints are a separate type in JS.
Also, in Python 3 and Ruby, I don't think bigints count as a separate type from smaller ints. Just a more efficient handling when they're small. I think Python 2 had a distinct "long" type for bigints, though, even if they added the automatic promotion at some point in the evolution.
try jakt
JS autofloat😎
Yeah, also wouldn't hit the limit so soon because more bits in mantissa.
what the hell is PONY?!
A small horse.
“Pony is an open-source, object-oriented, actor-model, capabilities-secure, high-performance programming language.” I like it a lot.
C solo neg diff
Languages in a high-school drama...
C++ : As always, you will never pay a cycle for ubsan and boost mp math when you're not using them even at compile time.
Rust : I personally choose to buy a Volvo XC and I'm using it. Huh, You won't believe those people's cheap by default "philosophy". Duh!
C++ : Why are you that angry all the time?
Rust: I just hate hackers that keep selling gazillion zero-days and get rich quick, not you guys TBH.
Zero-day: Don't look at me. Blame it on capitalism and free market.
Communism: You see? That's why the people must be kept in a lockdown forever. They well deserve it.
Communism Propaganda: Creating youtube news channels while suppressing press freedom under sovereignity are not related and not hypocrite at all. Be logical, guys.
I don't understand the latter criticism in this comment. That happens in both capitalist and communist societies lol.
@@inkryption3386 Exactly how propaganda is supposed to work in the mind. One must find Marx is never worse than the rest ever in every aspect. They are almost flawless to the subject so to speak. It's a sole reason to protect the party at any cost. That's simply logical to the subject.
@@JohnWilliams-gy5yc I think you're perhaps confusing authoritarianism with Marxism, and Marx with Stalin/Lenin. At any rate, the same shit happens in capitalism, people worship figures of authority, they're just not always state-sanctioned.
@@inkryption3386 Yeah, you're right. Marx can solely exists in reality without any forms of authoritarianism. How come I missed it. I'm sorry that I'm too confused to understand that facts. Your view is completely logical without any artificial influence. I'm impressed. Thanks for correcting me.
CZcams communism?? bro are you 8 years old?
The biggest lie in systems languages like Rust/C++/Zig or anything using LLVM is that they're fast.
Yes, you go fast by being inexact. Basically you're giving slightly wrong results, that's the magic of 'native' languages.
What do you mean by "wrong"? if something does what its documentation/specification says, it's not wrong.
So the lie isn't that they're fast, it's that they use native processing? Even Python has inaccurate floats.
@@patryk_49 That's a cope isn't it?
You're justifying the sacrifice in behavior of the computing environment.
For example, weak memory models.
And ironically most Undefined Behaviors are not defined, they're by omission. Some of them are what's called "implementation detail"
The LLVM IR suffer less from that, but it also has its undefined behaviors like aliasing of memory pointers.
Documenting a bug doesn't make it less of a bug in design.
It's a matter of perspectives.
@@electric26 Because that's an implementation detail of IEE754.
There are overflows, C++/LLVM IR pretend they don't exist.
Why on earth would you disable overflow checking?
It's a failure of abstraction.
That's the lie.
One of the lies C++ and native languages tells you.
They are literally trading off precision for performance. They're not fast.
@@monad_tcp what's ironic about undefined behaviours being undefined?