Haskell is our first choice for building production software systems • Hacker News Board

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

#241

Post by 91edec » Mon, Jan 11, 2021, 5:32 PM UTC

brundolf wrote: post #237

ashtonkem wrote: post #198

Earlier quoted context omitted.

Haskell error messages are far less verbose, but I find them hard to read. What makes it worse is that often the error message involves a lot of deeply nested types that were hidden from me before by library writers using an alias. So I’ve had a lot of “where did that come from?” moments.

I had this problem when being onboarded into a TypeScript codebase recently. Unfortunately I don't think there's a technical solution to it: the type system simply won't stop you from making types that are way too complicated (unless you use a language like Go where the type system is intentionally lobotomized, which obviously comes with its own problems). We're used to avoiding complexity when it comes to logic , bu…

Typescript needs some work on displaying type error messages, often the last line is all that needs to be read.

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

#242

Post by brundolf » Mon, Jan 11, 2021, 5:38 PM UTC

91edec wrote: post #241

brundolf wrote: post #237

Earlier quoted context omitted.

I had this problem when being onboarded into a TypeScript codebase recently. Unfortunately I don't think there's a technical solution to it: the type system simply won't stop you from making types that are way too complicated (unless you use a language like Go where the type system is intentionally lobotomized, which obviously comes with its own problems). We're used to avoiding complexity when it comes to logic , bu…

Typescript needs some work on displaying type error messages, often the last line is all that needs to be read.

Type systems are really good for detecting contradictions; they're much less good at figuring out which piece should be different. For any given type error, there may be half a dozen different changes to the code that would resolve it in different ways. Type systems often have no real way of guessing the user-intent there. There are loose heuristics, like... an explicit return type is more likely to be intentional (and therefore correct) than the type of the local value that's being returned. But I'm not aware of any formalism around this "ranking" of which types are most likely to be unintentional. Maybe we need one.

The only immediate solution I can see is to keep types simple enough that the user can fit the entire relevant type-space in their head (and in the IDE dialog!), so that they themselves can determine which part is actually "wrong" (as opposed to just contradictory).

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

#243

Post by gpderetta » Mon, Jan 11, 2021, 5:47 PM UTC

thesz wrote: post #209

jcelerier wrote: post #18

Earlier quoted context omitted.

> the types are really low level (missing basic things like tuples) and lack of type inference how far ago was this in the past ? C++ had tuples and type inference for ten+ years officially now - gcc 4.4 had it in 2009

C++ cannot have non-local type inference due to, you know, object-oriented part of it. This means that you cannot say something like this: auto sepulka; auto bubuka = zagizuka(sepulka); Because if zagizuka's parameter is a structure or a class, you have a selection of parents. On a contrary, you have a selection of descendants of the result type of zagizuka() for bubuka, each having their own copy or assignment const…

C++ doesn't have type inference at all which I understand requires constraint solving.

It has a much simpler type deduction system where the type of an object is deduced from its initializing expression, i.e. deduction always flows in one direction.

It is nowhere as powerful, but it does cover a lot of use cases.

One advantage (in addition to the ease of implementation) is that, except for circular definitions, there are no undecidable cases and it is not necessary to restrict the type system to prevent them.

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

#244

Post by pwm » Mon, Jan 11, 2021, 5:51 PM UTC

erik_seaberg wrote: post #34

unicornmama wrote: post #3

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.

Is is actually hard to hire for Haskell? You can’t just tell some random to learn it (because his head will explode), but my impression is that you’ll have candidates coming out of the woodwork who could never get away with using it before but always wanted to .

Single datapoint: The last time I posted a job ad (I was the hiring manager) I got ~40 good applicants within a week. I expected much less and got pretty overwhelmed.

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

#245

Post by Rusky » Mon, Jan 11, 2021, 5:52 PM UTC

jhayward wrote: post #158

Rompect wrote: post #69

Earlier quoted context omitted.

In contrast, Rust's compiler sometimes gives suggestions for changes which can often just be copied.

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.

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

#246

Post by gpderetta » Mon, Jan 11, 2021, 5:53 PM UTC

mjburgess wrote: post #203

tome wrote: post #160

Earlier quoted context omitted.

Hmm, what do you mean? Haskell is generally considered nominally typed (or rather types introduced by its newtype and data declarations are ...). "Structural typing" typically refers to things like polymorphic row types and polymorphic variants.

Sure, my mistake. I meant something looser. Only that the types can be analysed structurally (ie., pattern matched). In C++, etc. there's a "radical nominalism" in which the type was very opaque, ie., encapsualated.

It is complicated. Templates do allow some form of structural typing and the new-in-C++17 structured bindings do allow for decomposing and inspecting types (although this being C++ it is kind of awkward). Structured bindings are expected to evolve into full pattern matching in the future.

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

#247

Post by dehrmann » Mon, Jan 11, 2021, 5:55 PM UTC

KingOfCoders wrote: post #21

js8 wrote: 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've joined several companies, and getting into a Python code base was the most difficult one, because of the lack of typed method parameters. It was easier with Java and better still with Scala - same for Typescript vs. Javascript. I would be interested, is your Python experience green field or joining a large project? (just wanting to know, not implying anything on your part).

> getting into a Python code base was the most difficult one, because of the lack of typed method parameters

One place I worked used to be a Python shop, but had migrated most of its services to Java. Chatting with one of the engineering leads for a large Python system that had a lot of business logic, he said where Python actually fails to scale is lines of code and developers because lack of types makes it harder to reason about and harder to make changes safely. This obviously changed now that type annotations are a thing.

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

#248

Post by thedmstdmstdmst » Mon, Jan 11, 2021, 5:57 PM UTC

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…

I completely agree about your thought about emotions and the Spock-like emotional detachment and the importance of emotions in decision making and every day life.

I disagree that this is related to the original posted article about a company that has chosen as their first language Haskell. I do wonder how your responses would differ if they had chosen Elm originally and perhaps it is both you and I that should evaluate our emotions are why we even commented...

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

#249

Post by chc » Mon, Jan 11, 2021, 6:01 PM UTC

brundolf wrote: post #237

ashtonkem wrote: post #198

Earlier quoted context omitted.

Haskell error messages are far less verbose, but I find them hard to read. What makes it worse is that often the error message involves a lot of deeply nested types that were hidden from me before by library writers using an alias. So I’ve had a lot of “where did that come from?” moments.

I had this problem when being onboarded into a TypeScript codebase recently. Unfortunately I don't think there's a technical solution to it: the type system simply won't stop you from making types that are way too complicated (unless you use a language like Go where the type system is intentionally lobotomized, which obviously comes with its own problems). We're used to avoiding complexity when it comes to logic , bu…

The thing is, these types aren't usually complex in the way that logic is. Complex logic generally means lots of loops and conditions and such, maybe shared mutable state. Linear code that just calls a series of independent functions one after another is not generally considered complex, even though it may ultimately result in the execution of lots of code. What generally leads to these confusing errors is just simple types composed end-to-end. The problem is that while compilers are good at picking out the specific part of a function that's causing problems, they generally can't do the same thing with types, so it's kind of like if every time you got an exception, the entire module source was pinpointed as the problem.

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

#250

Post by slow_donkey » Mon, Jan 11, 2021, 6:02 PM UTC

thedmstdmstdmst wrote: post #235

IfOnlyYouKnew wrote: post #23

No, sorry, it has very little to do with technology. There's at least a dozen languages you could have chosen, and that others have chosen for any given use case. within some bounds, it makes very little difference.[0] 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 f…

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 be extremely hesitant to hire the services of this company entirely because they use Haskell and it'd be a nightmare to maintain after their contract.