Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Haskell is our first choice for building production software systems

foxhound.systems

Post reply on HN
Print view View original

251–260 of 297 posts

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

#251

Post by dmitriid »

pjmlp wrote: post #104
corty wrote: post #26

Earlier quoted context omitted.

Annoyance about C++ errors isn't only about the error occuring. With me, it is predominantly about the utter unusability of the error messages. C++ has postprocessors you can use to get your 20 page STL errors down to a few lines just by reversing the expansion the compiler did to show you mere mortal something that you might recognize as your code instead of template-cthulhu. Haskell has such situations as well, but…

Not only do modern compilers give better error messages (with room for improvement still), it is possible to make use of enable_if and if constexpr/static_assert to give proper error messages for templates, and when C++20 gets widespread enough, concepts.

I personally call it "old school" vs "new school".

"Old school" is asically the programming languages that originated in the 70s-80-90s. An incorrect but an illustrative way to describe error messages for them is "The programmer needs to suffer". They are any combination of cryptic, terse, complex, exposing internal machinery of the compilers and linkers etc. There are many reasons for this: computers were not powerful enough to afford better code analysis, parsing, backtracking etc; the users of the tools also knew the tools and could tinker with them etc.

"New school" is from late 2000s on. I usually say it started with Elm. Clear messages pinpointing the exact problem, solutions to problems inside error messages, error clarity as one of the priorities in language/compiler/tool design.

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

#252

Post by willtim »

Geminidog wrote: post #227
willtim wrote: post #226

Earlier quoted context omitted.

Monadic composition is used everywhere from simple failure (Maybe or Either) through to genuine side effects such as IO. The presence of monads does not necessarily mean side effects. Haskell never claimed to "get rid of side effects", the idea is make them explicit in the types and to be able to reason about them.

Right, but the article says that Haskell pushes these side effects to the edge. I am not saying haskell claims this, I'm saying the article claims this. Haskell actually doesn't do this in practice as tons of people use do notation and state monads. The more people use do notation, the more they are embracing side effects. Literally I've seen haskell code where all function definitions had some form of do notation wh…

You seem to be lumping all side-effects together as equally bad? I don't think you can expect to push everything out to the edges, for example partiality. I take your point that a lot of imperative programming is done in Haskell (e.g. State monads). However, I think what most Haskellers mean when they talk about pushing effects to the edge, is pushing IO and other less benign effects.

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

#253

Post by thedmstdmstdmst »

slow_donkey wrote: post #250
thedmstdmstdmst wrote: post #235

Earlier quoted context omitted.

I have no horse in this race. Reading the posted article I have a hard time understanding why you posted this comment. The article has reasoned arguments related to software development. Your comment is pure emotion which seems to be your main claim against the article.

I had the same feelings as the parent - this article did not make good arguments for using Haskell specifically in building production systems, it instead argues that Haskell is a good programming language yet many of the benefits listed can be found in other languages. Even if Haskell was objectively the 'best' language, it'd likely be a poor choice for most teams simply due to familiarity and developer speed. I'd b…

I think the article was easy enough to pass by as I agree it didn't make GOOD arguments specifically in building production systems. I also give the author some slack because that article would be quite heavy to address the entire development cycle up to production systems.

From my reading the article makes no claim that Haskell is the best language. The purpose as I read it is to explain why Haskell is their first choice while addressing an audience that has a passing knowledge of Haskell.

You being extremely hesitant to hire the services because of their technology stack is great and fine. There are many stacks and services I completely avoid in dealing with so I agree there.

"It'd be a nightmare to maintain after their contract" is something someone would likely say to any language that is not their preference.

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

#254

Post by nobodyandproud »

IfOnlyYouKnew wrote: post #121
FlyingSnake wrote: post #70

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…

It’s believed (by some) that emotion is a necessary prerequisite for intelligence.

Something needs to be a driver for action, and emotions fit the bill nicely.

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

#255

Post by throwaway894345 »

hardwaresofton wrote: post #101
johndoe42377 wrote: post #85

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…

This article might be a bit overeager and overzealous, but how you use haskell is up to you -- don't use those underlying packages that disgust you if you don't like them. Haskell offers benefit at every level of abstraction. There are many ways to write Haskell and you do not need a bunch of the higher level stuff. 99% of the time you are just fine with the data modeling (simple Algebraic Data Types) and type classe…

> how you use haskell is up to you -- don't use those underlying packages that disgust you if you don't like them

These kinds of arguments are particularly lazy. Of course, Haskell's ecosystem is not so large that it's trivial to find a well-maintained, high-quality version of a library that meets one's other criteria. Programmers of a particular language are at the mercy of that language's ecosystem.

This line of reasoning reminds me of how C++ programmers would deflect criticisms of problematic features by arguing that one could use only the features that one wanted (thereby effectually creating or curating their own sub-language) and only choosing dependencies that were equally written in that sub-language. So easy!

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

#256

Post by Geminidog »

willtim wrote: post #252
Geminidog wrote: post #227

Earlier quoted context omitted.

Right, but the article says that Haskell pushes these side effects to the edge. I am not saying haskell claims this, I'm saying the article claims this. Haskell actually doesn't do this in practice as tons of people use do notation and state monads. The more people use do notation, the more they are embracing side effects. Literally I've seen haskell code where all function definitions had some form of do notation wh…

You seem to be lumping all side-effects together as equally bad? I don't think you can expect to push everything out to the edges, for example partiality. I take your point that a lot of imperative programming is done in Haskell (e.g. State monads). However, I think what most Haskellers mean when they talk about pushing effects to the edge, is pushing IO and other less benign effects.

