I'm a bit biased in my development perspective and a bit jaded with the state of back-end development, but here goes:
I've done a decent amount of Elixir in prod over the last year and a bit and I've found the lack of a decent, modern static type system pretty frustrating. I love the idea of failing fast, but most of the time we're throwing 500s from trivial developer mistakes (and yes, we do TDD). Lazily evaluated libraries like Streams or Ecto.Multi explode in weird, non-local ways because the types are not checked at the call-site, making refactoring and iterating a chore.
I have tried out Dialyzer, but it lacks many things you would expect from a modern type system (eg. parametric polymorphism). While experimenting with it I've been able to get it to accept trivially broken programs without complaint, which means I've never been really be sure it's got my back, so have given up on it. And yes, this is with the flags ratcheted to their highest settings. Not to mention all the third party libraries who forget to keep their typespecs up to date.
I realise designing a type system that can handle hot-reloading in a cluster is still an open problem (interesting work in progress on this front though), but most folks aren't really at the scale where that is a problem. They'd probably be far better served using a more traditional deployment process while getting the immediate benefits of the improved iteration speed, refactoring confidence, and data modelling that languages with modern type systems provide. The front end is beginning to 'get it' with the likes of Typescript, Flow, Elm, Reason, Purescript, etc, and I can only hope that their good work and excitement will eventually flow back to us on the back-end...
The front end is beginning to 'get it' with the likes of Typescript, Flow, Elm, Reason, Purescript, etc, and I can only hope that their good work and excitement will eventually flow back to us on the back-end...
I really have to say it’s been a joy writing the backend for a Bitcoin-related app[1] in Haskell. It took me a while to adapt to Haskell — probably a couple of years or so — but in the end it has left me with such strong compiler guarantees that I can literally grep through my codebase for “error|throw” and see where a 500-error may be thrown by the server.
The only somewhat laborious part is categorizing all the exceptions, that can be thrown when performing requests, into retryable and non-retryable ones, so requests that throw these intermittent, retryable errors are automatically retried (the retry package makes automatic retrying super easy).
This post[2] gets to the crux of how my coding has adapted over the years: getting rid of runtime-decisions (e.g. looking at a Maybe value at runtime to figure out what to), by moving the relevant parameters to the type level, such that program flow is determined at compile-time by which type an operation is parametized over. For example, the app is parametized over two types: DB implementation and Blockchain implementation[3], which makes the compiler construct a program for these specific implementations at compile-time, rather than making it a runtime-decision based on reading a config file at startup.
Scala maybe, but it has its share of problems, alas. On a purely features level I'd definitely be looking for something with null safety, disjoint unions, pattern matchin with exhaustiveness checking, local type inference, and parametric polymorphism (ie. generics). These are what set a modern, nicely typed language apart from the more constrained, frustrating kind that caused many to escape to PHP, Ruby, Python, and now Elixir in the first place. We need a richer experience beyond that though in terms of ecosystem, compiler performance, teaching materials, etc. in order to really drive things in that direction though and get more back-end devs on board. Obviously something in our approach is not working - and it must be partly our failings. It's going to take a while to turn the ship around, but I still have hope!
In my frustration while writing my comment I'll admit I was a bit weaselly there and didn't really cite anything. The Akka.Typed[1] project is working on type-safe actors, but looking at it again I'm not sure how or if they can do hot-reloading or ensuring that you can soundly migrate actors in-memory before starting a deployment. That would be super cool to see. Maybe something for Pony to look into? If folks know of any academic PL research on this front I'd be very interested. But again, I'll reiterate that it's a use case that lies at the very extreme end of our industry.
Comments
I'm a bit biased in my development perspective and a bit jaded with the state of back-end development, but here goes:
I've done a decent amount of Elixir in prod over the last year and a bit and I've found the lack of a decent, modern static type system pretty frustrating. I love the idea of failing fast, but most of the time we're throwing 500s from trivial developer mistakes (and yes, we do TDD). Lazily evaluated libraries like Streams or Ecto.Multi explode in weird, non-local ways because the types are not checked at the call-site, making refactoring and iterating a chore.
I have tried out Dialyzer, but it lacks many things you would expect from a modern type system (eg. parametric polymorphism). While experimenting with it I've been able to get it to accept trivially broken programs without complaint, which means I've never been really be sure it's got my back, so have given up on it. And yes, this is with the flags ratcheted to their highest settings. Not to mention all the third party libraries who forget to keep their typespecs up to date.
I realise designing a type system that can handle hot-reloading in a cluster is still an open problem (interesting work in progress on this front though), but most folks aren't really at the scale where that is a problem. They'd probably be far better served using a more traditional deployment process while getting the immediate benefits of the improved iteration speed, refactoring confidence, and data modelling that languages with modern type systems provide. The front end is beginning to 'get it' with the likes of Typescript, Flow, Elm, Reason, Purescript, etc, and I can only hope that their good work and excitement will eventually flow back to us on the back-end...
I really have to say it’s been a joy writing the backend for a Bitcoin-related app[1] in Haskell. It took me a while to adapt to Haskell — probably a couple of years or so — but in the end it has left me with such strong compiler guarantees that I can literally grep through my codebase for “error|throw” and see where a 500-error may be thrown by the server.
The only somewhat laborious part is categorizing all the exceptions, that can be thrown when performing requests, into retryable and non-retryable ones, so requests that throw these intermittent, retryable errors are automatically retried (the retry package makes automatic retrying super easy).
This post[2] gets to the crux of how my coding has adapted over the years: getting rid of runtime-decisions (e.g. looking at a Maybe value at runtime to figure out what to), by moving the relevant parameters to the type level, such that program flow is determined at compile-time by which type an operation is parametized over. For example, the app is parametized over two types: DB implementation and Blockchain implementation[3], which makes the compiler construct a program for these specific implementations at compile-time, rather than making it a runtime-decision based on reading a config file at startup.
[1] https://github.com/runeksvendsen/rbpcp-handler
[2] http://www.parsonsmatt.org/2017/04/08/maybe_use_a_type_param...
[3] https://github.com/runeksvendsen/rbpcp-handler/blob/master/s...
Like e.g. Java, Scala, C#?
Scala maybe, but it has its share of problems, alas. On a purely features level I'd definitely be looking for something with null safety, disjoint unions, pattern matchin with exhaustiveness checking, local type inference, and parametric polymorphism (ie. generics). These are what set a modern, nicely typed language apart from the more constrained, frustrating kind that caused many to escape to PHP, Ruby, Python, and now Elixir in the first place. We need a richer experience beyond that though in terms of ecosystem, compiler performance, teaching materials, etc. in order to really drive things in that direction though and get more back-end devs on board. Obviously something in our approach is not working - and it must be partly our failings. It's going to take a while to turn the ship around, but I still have hope!
"interesting work in progress on this front though"
Any pointers?
In my frustration while writing my comment I'll admit I was a bit weaselly there and didn't really cite anything. The Akka.Typed[1] project is working on type-safe actors, but looking at it again I'm not sure how or if they can do hot-reloading or ensuring that you can soundly migrate actors in-memory before starting a deployment. That would be super cool to see. Maybe something for Pony to look into? If folks know of any academic PL research on this front I'd be very interested. But again, I'll reiterate that it's a use case that lies at the very extreme end of our industry.
[1]: http://doc.akka.io/docs/akka/current/scala/typed.html