Why I think Haskell is the best general purpose language as of June 22 2019 | Hacker News Reader

Why I think Haskell is the best general purpose language as of June 22 2019

philipzucker.com

101 pointsazhenley99 comments

Today's wildly unpopular reality check for language booster-ism reminds you that there are next to no applications written in Haskell for a purpose that isn't programming a computer. When we do this exercise we can't get to double figures and nobody had a meaningful explanation as to why that is the case for a language that has been around with claims of being useful as a general purpose programming language for more than 2 decades.

I do not have a satisfactory answer for this. But, nevertheless I want to use it. Why can't I use it? I can't get my friends on board. Have they tried Haskell and seen that it doesn't work? No. Have I had success with it? Yes. Why is there so much distrust of Haskell exactly? "Nobody else uses it. It's weird and hard." I can extrapolate this battle to one with business people with money on the line and see it falling flat a lot.

But perhaps Haskell is fundamentally ill suited to applications. I hope not. Other possibilities: A language's success may be more sociological than technical, Business factors dominate, success is totally random, who got there first, holdover opinions from eras of more constrained computational resources.

More answers for the same question: https://news.ycombinator.com/item?id=11907839

I think it is mainly sociological. Are basque, irish or croatian less useful to convey ideas than chinese or english? Not at all. Perhaps they might even be better.

It doesn’t matter.

What matters is who talks the language, what is written in the language, where can you be understood in the language.

In programming language terms, the important questions are: do I have a library for X? Is bug Y solved quickly? How many answers do I have in stack overflow? Do I get job interviews due to that word in linkedin? Can I pair with a random valley programmer to work a quick pilot over a weekend?

This is just completely irrelevant. Quality and popularity are independent concerns.

Independent from each other, but both relevant to adoption. For any meaningful project, it's better to use a popular language than an obscure one, no matter how good, because it's easier to find developers for the popular language, and easier to find people to support your application in the future.

But to be fair, they should be positively correlated. Unless the world has beaten us down into nihilism and we think merit doesn't even tend to be rewarded.

I'm sure they are although for programming languages that correlation seems to be particularly weak. But judging the quality of a programming language by its popularity causes a kind of distributed circular argument: People use a programming language (=it is popular), so we assume it is good. We use it which means it becomes even more popular, convincing other people it is good etc.

When making a decision, using popularity as an easy but noisy indicator for quality can still make sense. If you kept your choice secret, you wouldn't even cause any negative externalities. But here, we don't make a decision so I don't think popularity is an argument worth considering (when evaluating the merits of the language itself, popularity does affect ease of hiring of course).

Anecdotally, my father develops offshore process control interfaces for a large international oil and gas technology provider, written in Haskell.

Granted, I don't know a great deal about that work directly, but I often hear about use cases for Haskell programming.

Unfortunately I think it is hard to take a "Haskell is the best" article seriously with no comparison to Clojure or Ocaml. Personally I am skeptical that typeclasses + an expressive type system bring more benefits than i simple parallelism, an easy to use macro system and atoms/STM for state management. It can take programmers months to be productive in Haskell. It should only take a few days to be productive in Clojure. I think the cognitive overhead of having to deal with ADTs/Monads is too easily dismissed/disregarded.

My accounting of languages was not thorough. I picked very common languages and Haskell. I am also not sufficiently familiar with clojure to form judgement. I am skeptical that a language without a type system will scale in mental and project complexity well, but it might. Lisps intrigue me very much, and any language with passionate proponents is worth looking at. I am currently trying to learn OCaml and find it very nice. I think it may be more pragmatic than Haskell in many respects. Strictness is easier, grabbing mutation and side effects is easier (is it gonna hurt me later though?). I am concerned that the community feels smaller and learning resources are scarcer. I don't love the syntax (a quibble). I think it leads to less power of abstraction, either as a community aesthetic or perhaps as a language constraint. I would be perfectly content if my friends accepted OCaml. Perhaps I will change my mind and then you will find an article labelled "I (as of X) think OCaml is the best general purpose programming language" on my blog. Haskell is indeed hard.

