Hacker News Reader

Hacker News

Comment by egonschiele | Hacker News Reader

Parent Full thread

egonschiele

Off the top of my head:

1. Built-in concurrency makes your backend scale better.

2. Type system reduces bugs in your code.

3. Mature libraries for web development: frameworks, templating languages, ORMs.

I'll admit there are some downsides:

1. Harder to hire devs that know Haskell.

2. Smaller community.

But it seems like those are getting resolved quickly. The Haskell community is growing, and there is better documentation and support thanks to companies like FPComplete. O'Reilly has been publishing a bunch of books in Haskell, the Stack Overflow community is active and helpful...

View on HN

1. Concurrency makes applications scalable, not fast. 3. I don't know what mature means, but they are not used by high-profile applications. 1'. This is probably balanced by their high-motivation to work on a Haskell project.

>I don't know what mature means, but they are not used by high-profile applications.

Does that mean that if my website becomes "high-profile" next month haskell will have suddenly become a better language than it is now, without the language changing at all?

It's evidence that it's viable, whereas now it might be great in theory, but there's no direct evidence that it works in practice for large-scale projects.

That seems like a very bizarre way for technical people to behave. "I'll assume this general purpose programming language must have some weird problem that somehow makes it unusable, but people can only find out about that problem if they write a popular project in the language". Why not assume every general purpose programming language is capable of being a general purpose programming language baring evidence to the contrary? Shouldn't tech people be capable of examining the language and determining if there's evil "large-scale" goblins lurking within?

Systems in general tend to have goblins that reach out and bite you when you try and scale them too hard. Better to have a clearer picture of where there be dragons - maybe or maybe not "better enough" when weighed against other advantages and disadvantages, but "mature" is a virtue.

Mature is a virtue, but "popular app was written in language X" isn't an indication of maturity, it is an indication of a particular app getting popular. The whole reason I used the term goblins is that without specifying what sort of problems people are afraid to run into, it is just vague, hand wavy nonsense. Does someone seriously think haskell is going to somehow "not scale" but ruby would have? Programming language choice has far less to do with scaling than the design of the application.

"Popular web app" implies a level of traffic - and thus demands at scale - that most other domains do not have. It's not the fact that someone was able to make a Haskell-based web-app popular that is indicative of much, but that the Haskell-based web-app stood up to popularity on the web that gives some reassurance and thus helps establish the maturity of the ecosystem.

But reassurance of what? That's exactly what I mean, what kind of evil spirits do people believe are going to make a general purpose programming language incapable of being used to write a web app? This is the exact same FUD that people spread about ruby when rails was starting out. It strikes me as a very lazy, unintellectual way to approach things. "I'll just assume magic gremlins make this language bad until someone else proves otherwise". And then inevitably someone else proves otherwise and it becomes "that proof isn't convincing enough". Make it explicit for me, how many page views/month do I need before haskell has been declared gremlin free?

You're making a binary distinction. It is not a binary thing at all. Any large software system has a lot of moving parts. Any of these parts may have bugs, some of those bugs may be significant. There's also the possibility for different pieces of functionality interacting in poor ways.

The more a piece of a system has been used to build things, the more confident you can be that it doesn't have bugs that will be getting in your way. The more similar these things are to what you're planning on doing, the more confident you can be that things won't get in your way. What the thresholds should be depends on the particular tech, your particular project, and the world around it. Maturity is absolutely something that should be traded away when there is sufficient reason.

This is by no means lazy or unintellectual unless you're using it as an excuse not to work (or learn) or not to think.

Regarding your implicit concern about no one being the one to step up and shoulder the burden of trying new things in production, I reiterate my assertion that maturity is just one factor that should be used in determining technology choice, and there's nothing wrong with those first venturing to new things those who have the most to gain by their use.

For what it's worth, I'd like to note that I am presently writing a web application in Haskell, so I obviously don't think it's a poor fit for all web projects.

I am not making any distinction, binary or otherwise. I am saying that dismissing languages as "not mature" based on a perceived lack of popular apps written in that language, without defining what "mature" means or what problems the language might be hiding, is lazy and unintellectual. "Not mature" is just a more socially acceptable way to say "I have no actual reason to dismiss this, but I will dismiss it anyways".

You were asserting that I was making a binary distinction:

"Make it explicit for me, how many page views/month do I need before haskell has been declared gremlin free?"

There is no such thing as gremlin free. As something is tested in various environments, we become gradually more confident that there are no gremlins.

A gremlin might look like:

I spent weeks building this system, and now I realize that it can't ever really be robust because I built it all around lazy IO and have no good method of controlling where exceptions happen when they are triggered.

That would be an example of Haskell - as a language and ecosystem - being immature. This is not what anyone recommends doing anymore, because the people have realized there be dragons there. Dragons are worse than gremlins, as it happens.

The odds of similar troubles go down over time, especially for areas anyone has done work near.

I'm sure we could quantify, with sufficient data, but I don't have the resources and I'm not sure it would be a good use anyway. How many resources did you put into investigating the other pros and cons, when you made the decision to use Haskell? Like anything else, it's a concern I give some thought, and weigh against other concerns, investing as much time into it as seems appropriate - estimating from what I've observed on other projects, what I've heard from other people, &c.

Just because I acknowledge that something can be a legitimate concern doesn't mean I'm lazy and unintellectual for not pouring way more resources than I have into it - eventually we have to get work done, and doing yet more investigation of the details of a particular decision has diminishing returns.

You really seem to just want to argue about nothing. Your position is a strawman. The original poster I replied to was literally saying "can't use haskell cause academic norealworld". That is lazy and unintellectual. I wasn't talking to you, so constantly trying to re-frame my statements as though they were directed at you is not productive.

"You really seem to just want to argue about nothing."

No, I want to argue (constructively, I hope) about things people say that I disagree with, in the hopes that at least one of us learns something.

"Your position is a strawman."

This is nonsensical. I'll assume you meant "You are arguing with a strawman." I'm not sure that's the case, but feel free to clarify any of your above arguments if you think I misinterpreted something.

'The original poster I replied to was literally saying "can't use haskell cause academic norealworld". That is lazy and unintellectual.'

On reviewing the thread, I understand you to be speaking of part 3 of https://news.ycombinator.com/item?id=6109593

What was literally said was, "I don't know what mature means, but they are not used by high-profile applications", where "they" referred to "3. Mature libraries for web development: frameworks, templating languages, ORMs" from the parent comment. Is that right?

I would say that "can't use haskell cause academic nonrealworld" is a substantial mischaracterization of that, and the parent point is something I would agree with - so far as I am aware we have not seen the haskell web frameworks exposed to tremendous real-world load.

"I wasn't talking to you, so constantly trying to re-frame my statements as though they were directed at you is not productive."

You were replying to me, so I'm confused who you were talking to. If you simply mean you weren't talking about me, I'm not sure I agree, as you seemed to be speaking in broad terms about those who might hold views I think are at least reasonable. I didn't so much think you were calling me out specifically.

Generally, this comment seems disingenuous at best, and I may not reply if you follow up, unless you raise the level of discourse - your earlier comments were better.

Haskell has been used in large-scale projects. There's an algorithmic trading firm, Tsuru Capital, that uses it exclusively, in fact.

You might also be interested in the work of Galois. They've got some slides on Haskell in industry: http://www.scribd.com/doc/19502765/Engineering-Large-Project...

Regarding 3, I wouldn't regard many of the technologies used in many high-profile applications, like Node.js, as particularly mature. They're just popular. They have mature communities surrounding them, but many of these technologies are far from technically mature and/or rock-solid.

Reply on news.ycombinator.com