Rust feels like a very patchwork language. There's all sorts of issues (for loops, error handling, referencing/dereferencing, type inference, etc) that they've worked around by adding another very specific compiler behavior that completely falls apart in any other usage.
Like having to do `&mut **` to pass a reference to a function once you get out of the compiler's comfort zone.
Rust is a very industrial language. It tries to identify specific useful patterns and then expose them to the programmer in misuse-resistant forms.
In contrast, academic languages try to identify broadly-applicable abstract primitives and expose those, allowing users to implement the behaviors they need in libraries. The result feels more consistent at a language level because you can tie language features very closely to an underlying theory of computation.
I've written a lot of C++ (industrial) and Haskell (academic). Although I love how Haskell allows users to (for example) define their own control-flow statements, that "bag of primitives" nature leads to Haskell projects easily forming their own dialect of the language[0] without even having to resort to macros.
[0] This is also a common criticism of Lisp and Forth.
Honestly I'd put rust somewhere between Lisp and Haskell, solidly in the academic language camp. It's full of all sorts of neat tricks, with a great variety of ways to accomplish any one thing. You also need to dip into 3rd party libraries for nearly basic things like decent error handling.
In my mind an industrial language needs to be boring and obvious. For instance, Go is very boring, and it actively discourages by it's design "clever" programming. Java Go and C are industrial languages. C++ is far too clever these days.
All that said rust is far better than Java and Go for interfacing with low level systems, and of course the safety improvements from the borrow checker are very valuable, despite the frustrations it often causes.
I don't dislike rust, but it sure could use a lot of polish in my opinion, making obvious things easy and discouraging clever things.
What's the idea here? Industrial languages are obvious and so more people can jump on a project without being lost? Is C really industrial in that case?
Are there any merits to languages like Haskell/Clojure when the goal is still shipping software?
> Are there any merits to languages like Haskell/Clojure when the goal
> is still shipping software?
Haskell is easy to use for building parsers, so if part of your value add is (for example) compatibility with a competitor's proprietary dialect of SQL then you'll be better off writing the parser in Haskell than in C or Rust. It also works well for software that is highly mathematical (in the "described as equations" sense, not the "HPC numeric kernel" sense), because a developer can apply formal methods without having to go all the way to Agda or Idris.
On the other hand, Haskell is not great when you need predictable optimization or precise memory management. A lot of modern commercial software is basically business logic scaffolded over an HTTP or RPC server, which is maybe a worst-case scenario for Haskell. It also doesn't work for Rust's target audience of systems programming because idiomatic Haskell requires a heavy runtime.
> Industrial languages are obvious and so more people can jump on a
> project without being lost?
>> On the other hand, Haskell is not great when you need predictable optimization or precise memory management. A lot of modern commercial software is basically business logic scaffolded over an HTTP or RPC server, which is maybe a worst-case scenario for Haskell
>> It's possible for a C expert to read C code from pretty much any codebase and understand what's going on at a tactical level. This is not true of research-y Haskell and it's very not true of idiomatic Lisp.
> Why is this a worst case for Haskell?
> is the average LISP developer anymore likely to make a non industrial
> code base than a Rust developer?
[0] IIRC the Yesod framework's Warp does well on benchmarks, and when you look at code like https://github.com/yesodweb/wai/blob/master/warp/Network/Wai... you can see the lengths they had to go through to work around the choice of implementation language.
[1] Go has a garbage collector, but exposes the stack/heap distinction more directly than Haskell, so it's easier to write allocation-free code in hot paths.