7 ms·

All this has been known in the PL design community for decades if not half a century by now. Two things are incredibly frustrating when it comes to safety in s

• Ygg2 1y ago
  > I like that Rust can pick good concepts and design coherent language from them without inventing its own "pragmatic" solution that breaks horribly in some use cases that some "practitioners" deem "too theoretical." I've thought Rust picked some pretty nifty middle ground. On one side, it's not mindfucking unsafe like C. It picked to remove a set of problems like memory safety. On the other side, Rust didn't go for the highest of theoretical grounds. It's not guaranteeing much outside of it, and it also relies a bit on human help (unsafe blocks).
  • eptcyka 1y ago
    As per the article, Rust has benefits beyond the ones afforded by the borrow checker.
    • Ygg2 1y ago
      Sure, but it is pragmatic in other ways as well :) It takes ADT, but not function currying, and so on.
      • jeffparsons 1y ago
        I've occasionally wondered about the lack of currying in Rust; it feels like something that can be done mechanically at compile time, so why not support it? Perhaps to do it cleanly (without more magical privileged functions in core) would require variadic generics?
        • bunderbunder 1y ago
          You can absolutely curry functions in Rust. You just have to do it manually because there's no syntactic sugar for it. I think that's a good thing. A curried function is a function that takes one argument, and returns a closure that captures the argument. That closure might itself take another argument, and return a new closure that captures both the original argument and the second one. And so on ad infinitum. How ownership and borrowing works across that chain of closures could easily become a touchy issue, so you probably want to be making it as explicit as possible. Or perhaps better yet, find an easier way to accomplish the same task. Maybe use a struct to explicitly carry the arguments along until you're ready to call the function.
        • skybrian 1y ago
          This isn’t Rust-specific, but one reason a language designer might deliberately not implement currying is that it makes function call sites a bit harder to read. You need to already know how many arguments a function takes to make sense of the call’s return type.
        • int_19h 1y ago
          Currying is just syntactic sugar for a lambda that binds the first argument and passes the rest unchanged, and you can achieve the same level of conciseness in other ways - e.g. "pipeline" operators - but with a syntax that is more readable and more extensible. E.g. https://docs.rs/piping/latest/piping/ https://docs.rs/piping/latest/piping/
      • andrepd 1y ago
        I don't think currying is that big a deal, it's just syntactic sugar that might or might not make things easier to read, unlike ADTs or closures which are important core concepts. I'd love to have a syntax like { foo(%1, bar) } standing for |x| { foo(x, bar) } though. I'm not aware of any language that has this!
        • Munksgaard 1y ago
          Elixir has this, which is close: &foo(&1, bar)
        • tcfhgj 1y ago
          Powershell has this, why do you like this?
        • masijo 1y ago
          Clojure has this user=> (#(println %1 %2) "Hello " "Clojure") Hello Clojure
        • tormeh 1y ago
          I'd argue that currying is actively harmful (I suspect you agree). I've seen functions take one argument in one source file, and the next argument in another source file. In JavaScript no less. Horrendous stuff. One of my most hated anti-features, along with Scala's implicits. These kinds of features are mostly misused rather than used.
          • bunderbunder 1y ago
            From what I've seen, partial application tends to be used for utmost good in dialects of ML, and utmost evil most everywhere else. Chaotic neutral in R/tidyverse.
        • tmoertel 1y ago
          Mathematica has this: In[1]: Map((1 + #1)&, {a, b, c}) Out[1]: {a + 1, b + 1, c + 1} See https://reference.wolfram.com/language/ref/Function.html.en https://reference.wolfram.com/language/ref/Function.html.en for the full story.
• sanderjd 1y ago
  Yep, this article is a good example of one way that c++ is bad, but it's not really a great example of rust being particularly good; many other languages support this well. I'm very glad Rust is one of those languages though!
  • groos 1y ago
    I had the same thought - what Matt's examples required was strong typing and that has existed for very long time outside of the C family world.
• blub 1y ago
  If the practitioners haven’t adopted what you’re offering for 50+ years, that thing can’t be good. Rust is also struggling with its “too theoretical” concepts by the way. The attempts of the community to gaslight the practitioners that the concepts are in fact easy to learn and straightforward are only enjoying mild success, if I may call it that.
  • db48x 1y ago
    I disagree. The advertising and hype pushing people to use C++ is insane. There are hundreds of magazines that exist solely to absorb the advertising budget of Microsoft (and to a lesser extent Intel). Hundreds of conferences every year. You could be writing code in ML at your startup with no complaints and demonstrable success but as soon as your company gets big enough to send your CEO to an industry conference you’ll be switching to C++. The in–flight magazine will extol the benefits of MSVC, speakers like Matt Godbolt will preach Correct by Construction in C++, etc, etc. By the time he gets back he’s been brainwashed into thinking that C++ is the next best thing.
  • fsloth 1y ago
    ”If the practitioners haven’t adopted what you’re offering for 50+ years, that thing can’t be good.” I don’t think what features are popular in C++ is good indication of anything. The language is good only due to the insane amounts of investment to the ecosystem, not because of the language features due to design. For an industrial language inventory of ”nice features to have” F# and C# are mostly my personal gold standard. ”Too theoretical” is IMO not the correct lens to use. I would propose as a better lens a) which patterns you often use b) how to implement them in language design itself. A case in point is the gang-of-four book. It mostly gives names to things in C++ that are language features in better languages.
    • senderista 1y ago
      The GoF book uses Smalltalk for the examples as well as C++, and Smalltalk is about the most expressive imperative language you could ask for.
  • ordu 1y ago
• bigbuppo 1y ago
  It's weird that this sort of debate around C++ often leaves out the fact that many of the problems with C++ were known before C++ even existed. Outside of a few specific buckets, there is no reason to use C++ for any new projects, and really, there never has been. If you can't stomach Rust for some reason, and I'm one of those people, there are plenty of choices out there without all the pitfalls of C++ or C.
  • ivmaykov 1y ago
    > If you can't stomach Rust for some reason, and I'm one of those people, there are plenty of choices out there without all the pitfalls of C++ or C. Unless you are doing embedded programming ...
    • fsloth 1y ago
      I think embedded is one of the specific buckets. You target the compiler your client uses for their platform. There is very little choice there.
      • int_19h 1y ago
        Even then you're probably better off using something safer that transpiles to C.
        • fsloth 1y ago
          ”Transpiles to c” - how do you generally optimize single line performance hotspots in that case?
          • int_19h 1y ago
            I don't see why that would make any difference? The generated C code is just a build artifact in this case, similar to IRs often used by compilers internally. You don't think about e.g. gcc IR when you optimize hotspots in code written in C, though - you just look at the C source and the generated asm code. If you have, say, Zig transpiling to C (which it can do with `-ofmt=c`), you'd similarly look at the Zig source and the generated asm code.