Matt Godbolt sold me on Rust by showing me C++

Two things are incredibly frustrating when it comes to safety in software engineering:

1. The arrogance that "practitioners" have against "theorists" (everyone with a PhD in programming languages)

2. The slowness of the adoption of well-tested and thoroughly researched language concepts (think of Haskell type classes, aka, Rust traits)

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).

It takes ADT, but not function currying, and so on.

I'd love to have a syntax like

    { foo(%1, bar) }

    |x| { foo(x, bar) }

    &foo(&1, bar)

    user=> (#(println %1 %2) "Hello " "Clojure")
    Hello Clojure

    In[1]:  Map((1 + #1)&, {a, b, c})
    Out[1]: {a + 1, b + 1, c + 1}

> for_each(a.begin(), a.end(), std::cout << _1 << ' ');

Also, Scala has something similar as a first class feature[2].

[1]: https://www.boost.org/doc/libs/1_88_0/doc/html/lambda.html

[2]: https://scala-lang.org/files/archive/spec/3.4/06-expressions...

    { foo[x, bar] }

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.

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.

Unless you are doing embedded programming ...

You target the compiler your client uses for their platform. There is very little choice there.

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.

    { foo($0, bar) }

I wouldn't trust opinion of practitioners. Not after they have chosen javascript and, God forbid, PHP. Practitioners choose not what is inherently good, but what is popular. It is a very practical choice that brings a lot of benefits, so it is just practitioners being practitioners. It can be good or bad, I don't care now, it doesn't matter for my argument. The issue that a good thing can be overlooked by practitioners for decades, because there is nothing popular giving them this thing.

   foo(%1, bar(%1, 42)) 

   |x| foo(x, |y| bar(y, 42)) 

   |x| foo(x, bar(x, 42)) 

I'm relatively sure there exists such a language you are looking for, but I've forgotten its name :(.

There was a syntax extension pa_holes for OCaml (which you perhaps know, as it is natively currying) that worked like

    (\ foo \1 bar)

    fun x -> foo x bar

https://reference.wolfram.com/language/tutorial/FunctionalOp...