Keeping the combinatorics to a minimum is critical, so if I wanted the benefits of erlang/OTP, I'd use it directly. Wrestling with these VM-in-a-VM languages is for the birds!
Only thing I miss about Elixir is its function composition operator.
Keeping the combinatorics to a minimum is critical, so if I wanted the benefits of erlang/OTP, I'd use it directly. Wrestling with these VM-in-a-VM languages is for the birds!
Only thing I miss about Elixir is its function composition operator.
Yeah after a friend re-introduced me to lisps, and I watched the original SICP classes along with some other things I got really into lisp and started building things in Clojure/SBCL (more so clojure).
After trying lisps my next foray was Haskell and now I can't imagine.
It's like a bad after school special -- Haskell, don't even try it once if you want to go back and live happily in untypechecked land. Now I have to have at least Typescript.
> Keeping the combinatorics to a minimum is critical, so if I wanted the benefits of erlang/OTP, I'd use it directly. Wrestling with these VM-in-a-VM languages is for the birds!
Yup, I feel that.
> Only thing I miss about Elixir is its function composition operator.
|> this thing right?
Startups need code that works, not good code, and certainly not code that is correct.
Large companies need code that meets the business need as fast and as cheaply as possible, makes developers more fungible, and is easy to hire for. Most companies just aren't doing the kind of work that you either need the correctness or the brains that Haskell attracts (not that Haskellers are smarter, but they skew towards theoretical knowledge, when sometimes you really just need someone to fix the rails controller that works properly with the new Stripe gem).
Correctness, performance, and error avoidance just aren't enough of a business need in just about all sectors. Good enough is good enough, and smart companies are good enough until it's not good enough.
BTW, even for myself, when I want to be productive/fast, I choose Typescript. When I want to be well structured and correct, I use Haskell. When I want to be blazing fast and mostly correct I use Rust.
IMO 99% of companies will never need anything more than Typescript (or it's equivalent) if the right solution wasn't wordpress+woocommerce or whatever to start with. Even Typescript is already overkill, since lots of people prefer vanilla JS and there are rubyists running around everywhere who haven't touched Sorbet but are extremely productive nonetheless (I am a bit biased against ruby, forgive me).
Haskell is what people think Java was supposed to be like/going to be -- the type system is expressive, the runtime system is amazing, it's got a bunch of mature libraries in the ecosystem, the performance is within spitting distance of Java if not better, consumes less memory, etc.
Even amongst research/ML languages Haskell isn't far behind. It's been a while since I've looked but Idris is basically Haskell + dependent types.
Haskell is the Mercedes of PL (especially if you're referring to the subset of practially-used PL).
I want to be clear that once I tried Haskell it became impossible for me to consider not having a similar type system again. It even soured me off of Go -- a simple nonfeature like having nullable types just ruins entire languages for me now.
Like it's why Python, Javascript, PHP and Ruby are underepresented, and why Visual Basic was so hugely unpopular in the 1990's, having had virtually no developer mind share or installed base.
It wasn't a dig at lisp BTW. Just pointing out that the combo of no typechecking + such a homogeneous syntax is going to make it harder for the new guy to find his bearings in the codebase.
In your examples objects are idiomatic, and give the new devs some idea of what they're dealing with outside of runtime. I know lisp supports objects, but I wouldn't call them idiomatic from the lisp I've seen.
And as for typechecking, the writing has been on the wall for PHP (first Hack, now native type declarations) & Javascript (Typescript anyone?) for some time now.