You should have a go at F#. OCaml-like syntax, strong type system, and like Clojure sits in a large reusable ecosystem (in this case .net). Cross platform in dotnet core too.

I have lived my life entirely outside of the .NET and Windows ecosystem, not really eager to go into it. Godspeed F# though!

Well, its not windows anymore since dotnet core, but fair enough :)

I'm interested you think the Haskell community is bigger than the OCaml one. Without checking any sources, I would have assumed the OCaml has a larger community of people using it in production for a variety of things, and therefore would have have the libraries etc. for me to build my thing.

I suppose this is my bias - the only community I care about is the engineering side as supposed to my academic side.

Also look at ReasonML (and bucklescript). I have tinkered with it for Web front end and been very impressed.

I haven't figured out where on the internet OCaml people live. Maybe they have better things to do with their lives than proselytizing. There is very clear bias in my opinions and information. Jane Street is a very prominent industrial user for which I can't really think of a Haskell equivalent of that company size. ReasonML is a nicer syntax. Kind of seemed like if you wanna do ReasonML you need to know both OCaml and ReasonML though on a cursory glance.

In my opinion the worst thing about the Ocaml/ReasonML platform is that discovery of language features/syntax/functions is needlessly difficult. There is no Hoogle equivalent for OCaml. Module functors are powerful, but the type system is very strict so it can be frustrating trying to express what you want. There are some techniques that are rarely covered by books and are almost impossible to google for. By contract, I think Haskell's typeclasses gives useful guard-rails to composing "complicated" logic. Overall, as someone who has been programming full-time in ReasonML for 9 months now, there are too many times places where I still feel like a "prisoner" of the type system for me to advocate for it over Clojure. I need to do more projects with Haskell, I am hopeful the built in typeclasses can reduce the time I am "stuck".

>I haven't figured out where on the internet OCaml people live.

https://discuss.ocaml.org/

As well as #ocaml on freenode and r/ocaml on reddit.

> I would have assumed the OCaml has a larger community of people using it in production

Yes, I also feel that Haskell has a larger community among academia/bloggers, but much lesser community among actual industrial users.

There are dozens of professional high quality OCaml software used by industry: Facebook's linters, Xen stack, Coq, Frama-C, Boeing's static analizer, FFTW, libguestfs by RedHat, camlpdf, Liquid Soap etc.

With Haskell, it feels like there are significantly less industrial grade projects written in it.

Your skeptical because you haven't used both in a meaningful way. Your conclusion is biased because it's based off of heavy usage of one paradigm. To become unbiased to truly know or hate a language you must become proficient in it.

For what you say to have truly any validity you must use Haskell and an untyped functional language.

I agree.

Author here. This is deeply amusing that among all the posts I write, the rushed half cogent Haskell rant rehashed for the billionth time gets the most attention. I guess that makes sense.

I find that with anything I write. The considered post that took weeks gets no attention, but people latch on to my 10 second tweet

I'm a Lisp expert. Learning Lisp (a long time ago) blew my mind. Learning Haskell (recently) blew my mind a second time. There are some things I can express in Haskell that I can't -- at least not easily -- in Lisp. And that had never happened before to me, with any other language.

I’m intrigued - can you share an example?

I'm not the parent so I can't answer from their experience, but I will say that laziness in Haskell lets you write functions that cannot be expressed in Lisp without macros.

Some simple examples are when and unless, which work like if...then and if not... then.

In most languages, these would be control flow statements built into the language (or not) and could not be written by the user. In Lisp you could implement these with macros, with all of the caveats that apply. In Haskell they're just ordinary functions with all of the benefits of being first class values at runtime.

> Lisp without macros

Why even consider that? Macros are IMO the main reason to use a LISP. As you suggested, they allow you to model laziness, or whatever else you might desire.

