Having developed Haskell skills, what can one then do with them? Who in the world wants to have any Haskell code written badly enough to offer to pay to have it done?
If Rust dies, it will die just exactly the way almost every language did: its adoption rate was two or more orders of magnitude too slow, and the world moved on.
This is not inevitable: there are many other ways languages have died. Ada had a formal spec, billions of dollars in development contracts backing it, many industrial-grade compilers, thousands employed coding in it. It died because, ultimately, it wasn't enough better than C.
PL/I died. Algol died. All the various Pascals died. Ruby is in sharp decline. Death is the natural course for languages. Overcoming death requires a near-miracle.
COBOL, Fortran, C, C++, Python, Java, and Javascript managed it. It is too early to tell about Go or Rust, but it is not looking good for Rust, just based on the numbers. Rust's originators hoped to displace C, but very few move from C. Most who might have moved on from C did before there was a Rust, and the rest like it for its flaws, the way rock climbers like cliffs.
Rust will take few from C++ because Rust is less expressive, by design. The gap widens with each Standard release.
The languages Rust can practically steal users from do not suffer from the memory-safety problems Rust is promoted as solving. They have other problems it could help with. Go and Java are pathologically weak languages, and Python is pathologically slow and un-parallel.
There are things Rust adherents could do to increase its adoption rate, but they seem, by all indications, supremely and aggressively uninterested in even trying any of them. HN buzz, which Rust fans have run up to stratospheric heights, is very far from enough to sustain a language. So, Rust's prospects are dimming even as its apparent popularity peaks.
Examples being Swift, Ada/Spark, C++ lifetime analyzers, Chapel, ParaSail.
Then there are the Haskell, OCaml, Pony, Verona, Nim, D, Nim efforts on how to combine the best of both worlds GC (in whatever form) + affine types when needed.
But taking the world by storm and actually replacing C++ across Fortune 500's, specially given the contribution of many of them to ISO C++ and industry certifications, I see that as a multiple decades effort and even, as we can see from C++'s failure to take over C in certain domains, it is going to be a very steep uphill battle.
So in the end, we might just happen to get the usual mainstream languages with improved capabilities for managing resources, just like Haskell happened to bring LINQ to .NET world, followed by influencing Java streams and C++ ranges.
That's not bad for a language that has "barely" hit 1.0 five or so years ago (next to C's 40-something years).
If it can increase its adoption rate by two orders of magnitude, it just might survive and grow. But it will need changes to get that.
So I guess it boils down to how much space are they planning to give to Rust on their own SDKs, IDE and OS infrastructure.
You need a large enough population of skilled programmers that you can reasonably count on finding enough that are ready to move on and good enough for your project, and enough ongoing projects to keep them all busy. The number of companies that have little projects doesn't figure, nor the size of the companies. A list of big companies using it is actually the least informative, because all it takes is one person using, out of the many thousands there, to say "the company" is using it.
It would be surprising if there were two hundred paid Rust jobs already, and astonishing if there were a thousand. It needs to get to a hundred times that to have a chance to survive, and in only a few years. Ada got there and died anyway.
It is also one of the few languages that has managed to keep a room at FOSDEM since I can remember.
It might be dead for FOSS hype projects, but in real life production code that actually affect people's lives, still has more deployments per year than most Rust projects.
I'd say that the amount of Rust work is the metric I agree with. I think Graham's "Python paradox" is true and correct. If you post a job position that includes working on Rust, you'll have people falling over themselves to apply. What you'd really need, IMO, is managers to get on board. It's a chicken and egg problem. If it isn't Java, PHP, Python, C++, then it's "risky".
We do use Rust for a few projects where I work. Entirely because I had enough social capital and reputation with my boss to push for it.
I don't do Rust full time. But what counts as a "paid Rust job"? I get paid. And I do Rust for my company. Does that count?
And I don't understand why you're asserting that it has to shoot up by orders of magnitude to survive. I feel like maybe you're being biased by something, but I'm not sure what. Look at Python. It existed in the early 90's IIRC, but it totally exploded around 2005-ish (again, IIRC). Haskell and OCaml exist. They seem to actually be picking up a bit of steam if you go by social media such as HN. Ada isn't dead.
Are there any languages you can immediately answer these questions for? Are there any popular languages you can't answer these questions for?
I have some ideas, but I want to nail things down a bit more before attempting an answer if you don't mind.
And of course we all get our monthly calls from Google recruitment contractors to come code Google's special subset of C++. Google doesn't offer a half $mil to everyone, but remarkably many do get it. I expect a few even get it for coding Haskell, although one may doubt that is what the req they were hired on called for.
literally none of these is related to intelligence.
And even if they did, to assert that not wanting to learn Haskell has anything to do with "drive, intellectual curiosity and desire for a challenge" is ridiculous. There are a million reasons a person that exhibits all three of those qualities could opt not to.
GP didn't mention the word "intelligence"
- having or showing quick intelligence or ready mental capability
They said "smart", I said "intelligence".
I am arguing a series of things. First, that being "smart" does not always mean those three things. Second, that being "smart" does not mean that you'd care to learn Haskell. Third, to suggest a tool isn't catching on because the members of the programming community aren't "smart" enough is so masturbatory it's actually insane. God forbid Haskell isn't catching on because of all the valid critiques that show up in every one of these threads and then gets dismissed under this same "Haskell smart" rhetoric.
Haskell will not catch on because the community thinks it is too smart to have to actually accommodate the programming community. Simple as that.
The person used "smart" in scare quotes, and defined that usage of smart as being those things. That seems like an explicit mark that they are not talking about all of the usual definition of the word.
> Second, that being "smart" does not mean that you'd care to learn Haskell.
That's irrelevant. If X is necessary for Y, lack of X is a good explanation for lack of Y even when X is not sufficient for Y.
> God forbid Haskell isn't catching on because of all the valid critiques that show up in every one of these threads and then gets dismissed under this same "Haskell smart" rhetoric.
If you're looking in from the outside, you may not be in a good place to distinguish between "all of these valid critiques" and "invalid complaints that arise because of misunderstanding, dated info, or outright FUD". There are absolutely valid critiques of Haskell. Most of my problems with it are things that are even more present in languages that have caught on, though, so they cannot stand alone as an explanation.
All of that said, "people aren't smart enough" isn't a claim I'd make, even with the reduced scope. I just don't think your argument is well formed.
It's weird, then, that the person that wrote the article that you and I are both commenting on has written a well regarded book using Haskell and their assertion is exactly the same as mine, no? It's also weird that the subject of this article is meant to be Rust, and yet here we are debating the idea that "Devs just aren't smart enough to understand haskell".
But, as always, I wouldn't expect a conversation about Haskell to really go anywhere. You can't comment unless you've drank the kool aid, and if you've drank the kool aid you're required to spout the same rhetoric.
... their assertion was that the problem was the exactly the same unspecified pile of "valid critiques that show up in every one of these threads"?
> I wouldn't expect a conversation about Haskell to really go anywhere.
Many conversations I've had about Haskell - pro and con - have gone really interesting places. But as your experience has differed, and you appear to think that's predictive, I'll take this opportunity to remove that common variable by wrapping up discussion here.
Snark aside, I wish you well.
From the article: There was an arrogance in the Haskell community. Not the evil kind, but the kind that told them that they were somehow better. That the tools they were using were somehow better. That the things they were doing were somehow better. There was the arrogance of those people who believed that victory was inevitable. This was not the slapping your face “you, stupid fool golang programmers” kind of arrogance, although there was plenty of that, too. Instead, it was a kind of arrogance of power. Because the Haskell people were writing a pretty powerful code, they did have a tiger by the tail. It was a powerful compiler, it was a powerful language, and they knew they could work miracles. And yet, that wasn’t enough. Something insidious, something subtle happened. It caused their separation, they set aside the rest of the industry. The people outside the community who were writing everyday programs began to look at the corner of the eye where the Haskell people were doing: “Emm… Haskell people don’t seem to like us very much, I don’t think we’re gonna like them”. Some of you might remember the Reddit discussions in the mid 2000s. A bunch of people were there. And they were talking about cool math things there. In those talks, they often were snickering about other languages like Go. It wasn’t anything significant, it wasn’t anything evil, they were just snickering: “He-he-he, mainstream people, ha!”. But I was a mainstream golang guy at that time! I didn’t like that. And I’ve been dealing with language wars in the next couple of years. And I said to them at that time “Do we really want to have language wars on Reddit?”. And the interesting thing about it was not about what they were snickering about, because they probably had a right to do that. What was interesting about is my reaction. My reaction was defensive. My reaction was “Well, you guys, go ahead and do your Haskell thing, but I’m the one who gets real work done.” That’s the interesting division that got set up at the time. And it was fairly pervasive. There was an attitude among the Haskell community, and again, it’s not an evil attitude, not one that was born out of ill will. But there was an attitude that said “You know, our tools are so good, our language is so good, we don’t need to follow the rules. We can do something else. We don’t have to talk to other people. We don’t have to do the other kinds of programs.” Haskell people didn’t want to do the regular kinds of programs. They didn’t want to have to deal with the corporate database. They didn’t want to have to deal with the horrible schema that had evolved twenty years. It was just distasteful. And they found ways instead to do things like using category theory, and dependent types. They’ve built a wall around themselves, and they’ve chosen to live in a technological bubble. Isolated from the evils of the outside world.
> I'll take this opportunity to remove that common variable by wrapping up discussion here.
This conversation has continued to be the status quo.
> Snark aside, I wish you well.
Best of luck!
Like, you don't literally mean there are Haskellers saying "we're to smart to write beginner-friendly documentation haha" right?
Jokes aside, can you give an example of this?
Specifically, though, this comment is a pretty good example of what this article (and I, now), am talking about:
> Certain problems, like working with databases in the principle Haskell way, are still open questions (e.g. see effect systems). But to call a mere difference in approach "arrogant" is extremely arrogant in itself
Which points to a problem very specific to haskell, brought up in the article, which is "How do I actually get things done?" Which, according to that comment (supposedly in support of Haskell) even points out that something as obvious and boring as "using a database" isn't clearly defined in Haskell. Most programmers want to use a programming language to solve a problem. The haskeller's argument, I guess, is that Haskell tries to do that while also applying very strict constraints on how problems are solved. Great, right? Except that those constraints are so strict that even problems that aren't significant or meaningful are difficult/not well defined (like using a database).
So if the answer to "How do I get things done?" isn't "Like this" but instead "Haskell doesn't work that way", most programmers will consider this a nonstarter.
If anyone wants to read through that thread to see exactly how toxic /r/haskell is they can find it here:
https://old.reddit.com/r/haskell/comments/io3c11/essay_found...
> I genuinely tried to read this and take it seriously but this is just the most cringe-worthy thing I've read in ages. I'm sorry.
> As a composition of prose, this little essay is just stylistically terrible and reallllly hard to read.
> A really dumb essay.
Just from the one post.
I disagree with the cracked pot comment, that goes too far.
It is pretty cringe-worthy, is it toxic to point that out?
They are using a very high standard of clearly defined. Haskell has production ready ways of accessing databases and working with them today.
> problems that aren't significant or meaningful are difficult/not well defined (like using a database).
If you feel database work isn't meaningful, Haskell provides "write plain parameterized SQL, get back results" type libraries too.
I disagree database access and the realm of ORMs is simple, which is what they are talking about. You can tell by how they say "working with databases".
Other languages disagree about the best ways to work with databases. I'm sure you've seen the endless raw SQL vs ORM debates.
Saying it is very inconsiderate of the efforts of everyone writing real world Haskell software.
Facebook uses Haskell, Github uses Haskell, etc... the metaphor doesn't hold and means this is just FUD.
On top of that, you're actually talking to a working professional Haskell programmer whose company depends on it.
What do you use Haskell for?
Sometimes background services.
Separating "I like and use Haskell" from "Learning Haskell will amplify your career and employability" is, I think, what they're going for, and I would generally agree with. "The exception that proves the rule" is a thing, after all.
Reading a book on abstract algebra is going to give you more concepts of Type Theory than learning Haskell.
So you may say that learning Haskell is intellectually useful, yet there are more challenging purely theoretic concepts which are more useful than Haskell.
I would go as far as saying that learning Haskell is just a "<smarts> poor man's excuse for not challenging themselves enough in the areas that actually matter".
What aspects of a book in abstract algebra introduce you to concepts of type theory, would you say?