6 ms·

> Just like you never want to be the smartest person in a room, you never want to be the one pushing a language to its limits. (Channable co-founder here) If e

by rkrzr 4y ago

> Just like you never want to be the smartest person in a room, you never want to be the one pushing a language to its limits. (Channable co-founder here) If everybody took this view, then a language could never improve. I have actually been very impressed with how far we have been able to take Haskell before having to push its limits. Anecdotally, we previously were using Scala (and Spark) and ran into issues much earlier. In those cases we were pushing the limits of Spark, but underlying those were the limits of the JVM. > IMHO when you’re providing language patches you probably choose the wrong language. This is a very myopic view. There is much more to consider when choosing a language (what kind of team do you have, what kind of problems are you working on, maintainability, performance, ecosystem, hiring, etc.).

DonaldPShimoda 4y ago
I really appreciate your view on all this, and I totally agree with you that the other commenter has a very nearsighted perception of things. I think the go-to example of a group taking this to the extreme is Jane Street with OCaml. For many intents and purposes, Jane Street are really the major shepherds of the language these days. They contribute tons of compiler fixes and improvements, and have written their own replacement of the standard library (which is used by many people). I think it'd be silly to say that they "chose the wrong language"; rather, they've invested in a language ecosystem that benefits them and reflects their needs, while at the same time growing and improving a whole language community. That's an awesome feat.
- rkrzr 4y ago
  That's how I see it as well - Haskell has been very beneficial for us as a company, so it's nice if we can also contribute something back to the community.
- wespiser_2018 4y ago
  The difference here is scale: Jane Street is a 20 year old company with over 1000 employees, Channable has maybe a fifth of that. The proportion of engineering effort that will have to go into language expertise will just be higher at a smaller shop pushing the bounds and this will simply take away from feature development. I've worked writing Haskell in multiple shops, seen it be successful, and also seen it fail to many times. This is a huge issue for adoption: that an engineering team using Haskell will have to devote a significant amount of time/effort to tooling/resuability/infra that would otherwise be available to directly deliver value to customers if they had gone with a different language. Stuff like pagination, custom json/typescript encodings and route generation, organizing the code base so complication time isn't a nightmare, these are all "inner source" projects I've worked on that needed to be done for us to use Haskell for a decent sized team. The fact that Channable had to go down the road of ghc-compact regions, to me, suggests that on a strictly technical basis they would be much more productive using a language like Rust of C++. Better for their end users, and better for their investors. Of course, large companies can make these deep investments into languages, tooling, and infrastructure (and by all accounts Channable is well on their way) but when they do it's only a small proportion of their entire dev team. For Haskell, I contend that its' lack of state of the art library support and tooling is a massive impediment to wide scale adoption: companies just don't want to put 1/3 of a 30 person dev group on a "platform" team in order to be productive.
  - ParetoOptimal 4y ago
    > I've worked writing Haskell in multiple shops, seen it be successful, and also seen it fail to many times. Can you share some of the successes, failures, and composition of teams Haskell experience? Also any success/failure causes you believe they had in common.
  - agentultra 4y ago
    Any team is eventually going to have to invest in tooling. If they had gone with C++ they would be fighting different fires: memory safety problems, build tool complexity, bloated compile times, memory leaks, etc. If they went with Javascript; run-time errors, async memory pressure, complex deployment artifacts, etc. Haskell has benefits for its trade-offs. Its type system is world class. I get a lot of leverage out of its type class constraint resolution. It has a sufficient compiler that generates good, fast code and a run-time system that makes dealing with concurrency much safer and easier than other systems I've worked with. You can choose any language we have out there right now and a decently sized engineering team, if they're smart, are going to have an internal team or some amount of their backlog of work dedicated to tooling. Even Twitter has a tooling team! And Java has an ecosystem where millions of dollars of full-time engineers are building IDEs and DUX tools constantly. It's the nature of the beast.
    - wespiser_2018 4y ago
      yes, but I'd argue the "buy vs. build" balance is shifted too far to the build side right now when you build all your backend services (or most of them) with Haskell. In the Haskell ecosystem there's a good deal of solutionism, but this can be solved with diligent decision making and good technical leadership, the greater issue, IMO, is that Haskell lacks the breadth and depth of libraries that allow Haskell to be a low risk language choice that allows you to build a project, see how things go, then restart with a different team/assumptions if need be. I want Haskell to win and solve these problems: I've invested years of my life learning the ecosystem and actively maintain open sources libraries, but after years of using the language and running into problems, I've lived through the situations when Haskell is less than stellar as a software engineering tool and it's quite disappointing to see.
