4 ms·

I would say the main competitive advantage of using functional programming, or Haskell in this case, is that it's a relatively inexpensive benefit you can offer

I would say the main competitive advantage of using functional programming, or Haskell in this case, is that it's a relatively inexpensive benefit you can offer to employees (the cost is in rolling your own version of sorely needed tooling/ecosystem stuff once you reach sufficient size) and lets you tap into a pond where even a small fish can feel big. For scalability, I disagree with the author. Being functional does not necessarily make you scale better. The one hot backend paradigm that is easiest to scale is to write stateless, containerized microservices. Functional programming will nudge you in the right direction of writing stateless code but isn't strictly necessary. It's kind of disappointing to hear functional programming cargo-culting from someone who admittedly doesn't really program much anymore. The software engineering industry already has enough resume driven development perpetuated by software engineers hyping things up to other software engineers

opportune 7y ago
As an addendum, I'd say "sorely needed tooling/ecosystem stuff once you reach sufficient size" is flexible. You can probably get by with Clojure, Scala, or F# for a lot longer than you can with Haskell.
- yakshaving_jgt 7y ago
  > You can probably get by with Clojure, Scala, or F# for a lot longer than you can with Haskell. What experience are you basing this on? It sounds like pure assumption, and doesn't at all match my experience of working at either a Scala or Clojure company, or running my businesses on Haskell.
  - opportune 7y ago
    I actually don't have much experience with Haskell, however I do have experience with Scala and the Java and .NET ecosystems (and know personally some people very into F#). My assumption was that the libraries, build and test systems that work in JVM/.NET land probably don't work as well as in Haskell land. There are many JVM/.NET applications with very large development teams that have put a lot of work into tooling; I don't know of any large (in terms of active fulltime devs) Haskell projects so my assumptions is that these tools would be less mature there. But perhaps I'm incorrect, hence my original use of the qualifier "probably"
- karmakaze 7y ago
  I would immediately believe Clojure and F#. Scala I'm a bit more skeptical about. Unless it's in a restricted domain with established patterns, I've seen and can imagine seeing many more codebases which sprawl into accidentally complex messes with very poor compile time ergonomics.
lmm 7y ago
> The one hot backend paradigm that is easiest to scale is to write stateless, containerized microservices. Functional programming will nudge you in the right direction of writing stateless code but isn't strictly necessary. Microservices force you to reduce your service interfaces to lowest common denominator. You simply can't build a really powerful system out of microservices with a reasonable amount of code, because there's no way to send complex structures across service boundaries; you end up spending more effort serializing and deserializing than actually doing business logic. Functional programming lets you achieve the same isolation benefits as microservices without the overhead.
- opportune 7y ago
  A good microservice architecture won't have an external call result in multiple serde bounces between other microservices before a response is returned. At worst it should wrap access to something slow like a database or another complicated backend service. >Functional programming lets you achieve the same isolation benefits as microservices without the overhead. Isolation benefits, sure. Performance benefits, no, because you still run into https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law
- weberc2 7y ago
  Why should serialization and deserialization be “effort”? Your data objects shouldn’t be more complex than is trivially represented with JSON or else you have a different problem. Besides, while I’m not a microservices enthusiast, isolation isn’t the main goal of microservices, it’s being able to deploy, scale, and operate services independently from other teams.
  - lmm 7y ago
    > Your data objects shouldn’t be more complex than is trivially represented with JSON or else you have a different problem. That's the whole problem I'm talking about. Like I said, it forces you to reduce all these interfaces to lowest common denominator. > Besides, while I’m not a microservices enthusiast, isolation isn’t the main goal of microservices, it’s being able to deploy, scale, and operate services independently from other teams. If you're just talking about each team having its own service, that's not what's usually meant by "microservices".
