undefined | Better HN

0 pointstensor3y ago0 comments

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.

0 comments

3 comments · 1 top-level

Capricorn24813y ago· 2 in thread

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?

jmillikin3y ago

  > Are there any merits to languages like Haskell/Clojure when the goal
  > is still shipping software?

Depends on what kind of software you're shipping.

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?

Definitions will vary, but IMO the defining feature of an industrial language is that the language itself is not extensible. Every C or Rust project has the same keywords, control statements, operators, and type system -- as long as you don't go absolutely mad with macros. 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.

Capricorn24813y ago

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

Why is this a worst case for Haskell? Aren't databases and HTTP the real blocker to performant web apps?

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

I don't know enough about CL, but if you stay away from macros, is the average LISP developer anymore likely to make a non industrial code base than a Rust developer? It seems like the real cause of difficult to grok codebases is not just macros, but extreme abstraction, which can be done with just passing functions around.

1 more reply

j / k navigate · click thread line to collapse