Live data from Hacker News

Haskell is our first choice for building production software systems

foxhound.systems

161–170 of 297 posts

Re: Haskell is our first choice for building production software systems

#161

Good luck scaling this to organization of 100+ engineers. You will soon learn the tradeoff between writing and reading code. And the stark realities of the dev hiring markets and the thing called a learning curve.

You're off by probably an order of magnitude. You can absolutely scale this organization to 100+ engineers. I've worked at a company with ~30 Haskell developers and I was involved in hiring most of them without lowering our hiring bar. If we really needed more it would have been quite easy to lower the bar a little and increase the numbers significantly. Here's another example of a company that has a large Haskell team:

https://iohk.io/en/team/#team=development

Now if you needed to hire 1000 developers, then you'd have more of a problem, and perhaps Haskell wouldn't be the right approach. But in my experience, Haskell engineers get a multiplier effect over the average non-Haskell engineer because the code is more concise and the average engineer skill is higher. I don't know what the multiplier is, but it's definitely non-zero and positive. This not only pays the obvious direct benefits, but also reduces the communication overhead of your team and the number of managers you need to hire.

Re: Haskell is our first choice for building production software systems

#162

> Many programmers encounter statically typed languages like Java or C++ and find that the compiler feels like an annoyance. By contrast, Haskell’s static type system, in conjunction with compile-type time checking, acts as an invaluable pair-programming buddy that gives instantaneous feedback during development. the reason they "find that the compiler feels like an annoyance" is because their first exposure to Java…

I learned both Haskell and Rust self-taught an still find the latter's type system a bit of a cage for it's lack of higher kinded types, frankness be. I know not much of Java , but my sentiments concerning C++ are even worse. I do not regularly program in Haskell and far more often in Rust .

Rust metadata (not just types) have an habit of getting in your way.

It is all for good reason, you can't ditch the GC and have control over the memory structure without the compiler complaining about details here and there. But fixing those strings versus slices and iterator type mistakes is really annoying.

Re: Haskell is our first choice for building production software systems

#164

Unfortunately, the Haskell ecosystem has been ruined (well, almost) by unnecessary, redundant abstractions and narcissistic idiots who pushes them. I recently tried to compile haskell-language-server and stack from sources. 157 and 168 (or something) dependencies, full of redundant esoteric bullshit, compat packages, lifted crap, etc. It is even worse than J2EE where it was the same redundant wrapping and indirection…

> To use Haskell correctly, like the classic xmonad and similar projects, requires discipline, knowledge and good taste for just right abstractions

Hum... Knowledge and an acquired taste, yes. You'll need those. Discipline not. Discipline is exactly what Haskell doesn't require.

Re: Haskell is our first choice for building production software systems

#165
post #36
post #19

Earlier quoted context omitted.

> on the other hand you have an easier time to attract the few you need How is it easier to find a Haskell developer vs finding a Java/Python/PHP developer?

I've never hired a Haskell developer, but anecdotally from my friends and associates who have, if you put out an advertisement for a Java/Python/PHP developer you get 500 applications from average candidates. If you put out an advertisement for a Haskell developer you get 5 applications from good candidates.

For reference, that got called the "Python paradox" back then when Google was exploiting it. Of course, Python is now mainstream, so it doesn't have this effect anymore.

Re: Haskell is our first choice for building production software systems

#166
post #68
post #56

Earlier quoted context omitted.

> your program is only fully type checked when all code paths are executed. The solution to this is to make sure that, during testing, all code paths are executed. And that’s something you should be doing anyway, to find bugs that aren’t type errors.

That is impossible with almost all non-trivial software. Testing proves only the presence of errors not their absence.

> Testing proves only the presence of errors not their absence.

I've never thought of it that way, but that totally makes sense.

Re: Haskell is our first choice for building production software systems

#167

Earlier quoted context omitted.

> The reason you've chosen Haskell and, by the way, also the TLD ".system", is that you've constructed your identity in such a way that "advanced language with a steep learning curve" is something that fits. I think you're projecting too much on them. They found Haskell performant and are promoting it, I don't see any problem with it. How is any different from all the Rust evangelism HN sees all the time?

I really don't have a problem with their choice–I wasn't being ironic. It's perfectly acceptable to make "I like it" or "it works for us" choices. I do believe, very very mildly, that there's a strain of thinking among the tech crowd that glorifies this Spock-like emotional detachment and I'm-so-rational mindset. Two issues, actually: First, such a mindset is neither possible nor would do much good. There are stroke…

I think these are very keen observations of reality, and they're very well put.

I've long-admitted that my heuristics for choosing a tech stack are very similar to what you describe. I analyze the requirements and give each technology a pass/fail grade. Then, amongst those that pass, I simply choose the one that I find the coolest.

Re: Haskell is our first choice for building production software systems

#168
post #9

Good luck scaling this to organization of 100+ engineers. You will soon learn the tradeoff between writing and reading code. And the stark realities of the dev hiring markets and the thing called a learning curve.

I feel like this isn't discussed enough. I can't comment on the technical merits of Haskell but growing an organization and replacing engineers is so much more difficult when you're using tools that aren't mainstream.

Optimizing for worker fungibility, in a vacuum, seems like a -EV "playing not to lose" strategy. It's understandable that this line of thinking is common though.

I also believe that to be the case as an employee. Ie, being a generalist is probably -EV for your career but it feels safer so it's kind of a contrarian position to say "be a specialist".

Re: Haskell is our first choice for building production software systems

#169

> Many programmers encounter statically typed languages like Java or C++ and find that the compiler feels like an annoyance. By contrast, Haskell’s static type system, in conjunction with compile-type time checking, acts as an invaluable pair-programming buddy that gives instantaneous feedback during development. the reason they "find that the compiler feels like an annoyance" is because their first exposure to Java…

I find the compiler an annoyance in Haskell just as much as C++ - it just forces me to write more code (more liability) and leads to overly rigid type system designs, like modeling behavior with classes or traits/type classes. I’ve only found these ways of writing software to be universally worse than simple module-oriented programming, writing C-like code in languages like Python or Ruby and only selectively using C extensions for isolated cases where speed provably matters.

Compilers do not offer compensating benefits, like catching bugs or ensuring behavioral correctness, that justify all the extra rigidity, slowness, and especially liability of all the extra code (even in Haskell).

Re: Haskell is our first choice for building production software systems

#170
post #14

Earlier quoted context omitted.

Actually, the reason why I found static typing annoying in the past (and why I felt more productive in Python) were the types are really low level (missing basic things like tuples) and lack of type inference. You have to repeat the type information, a lot. And also you have to declare lot of intermediate data structures. In Python, this became easier and one could focus on the data transformations, thinking about th…

I appreciate that you wrote that you "feel" more productive with python. I 100% agree with this feeling at most scales of code size, and the feeling matches reality at the small scale. However, I've found that this feeling of productivity doesn't match reality in the large. I use Haskell for programming in the large despite this feeling of unproductivity, because in fact, I am way more productive.

Just to clarify, I agree that Haskell can be more productive than Python, I was talking about productivity of Python (or, for that matter, Lisp) compared to C-like languages of the era. But with Haskell's type inference, the Python's advantage is lost (if we forget, for a moment, extremely well-designed Python's standard library with focus on convenience).
Post reply on HN