UK-AL 7y ago
I don't think most companies would take much notice of functional programming experience. So it cannot be resume driven. If you resume driven, you go with react, or containers or something.
caseymarquis 7y ago
I would argue that starting with the actor paradigm is better than starting with microservices (ideally with some form of dependency injection). In a way they are the same thing, but you aren't forced by the Actor paradigm to start with individual processes. You can start with a single service, and break actors out into microservices as needed. Starting with microservices seems like premature optimization to me. I feel that the actor paradigm fills this gap nicely.

opportune 7y ago

As an addendum, I'd say "sorely needed tooling/ecosystem stuff once you reach sufficient size" is flexible. You can probably get by with Clojure, Scala, or F# for a lot longer than you can with Haskell.

yakshaving_jgt 7y ago
> You can probably get by with Clojure, Scala, or F# for a lot longer than you can with Haskell. What experience are you basing this on? It sounds like pure assumption, and doesn't at all match my experience of working at either a Scala or Clojure company, or running my businesses on Haskell.
- opportune 7y ago
  I actually don't have much experience with Haskell, however I do have experience with Scala and the Java and .NET ecosystems (and know personally some people very into F#). My assumption was that the libraries, build and test systems that work in JVM/.NET land probably don't work as well as in Haskell land. There are many JVM/.NET applications with very large development teams that have put a lot of work into tooling; I don't know of any large (in terms of active fulltime devs) Haskell projects so my assumptions is that these tools would be less mature there. But perhaps I'm incorrect, hence my original use of the qualifier "probably"
karmakaze 7y ago
I would immediately believe Clojure and F#. Scala I'm a bit more skeptical about. Unless it's in a restricted domain with established patterns, I've seen and can imagine seeing many more codebases which sprawl into accidentally complex messes with very poor compile time ergonomics.

lmm 7y ago

> The one hot backend paradigm that is easiest to scale is to write stateless, containerized microservices. Functional programming will nudge you in the right direction of writing stateless code but isn't strictly necessary. Microservices force you to reduce your service interfaces to lowest common denominator. You simply can't build a really powerful system out of microservices with a reasonable amount of code, because there's no way to send complex structures across service boundaries; you end up spending more effort serializing and deserializing than actually doing business logic. Functional programming lets you achieve the same isolation benefits as microservices without the overhead.

opportune 7y ago
A good microservice architecture won't have an external call result in multiple serde bounces between other microservices before a response is returned. At worst it should wrap access to something slow like a database or another complicated backend service. >Functional programming lets you achieve the same isolation benefits as microservices without the overhead. Isolation benefits, sure. Performance benefits, no, because you still run into https://en.wikipedia.org/wiki/Amdahl%27s_law https://en.wikipedia.org/wiki/Amdahl%27s_law
weberc2 7y ago
Why should serialization and deserialization be “effort”? Your data objects shouldn’t be more complex than is trivially represented with JSON or else you have a different problem. Besides, while I’m not a microservices enthusiast, isolation isn’t the main goal of microservices, it’s being able to deploy, scale, and operate services independently from other teams.
- lmm 7y ago
  > Your data objects shouldn’t be more complex than is trivially represented with JSON or else you have a different problem. That's the whole problem I'm talking about. Like I said, it forces you to reduce all these interfaces to lowest common denominator. > Besides, while I’m not a microservices enthusiast, isolation isn’t the main goal of microservices, it’s being able to deploy, scale, and operate services independently from other teams. If you're just talking about each team having its own service, that's not what's usually meant by "microservices".

UK-AL 7y ago

I don't think most companies would take much notice of functional programming experience. So it cannot be resume driven. If you resume driven, you go with react, or containers or something.

caseymarquis 7y ago

I would argue that starting with the actor paradigm is better than starting with microservices (ideally with some form of dependency injection). In a way they are the same thing, but you aren't forced by the Actor paradigm to start with individual processes. You can start with a single service, and break actors out into microservices as needed. Starting with microservices seems like premature optimization to me. I feel that the actor paradigm fills this gap nicely.