Because macros are not first class the way functions are. You can't map a macro over a list the way you can a function. Haskell functions give you the power of lisp macros at runtime.

Macros are IMO the main reason to use a LISP.

It's funny that you say that. I've heard it before and it sounds great but from the time I spent in the Clojure community, people would always say "the first rule of macros is that you do not write macros!"

Automatic currying: Haskell does it; Lisp doesn't. You can do partial evaluation in Lisp but it's not as convenient. This makes Haskell more functional than Lisp and eliminates one use case (or maybe more) for macros.

Laziness: You can build infinite data in Lisp but again, it's not as convenient.

Monads: Possibly the most mind-bogglingly useful programming pattern I've explored in the last 20 years, and you can't completely build them in Lisp. You can get about 75% of the way toward monads in Lisp but that last 25% requires manual one-off coding because Lisp functions don't automatically know the types they return. Even using macros I haven't figured out a way to solve this problem.

On the other hand, Lisp gives you variadic functions like (list) (list 1) (list 1 2 3 4). Lisp catches it in a straightforward way when you pass too many parameters to a non-variadic function, or fewer than the required number of parameters to any function. (cons 1) is a plain and simple error rather than a correct expression that evaluates to an unintended (lambda (x) (cons 1 x)) term. Macros can provide a clear explicit syntax for partial evaluation in which everything is visibly delimited, like (op cons 1).

I think you're highlighting the downside of ubiquitous laziness. In a lazy world there's nothing wrong with (lambda (x) (cons 1 x)). But if you want to call this an error earlier, I agree that Lisp defaults in that direction.

I must do a different type of programming than the masses. 99% of all of the work I do is API calls, map/filter/reduce, and maybe some database persistence of simple objects/arrays and it has been this way for years. CRUD calls, data in -> data out.

I don't see how any of Haskell's crazy syntax would make my life easier compared to node.js

Haskell people claim that combinators and monads are clear, but in practice the code seems to be write-only. Each combinator might be simple, but that doesn’t mean that the result can be understood easily. And monads have the same problem, except they aren’t simple.

Javascript programmers seem to have no problem using a monad every day (promises), and they are huge fans of do-notation in the from of async/await. Imperative programmers do not seem to have an issue with the idea of assignment, why are monads problematic?

By "combinator" do you mean combinator as in the combinator pattern?

I have no idea what value your comment brings us except a way for people who already agree with you to give you upvotes, and what's the point in that?

getting people who already agree with me to give me upvotes is the whole point of this website

> Imperative programmers do not seem to have an issue with the idea of assignment, why are monads problematic?

This drive-by-question style makes it hard for me to know what your real point is. Are you saying that an assignment does the same thing as a monad? OK. That it is a monad? I doubt it; assignment doesn't have the right operators (you might argue that it does, but you'd have to really stretch it.) That it's just as simple and easy to understand as a monad? I call BS.

> I have no idea what value your comment brings us except a way for people who already agree with you to give you upvotes, and what's the point in that?

That kind of rhetoric is against the site guidelines.

> Javascript programmers seem to have no problem using a monad every day (promises)

Using (something similar to) a monad (Javascript promises do not form a monad) successfully is different than using the monad abstraction successfully.

> and they are huge fans of do-notation in the from of async/await.

Async / await is not monadic do-notation. Arguably, it has a somewhat similar relationship to the underlying promise abstraction that do-notation had to the monad abstraction, but they aren't the same thing.

> Imperative programmers do not seem to have an issue with the idea of assignment, why are monads problematic

Why are the two halves of this sentence connected to each other since they have no relationship other than the proximity they've been (bizarrely) placed in.

Yeah, you're right that in some manners JS's promises do extend the semantics of a monad (notably in its impl. of return) but it is a monad though:

function bindPromise(p, f) { return p.then(f); } function returnPromise(a) { return new Promise.resolve(a); }

