Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by cl333r View Post
    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?

    Comment


    • #22
      Originally posted by cybertraveler View Post

      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.

      Comment


      • #23
        Originally posted by cl333r View Post

        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 )

        Comment


        • #24
          Originally posted by moltonel View Post

          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.

          Comment


          • #25
            Originally posted by bug77 View Post

            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..
            Last edited by caligula; 01-18-2019, 10:51 AM.

            Comment


            • #26
              Originally posted by bug77 View Post

              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.

              Comment


              • #27
                Originally posted by ihatemichael
                Yes, I agree my first post was inflammatory on purpose, sorry.
                No need to apologize, Rust dummies deserve it.

                Comment


                • #28
                  Originally posted by cybertraveler View Post
                  • 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.

                  Originally posted by cybertraveler View Post
                  • 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.

                  Comment


                  • #29
                    Originally posted by Weasel View Post
                    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.

                    Comment


                    • #30
                      Originally posted by caligula View Post
                      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)?

                      Comment

                      Working...
                      X