101–110 of 227 posts
If you have been on the fence about learning Rust, I encourage you to dive in. It is very productive.
How is the build system? Is it stable and easy?
easy: far easier than gradle and maven, imho even easier than go. Definitely easier than cmake.
Earlier quoted context omitted.
I thing you are right about that, I'd prefer panicking too. Also, reading the RFC will surely clear up the motivation. Without knowing this case, I'd wager a guess: it's about performance. Panicking introduces a branch and side-effects which, again, affects negstively optimization potential and performance. The saturating cast affects performance too, but less. If some old code has a lot of number crunching containin…
It is't about performance because array indexing also panics.
I don't disagree that making more obvious errors into panics would be nice, but the performance implications are often quite unforgiving.
> Just like with array access, the compiler can often optimize the checks away, making the safe and unsafe versions equivalent when the compiler can prove it. Can it "often" solve the halting problem as well? The hope that this kind of optimization will happen sounds a bit fanciful for any non-trivial part of a program.
I ported a small C function to Rust recently that involved some looping, and all of the bounds checking was completely eliminated, even once I took the line-by-line port and turned it into a slightly higher level one with slices and iterators instead of pointer + length.
Earlier quoted context omitted.
Fortran predictably overflows the result, in contrast to fptoui which gives a poison value. I agree that even a predictable overflow can bite you on the behind. But it's better than undefined behavior. I'm not a fan of saturated cast, but having a defined behavior is for sure a great improvement.
When working with audio as an example, saturation is much less obnoxious than wraparound. You can potentially destroy speakers and your hearing that way.
Especially back in the 1980s and 1990s you'd get awful code that did things like averaging the two streams because wrapping sounds awful and the authors were ignorant of the theory and/or unaware that saturated addition is a thing.
You can tell when somebody did this because it means playing silence makes everything else quieter, or worse there's an arbitrary limit on how many streams are played and playing any one thing is very quiet because it's attenuated so as to never wrap.
Haiku the 1990s-style operating system did this for years, as did various Amiga music software.
By any chance if anyone is in the Paris area and is interested to teach Rust at university next year during the first semester. Please get in touch :).
Is this undergrad? Genuinely curious, how will you get someone to understand what ownership helps avoid without them having experienced the pain on the other side? I guess with younger and younger kids learning programming these, may be there can handle more? I am not sure if my son would understand all of the intricacies in his first semester.
Maybe the professor for this class could assign a non-trivial project in C at the start of the semester then the same project again at the end of the semester except in Rust.
I keep seeing more and more news about Rust, and figure that perhaps it is time that I learn something new. 99% of my development work these days is C with the target being Linux/ARM with a small-ish memory model. Think 64 or 128MB of DDR. Does this fit within Rust's world? I've noticed that stripped binary sizes for a simple "Hello, World!" example are significantly larger with Rust. Is this just the way things are…
Earlier quoted context omitted.
Sort of; we have more than nothing, but not a full thing. Some things are well specified. Some things are mostly specified. Some things are still very much up in the air.
Do you have specification of a memory model?
Earlier quoted context omitted.
That could literally produce no output program?
Yep! Dumb example. main() x = get_from_some_external_data_source() if x: print("Hello World") trigger_ub() You might expect this code to always print if x is true but the optimizer can look at this and say "welp, if x is true then it would trigger ub, therefore it must be false, and since x must always be false we can just remove that entire branch."
If you have been on the fence about learning Rust, I encourage you to dive in. It is very productive.
How is the build system? Is it stable and easy?