Proof of the laws left as an exercise to the reader :).

But yes, you are correct that promises do quite a bit more than only being a monad, for example because of how they treat errors.

EDIT: I concede, I am wrong! https://buzzdecafe.github.io/2018/04/10/no-promises-are-not-...

Generally, I think people don't like Promises and async/await, since it is very goto like, but there's not a whole lot better currently.

I also think there's nothing precluding some Monads to be good ideas and others to be bad ideas.

Similarly, the delivery could have a big impact. So it might be the theory of it is good, but a better delivery in terms of programming UX needs to be used. So maybe the dot notation somehow delivers better then the do notation.

Having said all that, I like Haskell, better than JS.

Promises are not monads. neither are scala's future.

I don't use Promises much, but Generators is like monads (but not monads on a category of pure functions, like it is in Haskell; also, these "monads" in JavaScript are not pure monads); actually, two kind of monads:

  return x;  return x -> return yield*x
  return yield x;  yield x -> yield*x

(at least, I think it is; I may have made a mistake)

It's not write-only in practice in my years of professional experience :)

Likewise.

That said, I think there are some legitimate reasons for the impression.

For one, Haskell (not uniquely) lacks the distinction between statement and expression found in many languages. This means that you have a freer hand about "where you cut" when breaking up your problem. In a way this is good - the optimal choice may be better when you have more options. But it also means a lack of consistency and more to learn about how to do it well.

Haskell's syntax is unusual. Everything is a harder to follow when you still need to work to parse things. There is a frustrating space between knowing the syntax well enough to want to learn other things and being sufficiently fluent that the new concepts are the only hard thing.

There are habits to reading Haskell code that differ from those involved in reading other languages - a big one being knowing how the types flow through an expression and how to spot where they're pinned down in various contexts.

I personally do not claim that Monadic code is clearer to read nor easy. But I think it is ultimately worth it in that the TYPES of monadic code are clearer and compiler enforced. By combinators I did not necessarily imply punctuation operators like (=--><><) which I also get can get confused by. I mean very small simple named functions duplicate, inparallel, fanout, first, second these sorts of things from which you can build your tower of power.

I like Haskell types, generally, but I think that both the monad types themselves and the syntactic sugar over them are both extremely confusing both in theory and in practice

It can get quite bad, yes. I find the simple cases pleasant at least. a -> Maybe b is the signature of a partial function. a -> State s b is a function that can mutate state, a -> [b] is a function that nondeterministically returns many results. I think these are clear. When you need to grab for multiples of them, it gets hairy. This is a problem the community acknowledges and is trying to make better.

those three are clear - but the next most complicated ones (Reader and Writer) are head-scratchers, and any beyond that are just completely opaque. And that’s not even considering monad transformers!

Yeah. I think you have exposed my double think. I really WANT to like that stuff regardless of the facts, but I might not. Monads are not my favorite part of Haskell. They hurt. But purity and immutability is. I want these at almost any cost. And if monadic pain is the price, so be it. Does this explode my entire thesis that Haskell is a good pragmatic language?

Does it explode your thesis? No. It can still be a good language for those who want purity and immutability that badly. Also, it can be a bad language for those who don't.

And there's nothing wrong with wanting purity and immutability that badly. And there's nothing wrong with not.

I suspect that FP fits the way some people think, and imperative fits how some other people think. And I don't think there's anything wrong with that. I'm a fan of picking the tool that is best suited to the job, and the person who is going to be using the tool is one of the biggest components of "suited". I might even say, of all the languages that suit you, pick the one that best suits the task.

Could you elaborate on what you find puzzling about Reader and Writer (and maybe State)? I've always thought of those as "simple":

Their use is (seems?) straightforward - I have a context that can hand me a value, take values from me, or thread a state.

Also, they're "just" thin wrappers around common types. `Reader r` is `r -> a`; `Writer w` is `(a, w)`; `State s` is `s -> (a, s)`.