lmm 4y ago
Can you talk more about what kind of limits you hit with Scala and Spark? I definitely have my own biases, but my feeling is you get 95% of the good stuff of Haskell while avoiding most of the problems mentioned elsewhere in this thread (e.g. you get a proper IDE-integrated debugger with breakpoints/stepping/etc. that Just Works).

by rkrzr 4y ago

DonaldPShimoda 4y ago

I really appreciate your view on all this, and I totally agree with you that the other commenter has a very nearsighted perception of things. I think the go-to example of a group taking this to the extreme is Jane Street with OCaml. For many intents and purposes, Jane Street are really the major shepherds of the language these days. They contribute tons of compiler fixes and improvements, and have written their own replacement of the standard library (which is used by many people). I think it'd be silly to say that they "chose the wrong language"; rather, they've invested in a language ecosystem that benefits them and reflects their needs, while at the same time growing and improving a whole language community. That's an awesome feat.

rkrzr 4y ago
That's how I see it as well - Haskell has been very beneficial for us as a company, so it's nice if we can also contribute something back to the community.
wespiser_2018 4y ago
The difference here is scale: Jane Street is a 20 year old company with over 1000 employees, Channable has maybe a fifth of that. The proportion of engineering effort that will have to go into language expertise will just be higher at a smaller shop pushing the bounds and this will simply take away from feature development. I've worked writing Haskell in multiple shops, seen it be successful, and also seen it fail to many times. This is a huge issue for adoption: that an engineering team using Haskell will have to devote a significant amount of time/effort to tooling/resuability/infra that would otherwise be available to directly deliver value to customers if they had gone with a different language. Stuff like pagination, custom json/typescript encodings and route generation, organizing the code base so complication time isn't a nightmare, these are all "inner source" projects I've worked on that needed to be done for us to use Haskell for a decent sized team. The fact that Channable had to go down the road of ghc-compact regions, to me, suggests that on a strictly technical basis they would be much more productive using a language like Rust of C++. Better for their end users, and better for their investors. Of course, large companies can make these deep investments into languages, tooling, and infrastructure (and by all accounts Channable is well on their way) but when they do it's only a small proportion of their entire dev team. For Haskell, I contend that its' lack of state of the art library support and tooling is a massive impediment to wide scale adoption: companies just don't want to put 1/3 of a 30 person dev group on a "platform" team in order to be productive.
- ParetoOptimal 4y ago
  > I've worked writing Haskell in multiple shops, seen it be successful, and also seen it fail to many times. Can you share some of the successes, failures, and composition of teams Haskell experience? Also any success/failure causes you believe they had in common.
- agentultra 4y ago
  Any team is eventually going to have to invest in tooling. If they had gone with C++ they would be fighting different fires: memory safety problems, build tool complexity, bloated compile times, memory leaks, etc. If they went with Javascript; run-time errors, async memory pressure, complex deployment artifacts, etc. Haskell has benefits for its trade-offs. Its type system is world class. I get a lot of leverage out of its type class constraint resolution. It has a sufficient compiler that generates good, fast code and a run-time system that makes dealing with concurrency much safer and easier than other systems I've worked with. You can choose any language we have out there right now and a decently sized engineering team, if they're smart, are going to have an internal team or some amount of their backlog of work dedicated to tooling. Even Twitter has a tooling team! And Java has an ecosystem where millions of dollars of full-time engineers are building IDEs and DUX tools constantly. It's the nature of the beast.
  - wespiser_2018 4y ago
    yes, but I'd argue the "buy vs. build" balance is shifted too far to the build side right now when you build all your backend services (or most of them) with Haskell. In the Haskell ecosystem there's a good deal of solutionism, but this can be solved with diligent decision making and good technical leadership, the greater issue, IMO, is that Haskell lacks the breadth and depth of libraries that allow Haskell to be a low risk language choice that allows you to build a project, see how things go, then restart with a different team/assumptions if need be. I want Haskell to win and solve these problems: I've invested years of my life learning the ecosystem and actively maintain open sources libraries, but after years of using the language and running into problems, I've lived through the situations when Haskell is less than stellar as a software engineering tool and it's quite disappointing to see.

lmm 4y ago

Can you talk more about what kind of limits you hit with Scala and Spark? I definitely have my own biases, but my feeling is you get 95% of the good stuff of Haskell while avoiding most of the problems mentioned elsewhere in this thread (e.g. you get a proper IDE-integrated debugger with breakpoints/stepping/etc. that Just Works).