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

231–240 of 297 posts

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

#231

Post by leshow »

steveklabnik wrote: post #218
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…

> why doesn't it just do the cross-function inference It could! This is an explicit design choice. There are a few different reasons. They're all sort of connected... In general, Rust takes the position that the type signature is the contract. If you inferred the types on function signatures, changing the body of your function could change the signature, which means that breaking changes are harder to detect. It also…

> I am gonna handwave this one slightly because I don't fully remember all of the details, but full program inference and subtyping is undecidable. Rust doesn't have subtyping in general for this and other reasons, but lifetimes do have subtyping. I am sure this would get ugly.

Correct. Haskell is the only language I know of with globally decidable type inference, and uses the similar hindley-milner method as Rust... but no doubt some of Rust's language features can break global inference. In Haskell, many common language extensions can also break global inference.

I think if Haskell was written today they probably wouldn't pick global inference as a goal, Haskell "best practice" types the function boundaries in the same way that Rust enforces.

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

#232

Post by leshow »

UweSchmidt wrote: post #109
nicoburns wrote: post #89

Earlier quoted context omitted.

That doesn't stop you having to type e.g. String foo = "bar"; String baz = foo; The `String`s can be completely avoided in languages with type inference because it's obvious that a string literal is a string.

Is it really that painful to write "String" each time? You spend at least a fraction of a second anyway to verify that you're writing the right thing, to reconsider if you should use an object or constant or refactor the function to work with a Boolean instead of a naked string; why is writing out the type such a big deal everytime this topic comes up? I remember my first attempts at programming and being annoyed tha…

> I remember my first attempts at programming and being annoyed that I can't add a string and an int; ever since that little bit of housekeeping of using types made sense to me and I can clearly see how it eliminates entire classes of errors.

Type inference doesn't make these errors go away.

And about your other point, it's unfair to look at just a simple case of writing "string" or not as the only thing inference provides. Although I'd argue that leaving out types where possible helps readability-- it's really the more elaborate cases or intermediate steps during a longer transformation that inference helps with. Not to mention the fact that inference in closures is also really nice.

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

#233

Post by FpUser »

mjburgess wrote: post #139
FpUser wrote: post #96

Earlier quoted context omitted.

I have zero problems using type inference, tuples, etc in my code. Other developers I deal with and who do use C++ have no problems using those "novel" concepts either. So I am completely at loss about what type of culture you are talking about here. It looks like grasping at a straw type of argument to me.

I'm talking about all libraries and books written since it's development up until the early 10s; and of all those teams, libraries, and code which are legacy. Haskell has never had a decades-long history of 'compiler-oriented programming', ie., excessive declarations, and so on. The idea that C++ has a haskellish culture is patently absurd, even if the vanguard regard itself as presenting tending toward that directio…

I am in no way implying that "C++ has a haskellish culture". Neither I would consider it of any advantage. All I said is that modern C++ programmers have no problems using the concepts. There is plenty of those that are used in gobbles of libraries as well. Sure old libraries do not have it but so what?

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

#234

Post by adamch »

elephantum wrote: post #187

It seems like you can substitute Haskell to Rust in almost every point they make. (Or with many other great options)

Yes, this was my immediate thought too. I love writing Haskell, but Rust has become my daily driver, both at work (Cloudflare) and personal projects. It gives me the excellent type system, better domain modelling, great ecosystem (serde, actix-web, rayon, reqwest, diesel, tokio) and performance.

I've basically traded away some nice abstractions (functors, monoids etc) for the ability to debug error messages more easily, and not have to convince people to learn/support an obscure language. Good deal IMO.

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

#235

Post by thedmstdmstdmst »

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.

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

#236

Post by thedmstdmstdmst »

oblio wrote: post #106
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 think his point is that there are N languages that are performant and they could have probably chosen any of them to achieve their goal, so the choice is primarily aesthetic.

The article doesn't say they have exhausted all languages, just that it is their first choice. Not their only choice but first choice.

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

#237

Post by brundolf »

ashtonkem wrote: post #198
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…

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, but maybe there's less awareness when it comes to types. Maybe what we need is to have a bigger conversation around that so people realize it's something that needs to be on their radar.

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

#238

Post by mattnewton »

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).

For new python work that might grow, I highly recommend pytype annotations. It’s not perfect but it’s as close to the best of both worlds that I have ever seen in production.

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

#239

Post by dkersten »

pjmlp wrote: post #196
dkersten wrote: post #190

Earlier quoted context omitted.

Modern clang (usually, there are edge cases) gives pretty good error messages over all. And like you point out, if you use constexpr you get even better messages. Hell, I watched some cppcon videos over the weekend and learned that clang can even detect out of scope access of temporaries when in a constexpr (but not otherwise sadly), and also that in many cases, a lot more of a program can probably be constexpr than…

Jason Turner has very cool talks, check the C64 one if you still haven't watched it.

I haven’t watched that one yet, thanks for the recommendation! I’ll give it a look tonight.

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

#240

Post by bcrosby95 »

WraithM wrote: post #146
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 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.

> in the large

At what point do you feel like this line is crossed? "In the large" can mean different things to different people.

Post reply on HN