9 ms·

In this regard Go has been the exact opposite of Rust.

• diarrhea 4y ago
  Isn’t the Rust DX pretty good still?
  • akmittal 4y ago
    Rust has very long compile time compared to Go
    • dgunay 4y ago
      Rust could also have shorter compile times, if it gave up on a lot of the optimizations and features it currently does.
      • eptcyka 4y ago
        A massive source of compilation pain is that Rust just generally generates a lot of code - it always prefers specialization over dynamic dispatch unless the source specificies dynamic dispatch. Couple this with a culture of believing dynamic dispatch is always worse and lots of codegen for generics and you get one hell of a task for your linter. I wouldn't call this an optimization, but rather an almost cultural design decision.
        • orf 4y ago
          It’s more correct to say that it always prefers zero-cost abstractions. Defaulting to dynamic dispatch would go very much against this, even if in some cases it’s not a bad idea.
          • vlovich123 4y ago
            Most of the code is cold. Spending compile time on that probably isn’t worth it. As such it’s not a zero cost abstraction (yes yes - it normally means runtime but still - developer time is important too and that’s where the trade off is). In most cases static dispatch is faster. In many cases dynamic dispatch can be just as fast (speculation by CPU negates the cost) and in some cases it can be faster (better code density). This 0-cost abstraction principle from c++ is actively harmful because there’s almost no such thing. Performance is such a subtle thing that what’s 0-cost in one scenario is a non 0 cost in others. Also spending compile time on the “dark matter” of code that’s rarely executed is probably not the best way to spend the developer time budget. I want CI to generate fully optimal code for production in release builds. For running tests in presubmit, I probably want a little bit less optimization. For local development I want it to be just fast enough that compile times are quick and I can iterate quickly (except for the cases I’m tuning performance in which case I have no choice but to spend max compilation time).
            • jeffbee 4y ago
              I strongly doubt that endless fields of cold/dead code are zero-cost, without profile guidance and link-time optimization.
              • morelisp 4y ago
                One of my favorite go-to examples for this is "Producing Wrong Data Without Doing Anything Obviously Wrong!" 4.2 where they demonstrate a reproducible >30% performance difference just by "misaligning" stacks with an unused environment variable. That's in the context of unexpected measurement bias, but you won't convince me piles of cold code can't affect memory layout less than that.
              • vlovich123 4y ago
                I think we’re in agreement. Did you misread what I wrote or did I say/imply the opposite somehow?
            • orf 4y ago
              I agree, but what you are asking is impossible in the general case. The compiler can’t know what is hot and cold without PGO, and doing dynamic dispatch in development to speed up compilation seems iffy. Surely a better approach is to use incremental compilation, and only do this expensive stuff potentially only once? However I do agree with your overall point - dev compilation in rust is too slow.
        • pjmlp 4y ago
          Meanwhile OCaml and Haskell provide interpreters and REPL to ease the whole development experience. Nothing prevents Rust of doing the same, other than resources.
          • LoganDark 4y ago
            evcxr does provide a hacky Rust REPL implementation: https://github.com/evcxr/evcxr https://github.com/evcxr/evcxr -Emily
            • eptcyka 4y ago
              Yes, but said REPL just wraps user entered expressions itno a function body and then compiles them to a shared object via cargo - thus the language is interpreted via the slow compiler anyway.
              • LoganDark 4y ago
                I said hacky, and also parent was talking about the lack of a REPL, not the speed of one. -Emily
        • foldr 4y ago
          >and you get one hell of a task for your linter Did you mean 'linker' here?
          • eptcyka 4y ago
            Yes.
• bsaul 4y ago
  I think the main problem with rust, is that the things they decided to settle on early on (aka the borrow checker) are the ones at the root of all the difficulties. They then tried to tame those issues little by little by improving the language ergonomics. This is pretty different from swift for example. Which had a sane basis very early on, but decided to expand the language by adding features over features, moving the language to a lot of different directions, turning it into an ugly beast ( i still like it though, but i’m not sure for how long).
  • mdavidn 4y ago
    Learning to work with Rust's borrow checker leaves one with the sinking realization that every C program also has a borrow checker: The very fallible programmer.
    • microtonal 4y ago
      Not just C, any language with mutable aliases references/pointers, which is pretty much every modern language. https://blog.polybdenum.com/2023/03/05/fixing-the-next-10-000-aliasing-bugs.html https://blog.polybdenum.com/2023/03/05/fixing-the-next-10-00...
      • eru 4y ago
        Well, Haskell has mutable aliases, references and pointers. But you seldom use them.
        • pdimitar 4y ago
          At this point in history it should be more or less apparent that "here's a gun you can shoot your foot with, just don't do it lol" is not a viable strategy. It's the strategy of the C devs whose memory safety bugs and buffer overflow mistakes we still find to this day, in a number of popular and very widely used programs. ...Nah. We shouldn't go back (and I am not saying you claim so, I am kind of just developing the thought here). Let's have memory safety and algebraic data types and maybe pluggable GC runtimes (if lifetime management proves too difficult which it has at times; not every task is perfectly suited for Rust's borrow checker) and async, and any other goodies that help us solve real problems, and let's not dream of a simpler life. That "simpler life" has failed. We should acknowledge that and move on and work with the reality in front of us. Rust's lifetime management and async runtime(s) can be maddeningly difficult but after being on all parts of the spectrum -- from bash scripts and JS Wild West projects to Rust -- I confidently claim that the more strictness the better. ...Though I wouldn't refuse Rust having compile times like those of Golang and OCaml, can't deny it.