I'm interested whether you can unpack a bit where the difficulty seems to lie. Backgrounds differ and what's simple for one may be complex for another, without any judgement around overall capability.

In my experience working full-time with a medium size team on production software, those things were not confusing in practice in that setting.

Don’t take this too seriously. He essentially says in the intro he’s writing this to troll his developer friends.

And, here’s his first reason for liking Haskell:

> The number one reason is that there is something ephemeral that I just like. I am not naturally inclined to analyze such things. When I like a movie or don’t like it, it just happens, and if forced to explain why, I’ll bullshit.

Haskell is nice, but it has plenty of room for improvement. The duality of strict vs. lazy eval is not really treated in an elegant or principled way, for example - which is one of the drawbacks OP mentions in their blogpost. There are theoretical approaches (polarity, focusing) that might work well for this.

Interesting, thanks! There are many exciting possibilities for the future of programming. My point to my friends is that I actually think Haskell is a shockingly pragmatic choice right now, despite how much my goofing around implied otherwise.

I really tried with Haskell but for me it was just impossible to refactor code without rewriting the whole program.

I've been considering lately why that doesn't seem to ring quite true. I thought this for a time, then realized that a fair bit of this concern comes from lack of intuition.

When you started out refactoring and making changes to object-oriented programs, how much did you have to rip out and alter each time?

How did that skill improve as your designs became more thoughtful, as you began to see the seams and tailor your designs to fit those seams?

I believe the same would apply for Haskell: its seams are different, but the separated concerns that come from experience and intuition should allow you to follow those seams more closely.

Haskell takes serious effort to get used to and begin writing idiomatically. This should go without saying for most programming languages but it goes double for Haskell, because it's so different.

One of the things I've come to appreciate about idiomatic Haskell is the library pattern (for lack of a better term). A properly designed Haskell project should be a library, not a monolithic program, and the problem you're trying to solve becomes a one-liner after importing your new library. A great example of this is Xmonad, which works exactly in that way.

Why does Ruby always get the shaft? It is pretty easy to learn, VERY expressive and readable, extremely easy to write tests against and works great with the web!

And slow as a snail versus anything else.

Which doesn’t matter for most of the programs out there.

Given that one can be productive as Ruby, and still enjoy the benefits of AOT/JIT compilation to native code, I beg to differ.

Qualification: I was introduced to FP a number of years ago and have finally reached a point where I feel that I have a deep understanding of FP in general. In my mind, Haskell is the "best" language out there ("best" in that it provides the best overall gain when all tradeoffs are considered).

I'm no longer confident that Haskell is the "best" language anymore. I was recently introduced to a language that might be even better than Haskell: Dyalog APL. (https://www.dyalog.com/). Try it out yourself (https://tryapl.org/)

To explain why, I recommend watching Aaron Hsu's videos on Dyalog APL:

