Rust 1.32 Released With New Debugger Macro, Jemalloc Disabled By Default

[cybertraveler]

Personally I'd switch to Swift if it was properly supported on Linux and Windows.

I've been looking at Swift a bit. It looks really nice. It looks like it has some of the safety features of Rust and is easier to read. So it's somewhere inbetween C and Rust.

What is drawing you towards Swift?

[cl333r]

I've been looking at Swift a bit. It looks really nice. It looks like it has some of the safety features of Rust and is easier to read. So it's somewhere inbetween C and Rust.

What is drawing you towards Swift?

That it's about 30 years younger and doesn't have the legacy cruft of C++. It's basically Rust without ownership, but because it's only well supported on OSX I'm not moving to it but would consider if otherwise. And would also dump Rust in favor of Swift cause I consider its ownership a negative trade-off because I don't write software demanding such high security.

[cybertraveler]

That it's about 30 years younger and doesn't have the legacy cruft of C++. It's basically Rust without ownership, but because it's only well supported on OSX I'm not moving to it but would consider if otherwise. And would also dump Rust in favor of Swift cause I consider its ownership a negative trade-off because I don't write software demanding such high security.

I think we are of similar minds about this.

Checkout some of the nice Swift safety features:

• Assignments don't return a value. This helps avoid errors where you accidently write the assignment x = 1 when you meant to perform the test x == 1.
• It has optionals to help avoid null pointer exceptions. IE you can tell Swift whether it should allow an integer to be set to null (AKA nil) or not. The syntax for managing this is quite nice IMO.
• Signed integer overflows result in run time errors rather than undefined behaviour (as they do in ISO C). Practically speaking, I think this can be somewhat mitigated already in C using GCC options: -ftrapv and -fwrapv (details here: https://gcc.gnu.org/onlinedocs/gcc-4...n-Options.html )

[bug77]

191K vs 415K for a stripped release build (so no fancy size-reduction technique) of an unmodified `cargo new helloworld`, on my Linux amd64 system.

While it's still a big hello-world, a 54% size reduction is impressive. But hello world isn't a realistic usecase, rust programs quickly get much bigger than that. My pet rust log-parsing program 'emlop' already weighs 2140k, making jemalloc's 220K less significant.

Stripping down debug symbols sheds a lot weight as well.

[caligula]

If it didn't deprecate (and eventually remove) what's not working, it'd end up like Java that carries AWT, Swing, Vector and whatnot into 2019.

If I understood correctly, in Java the functionality is located modules since Java 9 or so. You can link with only those you use. Not sure how much this helps, but at least you might be able to work without AWT and Swing. Vector is just a single class..

[moltonel]

Stripping down debug symbols sheds a lot weight as well.

Goes down to 159k using "debug = false, debug-assertions = false, codegen-units = 1, incremental = false, lto = true, panic = abort, opt-level = z". I wouldn't recommend these settings for all cases, but they are stable and reasonable if executable size is important.

One rust change that has a good potential to improve executable size (and performance) is compiling intermediate objectss (including the stdlib) to miri instead of native. But that's a long-term RFC.

[Weasel]

Yes, I agree my first post was inflammatory on purpose, sorry.

No need to apologize, Rust dummies deserve it.

[Weasel]

• Assignments don't return a value. This helps avoid errors where you accidently write the assignment x = 1 when you meant to perform the test x == 1.

Is this really a thing? An issue? Even if you make such an obvious mistake, compiler will warn you about it. I don't see the problem and it's obvious as fuck.

• Signed integer overflows result in run time errors rather than undefined behaviour (as they do in ISO C). Practically speaking, I think this can be somewhat mitigated already in C using GCC options: -ftrapv and -fwrapv (details here: https://gcc.gnu.org/onlinedocs/gcc-4...n-Options.html )

Cool, more pointless overhead in 99% of calculations that don't need it, array bounds checks just weren't enough.

[caligula]

Is this really a thing? An issue? Even if you make such an obvious mistake, compiler will warn you about it. I don't see the problem and it's obvious as fuck.

Not everyone has the privilege to use latest modern compilers. Take an embedded environment that's stuck with gcc 2 or 3 (was common few years ago). Now the general guideline was to compare in a way that the rvalue is on the left hand side. So e.g. 1 == x. Now if you make a mistake and type 1 = x, it won't compile. I'm not sure about the status of the NDA so can't paste the code style guide here. Many juniors also do this on purpose cause they don't know the difference. I think it's better to use languages where assignment doesn't yield a return value. That's a code smell anyways.

[cybertraveler]

Not everyone has the privilege to use latest modern compilers. Take an embedded environment that's stuck with gcc 2 or 3 (was common few years ago). Now the general guideline was to compare in a way that the rvalue is on the left hand side. So e.g. 1 == x. Now if you make a mistake and type 1 = x, it won't compile. I'm not sure about the status of the NDA so can't paste the code style guide here. Many juniors also do this on purpose cause they don't know the difference. I think it's better to use languages where assignment doesn't yield a return value. That's a code smell anyways.

Do you know if there is a practical benefit to C's design here (assignment yielding a return value)?