>You seem to be lumping all side-effects together as equally bad?

Never implied anything was bad or good. Just saying that Haskell style programming does not push side effects to the edge.

>I don't think you can expect to push everything out to the edges, for example partiality.

Of course you can't push everything to the edge, but haskell style programming doesn't attempt to do this. It embraces the side effects and no one actually pushes anything to the edge. Partiality was just an example, the point is the bind operator will have a side effect on b so you can no longer treat the output of b as a pure black box. People who use haskell use the bind operator all the time indicating that their code is littered with side effects. Which again isn't necessarily bad, it just is what it is.

>However, I think what most Haskellers mean when they talk about pushing effects to the edge, is pushing IO and other less benign effects.

But my argument is this is not often done. I've seen tons of giant IO functions wrapped in do notation. Generally, no big attempt is made to segregate IO or side effects away from pure logic. Everyone just writes a monad and starts using do notation.

Again if you avoid using monads as much as possible in haskell you are pushing side effects to the edge. If you don't do this, which is basically what most haskell programmers end up doing, then you are not pushing side effects to the edge.

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

#257

Post by jhayward »

Rusky wrote: post #245
jhayward wrote: post #158

Earlier quoted context omitted.

I'm always puzzled by people who see this as somehow a good thing. If the Rust compiler can figure out what the type should be, why doesn't it just do the cross-function inference, and leave the complicated nested implications which only obscure the intent and effect out of it? If having the programmer specify types is an important check on the correctness of the code that is written, how is blindly copying, without…

I am not sure where you got the idea that Rust error message suggestions lead to blindly copying 60+ character type specifications. They tend to be much more localized and understandable in my experience.

I got the idea by following the Rust tutorials and then making 'simple' programs, seeing the errors, going to Rust resources and getting the advice 'just cut and paste the expected type'. The expected types generally had 6-8 ':'s, and three to four deep nested type specifiers.

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

#258

Post by throwaway894345 »

darksaints wrote: post #202

Okay, so this is admittedly snarky but we've seen this sort of blog post so much that it has practically become an Onion article: Why Haskell Is Our Secret Weapon, by Startup You've Never Heard Of. And then when someone points out that nobody knows who they are or what they've built, we get commenters talking about how company X, Y, and Z are also using Haskell. And those claims also come up short...most of them can'…

At least they don't have exactly one company that has had some decent success with The Language in production, and were it not for the evangelism of The Language Community, you wouldn't know who the company was. And if you ask, "how does one do multithreading in The Language?", The Community will shout at you about how you don't really need multithreading and The Company has been super successful and never once needed multithreading and by the way multithreading will be a feature in The Language Very Soon. :)

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

#259

Post by 414owen »

PietPtr wrote: post #200
414owen wrote: post #29

Earlier quoted context omitted.

I write Haskell professionally, and I can confidently say that there are plenty of jobs. Some large tech companies (eg. Facebook, GitHub, Twitter), quite a few banks, a lot of consultancy companies, and plenty of random companies I'd never heard of. It is quite difficult to get a first Haskell job though, because they mostly require production Haskell experience, so there's your chicken and egg problem.

Working with Haskell professionally sounds like a very interesting career path. Could you point to some resources to get better at the production Haskell skills that these companies are looking for? Perhaps gaining experience with projects which use Haskell in a similar way to the companies you mention could help with finding that first Haskell job.

Sure thing.

I'm not sure what your current level is, but I can give some general advice for people that happen upon this:

---

Haskellers are generally expected to understand most of the typeclassopedia (https://wiki.haskell.org/Typeclassopedia), don't worry about learning it all in one go. I had to read this page many times before I grokked most of it.

---

Avoid tutorials that overuse analogies. A Monad only adds one operation to Applicative:

  class Monad m where
    (>>=)  :: m a -> (a -> m b) -> m b
This reads as: `m` is a monad if, given an `m a`, and an `a -> m b`, you can construct an `m b`.

---

It's important to be really good at using Monads that support multiple effects, to create little DSLs. If I want a component of my program to support throwing errors, creating a log, and reading an environment, (all purely), I'd use something like this:

  type MyDSL
    = ReaderT Environment
        (WriterT [String]
          (Except ErrorType))
These are monad transformers from the mtl library.

Where I work we use free monads instead of monad transformers, but that's just an implementation detail, it's used the same as a transformer stack.

---

Create a cool project, Haskell people like languages. When I was interviewing I showed off a tiny lisp-like language implemented in Haskell (https://github.com/414owen/phage). This was my first non-trivial Haskell project so don't judge it too harshly.

---

Read Haskell Weekly (https://haskellweekly.news/newsletter.html). It's a great source of ideas and knowledge.

---

A lot of Haskell shops use, or are migrating towards using, nix (https://nixos.org/).

---

Apply! The Haskell market seems to favor the interviewee. In the end, I had more than one offer, even for my first Haskell job.

Good luck!

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

#260

Post by zvrba »

uryga wrote: post #82
magicalhippo wrote: post #52

Earlier quoted context omitted.

Why couldn't it be a function that queries a database, like answering "on invoice x, does line y exist"? Genuinely curious, not that familiar with Haskell, just thought you could use something like parameter binding or similar to construct functions like that.

if it has side-effects, it has to be something like Int -> Int -> IO Bool otherwise the type checker won't let you perform any side-effecting operations (btw Haskell's `IO Bool` would be spelled `IO ` in C++/Java syntax)

But is _just reading_ from a database a "side-effect"? It is non-deterministic, but it has no side-effects. So IO jumbles together the two notions.
Post reply on HN