- Does APL need a Type System? (https://www.youtube.com/watch?v=z8MVKianh54) - This is actually a very interesting question that is more nuanced than upon first glance.

- Design Patterns and Anti-Patterns in APL (https://www.youtube.com/watch?v=v7Mt0GYHU9A) - The main takeaway from this video for me was the principle of "Idioms over libraries."

- Higher Performance Tree-Wrangling, the APL way (https://www.youtube.com/watch?v=hzPd3umu78g) - Or how to model Trees without using pointers by using "Inverted Tables." (An inverted table is a table where the columns are the rows and the rows are the columns)

https://web.archive.org/web/20190623200107/http://www.philip...

The article makes many good points about Haskell including cons: "Very difficult learning curve. Let’s get real. Haskell is a very confusing programming language to get started in for common programming tasks."

I can't avoid the comparison in my mind that Haskell is like Latin, spoken by priests, a very nice language Latin is.

"I have a tendency to joke about almost everything and have put forward that we use many interesting but not practical languages in the same tone that I suggest Haskell. This was a tactical mistake."

Cry wolf too often ot be an assh*le too often, and expect this....

Haskell is very, very funny. Coq brings tears of amusement to my eyes. I couldn't and can't resist. (shrug)

Programming languages don't live in vacuum, libraries, IDEs, supported OSes, and developer communities are also part of it.

I enjoy Haskell a lot, but trying to create a CMS, desktop GUI or a console game in Haskell? Good luck with the existing tooling and libraries.

What functional language would you recommend for something like a GUI application then? I have very little experience with such languages but am always looking forward to trying one when I get a chance.

There is none that can match the tooling of Delphi, C++, .NET, Java, Swift/Objective-C for RAD UI development.

Even the languages that target the JVM or CLR are not supported on the existing GUI tooling, forcing you to do workarounds.

So Scala, Clojure, F# can do it, but you end up having to save JavaFX or WPF layouts, while throwing away the generated code, and load them via library calls.

Or you write the UI layer in Java/C#/VB.NET/C++, while writing the rest as a library.

So at the end of the day you are forced to chose between RAD productivity or FP purity.

EDIT: I have naturally forgot Common Lisp, but for that you should make use of Allegro or LispWorks, not Emacs + FOSS Lisp compiler.

I love Haskell.

But I can’t understand why record syntax is 1) completely necessary to write manageable type systems and also 2) known to be half-baked.

I also wish the community was better at embracing newcomers and teaching them one step at a time.

Other than that, I have no complaints.

"The number one reason is that there is something ephemeral that I just like."

I think this is the most honest statement in the post.

Most of the mentioned C++ issues, for instance, are also Haskell issues (in a different form).

They are similar in that they are both kind of big languages with many features, and a reputation for difficulty. However, Haskell's reputation is one for difficulty on how to do anything at all but once you do the angels sing, while in C++ it is difficult to do anything right. I think the positive lists diverge significantly, and I don't really think of the languages as being similar at all.

I didn't mean that C++ and Haskell are particularly similar, but that if the feature set of C++ is "huge" the even more arcane Haskell language extensions are in the same league, that legacy features that shouldn't be used in C++ are no worse than multiple half-baked incompatible libraries for the same basic purpose in Haskell, that if C++ is full of footguns Haskell is full of footgun categories, that if C++ syntax is verbose Haskell syntax is bizarre and misleading.

Evidently, being in love with a programming language is an obstacle to comparing it honestly.

It is very, very, very difficult to be in love with a language and compare it honestly. I don't think I've ever seen anyone successfully do so. I don't agree that Haskell has as many footguns or as much legacy cruft, but if you've found that to be the case, I value your opinion.

> I don't agree that Haskell has as many footguns or as much legacy cruft, but if you've found that to be the case, I value your opinion.

And moreover, please write a blog post or even short comment about it, because few Haskell footguns are obvious to me and I would appreciate the warning!

A short list off the top of my head:

It is very easy to get over eager and use more abstraction than you need or can handle. This is perhaps the worst of them.

Strings shouldn't be [Char]. OverloadedStrings should be the default.

There are partial functions in base. head for example

It is easy to spring space leaks due to laziness.

Relatedly, choosing between foldr foldl foldl'

Incomplete pattern matching (which will be a warning) or sometimes default _ casing. If you add to the type, the compiler won't save you.

It is not necessarily so obvious to a beginner when you are doing tail call recursion.

Maybe overuse of typeclasses when records work better?

Over use of Template Haskell can raise an eyebrow.

A minority of extensions are ill advised.

All in all, I think the level of footguns in Haskell is in a different universe than C++, but I am trying to see it from the other perspective.

http://dev.stephendiehl.com/hask/#what-to-avoid http://dev.stephendiehl.com/hask/#the-dangerous

Thanks and agreed!

However, I was more asking for HelloNurse's opinion, since I can't think of any Python footguns that are on the same level as C++'s. The ones you cite are more on the level of Python's.

A nice article from slightly over 1 year ago https://lexi-lambda.github.io/blog/2018/02/10/an-opinionated... was linked on HN today.

It explains organized footgun management, with a discussion of what language extension should and should not be enabled, and some specific library threats (e.g. String and ByteString).

That is an excellent article. String vs ByteString is a beginner footgun in Haskell. It won't make incorrect or crashing code, but it will show up as poor performance on text heavy processing.

Does the Haskell compiler spit out useful concise, meaningful error messages? Compilers often have some pretty verbose output for what ended up being a (relatively insignificant feeling) typo.

It depends. After having gotten used to it, I can usually barely glance at an error and figure it out. I am basically satisfied with ghc errors messages, although they could be better. Sometimes it takes real head scratching. I think languages like Haskell give the compiler enough information to make insanely good error messages (At compile time mind you! Unlike python/javascript/etc). Elm apparently has some of the greatest error messages in the world. I think it is significantly better than C++ errors.

It's trying hard - usually it's really nice. But sometimes the amount of signature inference kills the meaning. Most of the time you get an error like A is wrong because B that comes from C. And a lot of the time it's immediately clear what the problem is. But sometimes I either don't know why would B ever get the signature it did, or why would C ever be relevant for this piece of code.

Haskell's compiler messages can be daunting for beginners but in the hands of an experienced user they can act like a surgeon's assistant, putting the right tool in your hand without you having to go and find it. This is the magic of types and features like typed holes, for which the compiler will suggest things in scope that will fit!

Haskell programming at its best starts to feel like you're putting together a jigsaw puzzle, and everything "just works" once you get it to compile.

"functional programming is weirder than imperative programming."

Honestly, it's hard for me to take seriously any post/comment including this.

I think that julia is giving haskell a run for its money. I find it more productive for numerical mathematics (maybe not formal methods or abstract algebra).

The title says "general purpose language".

I wouldn't call haskell general purpose. He lists a couple of areas he cares about.

I think Haskell is more general purpose than people give it credit for. The domains I care about are general web dev for stuff, formal methods, and numerical computation. I do not use Haskell day to day for numerical computation (I tend to use python, which I very much like), but it does bring to mind interesting ideas http://www.philipzucker.com/reverse-mode-differentiation-is-... https://t.co/HhUNpl0T5m

I think there is a bit of a problem with the definition of "general purpose" here, it's very dependent on the eye of the beholder. What might work for web programmers might not be of much use to more desktop centric programmers.

How portable is Haskell? Does it have a wide range of graphics/sound/UI libraries available? Are those libraries available on a large number of the platforms that Haskell runs on?

This are the kind of questions that many C/C++ programmers considering alternatives might ask when considering whether other languages are general purpose enough for their needs.

I think you bring up very valid points.

I agree on the promise (perhaps already realized) of Julia. The library ecosystem there is so, so incredible. The language is custom formed to it's intended domain of numerical computation. I've been trying to ween myself off of python for these purposes. Needless to say, my pushing of Julia also meets with a great deal of pushback. I have also had some setbacks. The 1.0 changes hurt my learning a bit. I don't like how it doesn't play well with brew. I feel like it is forcing me a bit into a Jupyter notebook style, which is not my favorite. All of these are small quibbles ultimately.

Use juno. I was in the same sitch re 1.0 update, it's gotten better. Why do you need brew interop?

A small quibble. I hate downloading binaries from websites. I hate ever going outside my package manager. I want to be able to get the latest version. I think many people prefer Julia the way it is.

You can use brew https://julialang.org/downloads/platform.html

Welp, my apologies. I'm a doof.

haha. Hahahahaha. hahahahahahahahahaha. Okay bub, here's your troll card, you are officially a member.

Posting like this will get you banned here. Will you please review https://news.ycombinator.com/newsguidelines.html and stick to the rules?

Reply on news.ycombinator.com