[taylodl]

Rust is not a great choice for startups!

In fact, NO LANGUAGE is a great choice for startups! You don't choose languages depending on whether you're a startup! You choose languages based of the problem you're trying to solve, how fit the language is for solving that particular problem, the ecosystem supporting that language, and the availability of developers who are experienced with that language.

Rust just may be the best choice for your startup, but it's not necessarily the best choice for all startups - in fact it's probably not the best choice for most startups! That doesn't mean there's anything wrong with Rust, it just means Rust isn't the right tool for the job most startups are trying to tackle. If it is the right tool then absolutely you should use it!

[StefanHamminga]

I've seen this in action: A startup I did consulting work for had a "genius" who convinced management that everything should be written in Haskell. As a consequence building a team was painfully slow, so slow that some guy in a weekend recreated in node.js what their 15 people team had painstaking put together in 3 months. Turns out doing a web service with tools meant for it was better than "everything should be functional".

[taylodl]

Unpopular opinion - Haskell was intended for research and learning, not so much for mainstream production code. I'm not saying you can't use Haskell for that purpose, but you should think long and hard before doing so. If the answer is still yes then go back and make sure you've thought long enough and hard enough! :)

[JoelMcCracken]

Haskell is fine for production code. You just need to know what you're doing, and not go crazy with abstraction.

[akhmatova]

You just need to know what you're doing

The problem is that there just aren't that many people who choose to invest in learning Haskell -- or for that matter, the essential-to-master nooks and crannies of Rust. And the learning curve to get there is intrinsically steeper that for, well, all those "dum-dum" ducktyped and/or mostly procedural languages one imagines you don't particular care much for, now do you.

Of course it's known that some shops, like Jane Street, have gone whole hog on FP and have managed to do all right, it seems (even arguing that "the fact that the learning curve for our bread and butter is significantly higher than for the usual college-taught languages is a feature, not a bug").

That may work if have the same brand recognition (not to mention salary and bonus pool available) as Jane Street. And even then, it's not exactly proven that large-scale FP worked out so well for them. Just that they didn't tank.

But if you don't have their clout and resoures... from first principles, you should probably think twice before making the same bet that they did.

[JoelMcCracken]

> now do you Depends. I like JS ok. I really like Lisps. I miss doing Ruby sometimes. I've been doing more Python lately and find it rather distasteful, all this tooling is just so so complicated for very dubious guarantees/benefit. Not all of us are a sum of tropes.

The main thing that I find frustrating is that the actual act of programming in an impure language is so much harder. Haskell is def harder to learn, like 10x at least imo. Especially for a mainstream dev. But, once you know it, there is a simplicity to what you're doing which is very easy to do. I find myself having to just think so hard when writing python. "what exacty does this function do? Oh it calls this other function, I have to go check that one." etc. And then with a myriad of control flow issues, and random syntactic "sugar" to contend with...

There are a number of haskell companies, not just Jane street, and they do pretty well. If you don't follow the space closely, it is not surprising that you don't know about it. But there are. Not nearly as many as Python or whatever, but the appeal to the popular is def problematic: mostly because, at one point python itself was a radical new thing, full of skeptics like "if its so great, why don't more people use it".

Many ideas from haskell/typed fp are slowly making their way out into the larger community. Witness Swift, Kotlin, Java, numerous features in C#, etc. People like them.

Its fine if you don't like Haskell and don't want to use it. But its not an insane choice.

Haskell community really needs to do better at making it easier to get started though. Eventually I hope to contribute to that.

[taylodl]

You remind me that it's not the language that people use per se, it's the frameworks. Python has been around for 30 years. It was NumPy and SciPy that propelled it to the phenomenon we know today. Likewise with Ruby. I remember when Ruby was released in the mid 90's and wondering why would anyone use this language? Ten years later the Rails framework appeared and suddenly Ruby was a language that went mainstream.

Honest question - does Haskell have such a compelling framework driving its adoption? Or does Haskell suffer the "curse of Lisp" and people just create whatever they need when they need it and no big framework ever gets developed that drives adoption?

[tartoran]

How do you know it didn’t work out very well for them and they keep it quiet just so the competion doesn’t gain the same advantage? There is that possibility or it could be that the same team would be capable enough to change the stack and paradigm and get more or less the same results, with some twist and a different flavor. It’s hard to know for sure I think.

[akhmatova]

We don't know of course; nor do we have any reason to believe it does work.

But as for "keeping quiet" -- that they aren't doing at all. They are (or at least were, when I last paid attention to this stuff) extremely forward about their belief in FP as part of their secret sauce for staying ahead of the competition.

Which, ironically, makes one further question whether it has all that much benefit. Because if it really did ... yeah, they'd probably want to keep quiet about it. Like any other truly winning strategy in their arsenal.

[ygram]

It's the same for all languages, premature abstraction is a plauge in this industry.

[JoelMcCracken]

Yep. But sadly Haskell does give you more rope to hang yourself with. Refactoring and normal development is so easy and then people use all that power to go nuts. Such a shame.

[incrudible]

Haskell culture is all about exploration, which means you do not know what you are doing, by definition. A large part of that exploration revolves around abstraction.

[JoelMcCracken]

You shouldn't make the job harder than it needs to be. The main danger is using tools/techniques you don't know well. Learn radical new approaches on your own time. Don't bet the farm on the latest free monad framework which has 10 downloads on hackage.

[wly_cdgr]

I don't think that's an unpopular opinion among realistic, practical people

[JoelMcCracken]

I'd really love to hear more details about those Haskell services.

I'd put money on either the team not knowing Haskell when they started, or the "genius" was one of those completely impractical people who do type-level astronautics in Haskell.

[incrudible]

I think you just described the only two types of Haskell programmers that actually exist in a meaningful number.

[JoelMcCracken]

There are a lot of us. But we are a minority in the Haskell world I think.

[omegalulw]

I would love to hear that argument for Haskell for web dev.

[valbaca]

> Rust just may be the best choice for your startup, but it's not necessarily the best choice for all startups - in fact it's probably not the best choice for most startups!

Maybe it's just an assumption on your end. Neither title nor author imply that it's THE choice. The title literally says "a great choice"

> In the next post we’ll go into some of the downsides of using Rust.

[CharlesW]

> The title literally says "a great choice"

When in reality it may be, or it may be the worst possible choice. This is the parent commenter's point, I believe.

[pjmlp]

Looking forward to see how Rust is a great choice for startups doing mobile apps, native GUIs for desktop or embedded devices, or game development for consoles.