Haskell is famous for it's quite an academic nature. But the ecosystem has drastically improved in recent years, so that that image is really outdated by now.
E.g. with Haskell Language Server we have nice autocompletion. Recently dot-notation has been added, so you can now write `someValue.someField` as in other languages. And the documentation is improving as well.
If you're doing web development, a good starting point is IHP (https://ihp.digitallyinduced.com/https://github.com/digitallyinduced/ihp). IHP is Haskell's version of Laravel/Rails/Django. It's really a superpower to have Haskell's type system combined with the rapid development approach of Rails :) (Disclaimer: I'm founder of the company that makes IHP)
I think of Haskell along with other languages that allow for shipping small, single-file binaries with a garbage collected, high level language. The straightforward alternatives I'm aware of include Nim, OCaml, Crystal, and Go.
Go is the most popular of this set, but to me seems like it barely qualifies as "high level". On Tiobe, the next most popular language from this set after Go is Haskell.
I like Haskell just fine, but what I really care about is "a more high level GC'd language than Go that ships binaries".
I think it's trying to stay fairly close to C, with additional features selected judiciously. Systems programming was identified as an important design goal (e.g. having close control of memory layout).
I work for one of the companies on the list, and touch Haskell every now and then on the job - maybe it's because I worked with quite a few functional languages when I studied for my degree (Artificial Intelligence, started in 1998), but I really really enjoy it.
Hey, at Comhlan Ltd. we have a few projects in production built with IHP. The largest public facing one is a visitor booking system for an irish regional hospital group we've had out since January. Happy to answer any questions but short answer is GHC+nix+IHP has made for a really robust development/deployment experience. (Disclaimer: I'm founder of Comhlan and we are a IHP platinum partner as well).
Security in Haskell isn't especially better than any other general purpose language. You do have a lot more tools to help though. For instance, you can make your web app fail to compile if you accidentally try to serialize sensitive information to JSON or plaintext. GHC will tell you exactly where you almost had a data leak.
It's actually a bit harder than you're implying, because any request coming to the server could have sensitive information in it.
But, yes, wrapping your data helps solve some of the problem in any language. For instance, in Java we hold passwords from requests with a Password class rather than with a String class, whose .toString will return "xx" rather than the actual password.
Security is resilience with respect to your threat model.
The usual security objectives are confidentiality, integrity, and availability.
Nothing is "secure" forever and ever. For each objective you need to state some assumptions that are required to uphold it.
Haskell allows you to express more assumptions in code, not just comments, to be enforced at compile time.
And with some careful handling Haskell types provide a solid foundation without going into full deductive verification mode.
One example of security is not munging strings together and shipping it off to the database or some other "eval" with full privileges. A programming language with lightweight static types makes it easier to parse outside data into a typed representation, then transform/evaluate/compile as necessary. This is of course Haskell's bread and butter.
Your best bet is probably to use VSCode + Haskell plugin, version 2.0+ (which handles the installation of everything via GHCup, I believe), barring any macOS-specific problems I don't know about.
That's the setup I use on Windows and Linux, and it's great
Our backend at Lumi (W15) is all Haskell. We’ve been happily building with Haskell since 2016. Lumi is making the world’s factories accessible online. The transactions that occur on Lumi are large and typically non-returnable because all of the products being manufactured are custom, mass-produced items. Haskell helps us in all kinds of ways, including performing safer migrations, and creating DSLs to define specifications of manufacturable products.
Just to be clear, the list is not supposed to be exclusive -- there's a lot of companies using Haskell out there. :)
I just wanted to feature some of the biggest names and some of the cool use cases.
BTW, if you're interested in Haskell case studies, we have a series called Haskell in Production (https://serokell.io/blog/haskell-in-production) with interviews with Haskell projects that covers more ground.
I've attended a few Haskell conferences over the years and the make up tends to be fairly evenly split between PL researchers, defence, aerospace, and finance. I recall the food stop after an event at Imperial where our table was twenty-ish people from Airbus, Barclays, Lockheed, QinetiQ, and Thales.
If you're looking to work in Haskell there are some avenues to hunt down. Same caveats as with Standard Chartered and Meta mentioned in the article, there is Haskell but it is scuttling around in the corners not flowing from everywhere.
If you know Haskell and people ask for experience, just write a program on your work computer and out it in your resume. If they need to see that to believe you have professional Haskell experience, then just give it to them. Programming interviews are pretty lame, so help them be less lame. You still need to prove your competence. And they’ll say anything to get you on board, so you’re just playing along.
I've only worked at (several) places not on that list, but I will say that despite everyone's snide remarks here about how nobody uses Haskell..I have been able to immediately get multiple Haskell interviews whenever I've wanted. Ping some recruiters & former coworkers on LinkedIn and it's done. Niche languages have their advantages. And despite "there only being dozens of us," there's plenty of money in Haskell out there to make a good living (no passion paycuts). Gotta know Haskell first tho ;)
What about reforming existing engineers? Especially ones that have gone down the operations path for several years and want to get back to contributing with code?
Edit: I was asking kind of flippantly, but actually upon reading your team and product seems quite interesting. Would you be up for a chat?
Apple and google have both launched full blown general purpose programming languages, enough of them that I can't speak broadly about them all but they all have some degree of following and support outside those orgs.
So has MS for that matter. I don't see why supporting the compiler of a relatively niche language counts as funding and research but those things don't.
I don't think your argument holds: if universities were to stop producing research and instead started producing code, that would raise a lot of eyebrows.
MS has produced a lot of pure research. Google and Apple produce mostly code.
I guess it depends on like "what is the output of research?" which I admit is probably hard to define and definitely not clear to me.
But your comment seemed to assume "compilers are the output of research" so I went with that.
I don't know anything about microsoft's research or apple's or google's either. But again I just don't understand the distinction between "research" and "code" that's being made here. There might be a useful distinction there but you're not making it.
It's really weird that we all don't just use one language. Can you imagine if different contractors building houses in the same neighborhood all spoke 7 different languages?
Sorry, the bathroom's gonna be later than we thought, we're having trouble finding a plumber who speaks Esperanto. And the deck's actually slanted because the framing team spoke a different language than the deck-building team so their interfaces weren't designed together. The roof is also porous now because the roofers' language didn't easily support water-tightness. Also, we need a crane to lift our toolbox since we need a duplicate tool for every language and now it weighs 5,000lbs.
I think it's really weird that we use different languages when building a house. Sorry, the basements gonna take longer than we thought. There's wiring issues and we don't have anyone available who speaks electrical. And the bathroom's gonna be another 2 weeks since we need to call in someone who speaks plumbing. Not sure why there are so many different kinds of plumbing pipes, if they were all PVC i'd be able to do it myself.
But... builders do speak different languages. Plumbing, electrical, framing, drywall, painting, flooring, finishing, foundation pouring, hvac, landscaping, ... these are all very different fields with people that specialize in a narrow subset. And sometimes they do have miscommunications that screw things up because they don't all understand what everyone else needs.
Its more like "Our pipes will be _at least_ 2 weeks late, because we can't find a guy that knows how to use a MIG welding machine, and we won't fork for a TIG one".
Programming Languages are known, not carried, they weigh nothing.
Using a single language for everything would be terrible, like using a Chinese Army Survival Shovel-fork-axe-spoon-saw-pan-ruler-hoe-hammer to build a house, it'd do everything, and do everything terribly.
> It's also literally impossible to pick just one - you would fail at the JavaScript vs C problem.
We could just make one language that had the features of both javascript and C. We literally can invent anything we want. A n y t h i n g. We have to throw away all our preconcieved notions about what's possible and just make the world the way we want it to be / a way that's better than we have now
In the same sense we could invent a single appliance that performs all kitchen tasks, rather than having a separate refrigerator, food processor, stove, oven, etc.
And people will call your language "bloated", and say "I only need those specific features which will allow my language to be developped faster/faster to compile/easier to learn/etc" and we're back again to multiple languages. Of course your simple language will then grow, gain more functionalities (since eitehr you will add them, or you will be replaced by something that adds them), etc. Then people will find your language bloated, create a new simple language. We've been through this cycle many times already. Same with frameworks (micro vs fully featured), databases (SQL vs NoSQL), web stuff (server rendered HTML vs JS).
relevant: https://brython.info/
Brython is designed to replace Javascript as the scripting language for the Web. As such, it is a Python 3 implementation
I don't think spoken language is the equivalent metaphor here. There's a grammar and toolchain for plumbing problems, and a different grammar and toolchain for framing problems. The fact that you can't use a nail where a machine screw is supposed to go is a language incompatibility.
Yeah and even then they have different goals, histories, and incompatibilities. Pipefitting and residential plumbing are completely different domains despite the abstract similarities.
Our tools are relatively cheap to build and test compared to other fields, so we have a lot more of them.
when working on a large code base, I found it productive to take a slow walk outdoors to some urban construction site, with all of the action that involves. Also I have done serious construction myself in the past. Construction terms, analogies and tooling names make a lot of sense to me when thinking about software systems some days.
Oh trust me, I get it. I think it can be a helpful tool, certainly; but making an equivocation between the two, then holding a trial for the discipline of software engineering for performing poorly in a rigged comparison strikes me as a poor use of one's time.
That's the point that I was trying to make (and likely, what I should've just said in the first place.)
https://kittyhawk.aero/ used to use Haskell to develop their flight control software. The strong type system of Haskell is touted as ensuring that entire classes of bugs can't occur (like accidentally adding different kinds of quantities together or getting the units wrong).
Unfortunately Klarna is consolidating tech stacks on Java/Javascript. Erlang/Scala/Haskell/Clojure (ordered) will probably stay for a couple of more years, but these will over-time be replaced by new systems in Java and Javascript. The main reason is ease of hiring, but also to be able to move engineers and systems around easily within the organisation.
I worked there a few years ago. I applied for a Haskell role there. During my interview I was told it was a Scala role.
I became the only Scala dev in a team who wanted to rewrite the codebase in Typescript.
I ran out of work to do there at times - while the team was still growing. The same manager who couldn't find work for me, after announcing that the team would be splitting because it got too big, was dumbfounded when I suggested we stop hiring more people.
I had a few colleagues who had worked there longer than me, but didn't have any code in prod.
I feel stupid even writing this, but it honestly seemed that having more developers was more important than the product itself.
When VCs give you money you're required to spend it.
Otherwise what the hell did you go out and raise more money for? More engineers is the easiest way to spin wheels and make money go away without a lot of questions being asked.
It's one of the sad realities and cargo cults that we all participate in.
Getting hired to a Haskell or Elixir/Erlang role in a bootstrapped company is the dream but there's only so many of those jobs out there right now, sadly.
I honestly believe that removing Typescript/JS would actually benefit the software engineering quality in the company, to me it's there just because the pool of people is large. I would prefer quality over quantity, but I'm not a manager ¯\_(ツ)_/¯
As mentioned on https://github.com/erkmos/haskell-companies, IMVU uses Haskell pretty extensively. Originally the server-side portion of the product was almost entirely PHP3 (with some bits of perl on the backend for things like Memcached) and then over time large portions were rewritten in Haskell (one service is/was Erlang, I think.) Part of the motivation for this was the incredible pain of the forced transition to newer PHP due to all the compatibility breaks.
If you had some time to put your thoughts in a comment/blog post, I'd love to read about your experience. This is the kind of feedback from which the community would benefit.
We are the global pioneers of an OECD endorsed disruptive fintech platform that enhances your parents pension wealth by 87% with Zero added risk according to ETHZurich (Einstein's alma mater).
OH, and I should mention that we are hiring mathematicians/statisticians.
It's quite dated at this point (14 years since the first/only edition) but Real World Haskell was written to be such a book and a lot of it still mostly holds up despite being dated: http://book.realworldhaskell.org/
Also, it might be a better list if the companies mainly used haskell. Having Meta or Microsoft doesn't mean all that much as they probably use every language under the sun somewhere.
Fwiw, we (mercury.com) use Haskell exclusively for our backend, and employ something like 75 engineers. Haskell isn’t widespread for sure, but this list is by no means exhaustive.
E.g. with Haskell Language Server we have nice autocompletion. Recently dot-notation has been added, so you can now write `someValue.someField` as in other languages. And the documentation is improving as well.
If you're doing web development, a good starting point is IHP (https://ihp.digitallyinduced.com/ https://github.com/digitallyinduced/ihp). IHP is Haskell's version of Laravel/Rails/Django. It's really a superpower to have Haskell's type system combined with the rapid development approach of Rails :) (Disclaimer: I'm founder of the company that makes IHP)