in summary: The reason why Haskell still doesn't really break through in the corporate world is not a failure of arrogance, but a marketing failure in the strictest sense of the word 'marketing'—which means prioritizing the right features to target the right market.
It's not targeted towards that. It's a 30 year old research language that is still ahead, and I don't really see a reason why it should change in any way towards businesses. If anything, it should lean more into research to keep ahead. I do not believe catering to anything in the corporate area will result in anything equivalent to the decades of research.
> As one might have guessed, this is not an essay. It's a transcript of the following talk by R. Martin with some substitutions made (SmallTalk -> Haskell, Ruby -> Rust, and others). You are free to make any conclusions from this.
I don't find this particularly interesting. Starting from the first questionable statement,
> Not because Rust is Haskell without HKTs
I was wondering why the article had so many inaccuracies.
Fundamentally, Haskell did not clearly solve any particular problem with other languages. There are a lot of cool things you can do in Haskell, and arguably, there are problems in other languages that aren't issues in Haskell. But the advantages of Haskell were never as clear cut as Rust.
In addition, Rust has already seen uptake on a level that Haskell never has. What's the most important Haskell project? Pandoc? Haxl? On the other hand, many companies have already started building core infra in Rust. Facebook with Mononoke, Libra, Eden, and Hack. Dropbox for storage servers. Mozilla with Firefox.
I think Rust has a bright future, and I don't think the analogy with Haskell is right at all.
EDIT: Judging from some of the other comments, I'm perhaps not surprised that GPT-3 achieved some success on HN.
> Fundamentally, Haskell did not clearly solve any particular problem with other languages. There are a lot of cool things you can do in Haskell, and arguably, there are problems in other languages that aren't issues in Haskell. But the advantages of Haskell were never as clear cut as Rust
I agree with you 100%
Did C++ kill C? Will Rust kill C++?
I think Haskell wasn't there to replace anything except maybe Standard ML, and you could say it won that one.
Rust is trying to be a better C++. And it addresses C++ issues directly in ways that are relatable to C++ programmers.
Similarly for Go, it really appeals to the Java croud that wants less patterns, less verbosity, more simplicity and especially that want lower memory footprint, fast startup times and simple deployments and delivery. It appeals to the Python croud that want better performance and to use what Google uses, etc.
I think in that sense, I see languages that take hold are those that directly address some of the pain points of other popular languages. Another great example of this is TypeScript.
And I'd say, that language cannot change everything that is familiar in doing so. You got to keep around a good 70% from the language that is popular, and with that 30% you can replace with something that fixes major pain points from it.
I think when you look at Rust it does that regarding C++, it purposely stayed close to the syntax.
And when I think of Haskell, it didn't do that. It wasn't trying to address the biggest pain points of everyday programmers in some other existing popular language. It was trying to be a whole new thing, an evolution of an already niche paradigm. It didn't meet anyone 70% of the way unless you were an ML programmer.
Now Squeak I find much more interesting, because it seem like it could have blown up, I mean Smalltalk too, not sure what happened, even Sun was working on Self, and the Java, Java won. I think it was due to performance at the time.
> many companies have already started building core infra in Rust. Facebook with Mononoke, Libra, Eden, and Hack. Dropbox for storage servers. Mozilla with Firefox.
You missed Amazon, Google, the Linux kernel, Microsoft, Apple, ... which big company isn't using Rust at this point in production?
The main difference between Rust as Haskell is that, while I really like doing competitive programming with Haskell, what I really like doing with Rust is shipping products to customers.
In my free time, I don't use Rust, right now I mostly use Idris2. But the main reason I can do that is that since we moved from C++ to Rust, nobody really call us on the weekend anymore to fix something that can't wait till monday.
> Fundamentally, Haskell did not clearly solve any particular problem with other languages.
Marketeers have a saying: "Its a lot easier to sell asprin than vitamins."
In other words, if someone says "This is giving me headaches" then someone with a solution for that headache will find it a very easy sale. But if your product pitch is that your general health will improve, your immune system boosted, yada yada, that's a much harder sale to make.
For Haskell original purpose it is hugely successful. It is a fantastic language to test new ideas and for functional language research. Think about how big of an impact it has had on languages like C#, Scala, Kotlin, and Swift.
SPJ has said Haskell's motto has always been "avoid 'success at all costs'", so it's perhaps unsurprising they're not concerned with industrial applicability, which doesn't mean it's particularly dead in the water or anything for other uses.
Also, just going off the substitutions, Ruby is alive and well with a major release on the horizon, many top startups got their start with it and the community is still growing. If Rust is the new Ruby, it should be pretty damn happy about it.
I agree with this story, but I would add one more thing (which so far, Rust doesn't suffer from, but is starting to sneak in with const functions).
Haskell suffered from people showing some great idea could be implemented in Haskell, without actually producing working finished code people could see.
For me the classic example is ripgrep. I remember seeing tutorials about how regexes could be nearly and efficently done in Haskell, but it was Rust and ripgrep which made a day-to-day useful tool, which gives me confidence I can also use Rust to do useful things.
Of course, I'm not saying everything has to be useful code, but having some commonly used programs in your language does help it seem practical. Haskell does have some great stuff (pandoc comes to mind), but very little considering its age, and compared to Rust.
Ahm, last time I checked Haskell was alive and well. Nothing killed Haskell because Haskell isn’t dead at all.
I guess what commercial-driven people don’t understand is that something isn’t a failure if it simply doesn’t play their “market domination” success game and doesn’t win by its metrics.
Go look at the photos of the first Haskell working groups; it’s an academic tool. It can be used for commercial workloads but it was never developed with that sole purpose in mind.
As a person who occasionally teaches programming languages, including Haskell, I have found the PHP community to be exceptionally supportive when it comes to documentation and examples. It has a very respectful attitude towards comments on the documentation website as well, where good examples contributed by users are eventually absorbed into the official documentation.
One of the least rigorous language in wide deployment has the best attitude towards its users.
If other languages also adopt a friendly and approachable attitude towards helping beginning, intermediate and advanced programmers, then I think that the ecosystems of languages would be much healthier.
Realistically the biggest problem with Rust today is the biggest problem it has always had - it is too hard to write useful programs. Rust has seen some success in very targeted use cases, but that isn't enough. I am 100% confident that introducing Rust to my company would be a huge mistake.
Can people tell me what useful program were produced in Haskell ?
I know a few for Ocaml but I dont know much Haskell, so dont know yet any useful program written in Haskell.
The program I know for Ocaml are:
- coccinelle (semantic patching used by linux kernel devs)
- FramaC (formal verification)
- Coq (proof assistant)
- Rust compiler (I think they bootstraped the language by writting a compiler in ocaml first, now the compiler is written in rust itself)
I just saw pandoc. It seems nice.
I know parsec.
But I would like to know what kind of haskell programs are actually used in real life ?
I know Jane Street does all their dev in Ocaml.
Is there similar company for Haskell ?
One that I use all the time is shellcheck, and git-annex. Others in the mainly-used-by-programmers-category include xmonad and hledger. https://github.com/owickstrom has some GUI Haskell apps.
Uncle bob’s original essay is largely worthless, and I’m genuinely struggling to understand what value is to be extracted by transplanting a terrible argument, onto an even less applicable programming language situation.
If anyone reading this has published anything resembling this tripe, please stop programming and start crocheting, or some other, more useful hobby.
I can see the use for Rust in writing an operating system or device driver...but manual memory management for application software? That's a huge step backwards. I really don't get why anyone uses Rust outside of low-level or very performance-driven problem domains. Seems like a cargo cult or hype machine, though certainly an improvement over C, it should be replacing C. It might be better than Java, but what replaces Java should look more Haskelly.
The vast majority software is performance driven, because the vast majority of software has end users who have better things to do with their lives than wait for software to do what it should.
But this point is lost on a large percentage of the people who build software. And those who do understand the point also often push performance down the priority stack because writing fast software is hard.
What's the weak points (except not-very-easy-to-learn and complication speed) of Rust? It listens perfect in every other aspect from the Rust promotion articles.
IDE tooling / intellisense is improving but still weak compared to, say, C# IME - although I should maybe give IntelliJ another shot.
It's still got a lot of low level building blocks in place but there are still gaps and mid-tier / high level frameworks are still missing for many problem domains.
It's strictness, while generally useful in the long run, can be more of a drag than a boon for quick and dirty projects (although the more I use it, the faster I'm getting with dealing with said strictness...)
It's got a nice hefty stdlib, which is usually a boon, but can be annoying to port for weird platforms. There's almost always a working C++ environment available, but Rust takes more work. A concrete example: https://github.com/MaulingMonkey/rust-opendingux-test . And yes, that "Rust" repository does have 2 lines of C code in it ;).
EDIT: Also, no standard/stable Rust ABI. And extremely limited dynamic runtime reflection via "dyn Any" (although pretty decent hygenic macros / proc macros and related crates makes the compile time stuff sufficient for most of my day to day needs). Still, C# DLL reflection is super nice at times, whereas Rust is "forced" to ship source code for libraries unless they want to jump through a bunch of hoops to limit the API surface to the C ABI...
EDIT: Also, a lot of rust libraries are quick to adopt new features of the latest stable compiler. Tools like rustup make it trivial to stay on the latest stable compiler, but can make things awkward if you insist on apt-provided rustc, or if you need to customize the compiler or stdlib for your particularly oddball target platform (read: consoles, but not opendingux like I linked above) - this can be a pain point.
You have to think about memory management. No matter what rust evangelists say, you have to think about it. Well you don't have to worry about it like in C. Of course rust is intended for safe performance-critical programming. GC is fine for a significant portion of software.
The ruby / javascript webshit culture creeping in - lot of microdependencies which can often be hard to audit. Projects like cargo-crev aren't getting any traction.
Crates.io - the package registry lacks namespacing. That means package names have to be choosen carefully and you might here phrases like "import data from cabbage to rabbit using chickenshit crate" etc..
Async runtime fragmentation because stdlib doesn't provide one.
Very small standard library. Many things need you install a crate which might come with 40 other dependencies. This kind of dependency counts are fine for creating webshit but sometimes you need to audit your dependencies, especially rust is intended for low level programming.
Horrible compile times. You might think rust has better compile times than C++ because it has a module system. But compile times are similar. Rustc emits large chunks of LLVM IR. Not faulting people working on rust for this - but they have a shortage of talent. And rust community's zealotry makes lot of people sceptical.
A very zealot community which also happens to be very active on programming link aggregators. You might get downvoted irrationally for simply critisizing some flaw of rust. You keep on hearing zero-information / out of context statements heralding rust. This is partly a consequence of influx of people from blogging-heavy ruby and javascript communities. Especially the javascript crowd has an Instagram feel to it. Some people among these have marginal knowledge of computer science concepts and still show up everywhere heralding rust.
No structural typing. This may be flaw or virtue - people from dynamic typed languages may like structural typing as in Go or OCaml than nominal typing.
Rust fits well in low-level cases and data-oriented design situations. For things needing any abstraction or modern OO, the borrow checker really damages your architecture.
Honestly that kind of number dropping just makes me laugh.
What does productivity mean? Is it time / feature? How do you do a proper comparison?
I have been programming for 20 years, mainly in C, C++ and python. Very rarely have I felt slowed by the language itself. It's the architecture, the implementation tradeoffs, the understanding of the business, etc that take most of the implementation time.
The right language choice for a problem space is a force-multiplier.
I don't think 'several times more productive for the at least some of the cases where it was designed to excel' is a particularly strong claim; the devil is in asking 'which cases are those?'.
Depends, using Typescript over Javascript has eliminated whole reams of ‘undefined’ errors. It may not make development faster, but it certainly prevents a lot of bugs.
Yes, agree with this. The very old separation between accidental complexity and intrinsic complexity from the mythical man month comes to mind. If you are spending less than 80 percent of your time on accidental complexities where exactly would a factor of 5 be coming from?....
Rust is already greater than Haskell. Not in programming terms, but in social terms. Rust won't die, or at least won't die the same death as Haskell. Rust, compared to Haskell, has already won.
I don't think Haskell was ever successful other than as an inspiration for parts of other programming languages like Rust.
They chose an unfamiliar syntax for no reason (and one that makes it hard to learn abstractions, e.g. the practice to not distinguish between a -> (b -> c) and (a x b) -> c), and non-strictness/space-leaks makes it unusable for anything serious; plus, it doesn't support dependent types, so it's not even good as a "theoretically perfect" language.
The only thing that can kill Rust is a better Rust, which means either a Rust with dependent types, or a Rust that is somehow much easier to learn while not sacrificing power and zero-cost abstraction (I believe the latter is likely impossible, but maybe I'm wrong).
There is also the possibility of limited success for Rust, i.e. the fact that it will kill C/C++ (which is inevitable), but fail to kill JavaScript and Java/Go/C#.
"Haskell in its time was at the forefront of functional programming. It was the language that kind of characterized or epitomized what FP was really about. There were other languages that were functional, but they were only sort of functional. And of course, I'm talking about languages like Scala, or JavaScript. Those were the two major competitors during the same mid 2000s."
I guess this guy has never heard of OCaml or SML.
Though Haskell was a leader in the FP field, it was never the only language to epitomize FP.
> Not because Rust is Haskell without HKTs. (Some of you know what that means, and the rest of you will wonder for a very long time)
It would make the paper more readable to newcomers to explain this. The author was too smug and as a newer person in the Rust community I wish people who cared enough about writing papers also cared about making them accessible :/
Actually what kills it is Yet Another F... Language. Most new languages are barely better then anything that already exists. After the initial cheerleaders that started the project moved on, the company realizes it's hard to find coders for the niche fad language of the period.
[+] [-] platz|5 years ago|reply
https://news.ycombinator.com/item?id=24401748
see my comment there:
https://news.ycombinator.com/item?id=24404593
in summary: The reason why Haskell still doesn't really break through in the corporate world is not a failure of arrogance, but a marketing failure in the strictest sense of the word 'marketing'—which means prioritizing the right features to target the right market.
[+] [-] bontaq|5 years ago|reply
[+] [-] chillee|5 years ago|reply
I don't find this particularly interesting. Starting from the first questionable statement,
> Not because Rust is Haskell without HKTs
I was wondering why the article had so many inaccuracies.
Fundamentally, Haskell did not clearly solve any particular problem with other languages. There are a lot of cool things you can do in Haskell, and arguably, there are problems in other languages that aren't issues in Haskell. But the advantages of Haskell were never as clear cut as Rust.
In addition, Rust has already seen uptake on a level that Haskell never has. What's the most important Haskell project? Pandoc? Haxl? On the other hand, many companies have already started building core infra in Rust. Facebook with Mononoke, Libra, Eden, and Hack. Dropbox for storage servers. Mozilla with Firefox.
I think Rust has a bright future, and I don't think the analogy with Haskell is right at all.
EDIT: Judging from some of the other comments, I'm perhaps not surprised that GPT-3 achieved some success on HN.
[+] [-] dang|5 years ago|reply
[+] [-] didibus|5 years ago|reply
I agree with you 100%
Did C++ kill C? Will Rust kill C++?
I think Haskell wasn't there to replace anything except maybe Standard ML, and you could say it won that one.
Rust is trying to be a better C++. And it addresses C++ issues directly in ways that are relatable to C++ programmers.
Similarly for Go, it really appeals to the Java croud that wants less patterns, less verbosity, more simplicity and especially that want lower memory footprint, fast startup times and simple deployments and delivery. It appeals to the Python croud that want better performance and to use what Google uses, etc.
I think in that sense, I see languages that take hold are those that directly address some of the pain points of other popular languages. Another great example of this is TypeScript.
And I'd say, that language cannot change everything that is familiar in doing so. You got to keep around a good 70% from the language that is popular, and with that 30% you can replace with something that fixes major pain points from it.
I think when you look at Rust it does that regarding C++, it purposely stayed close to the syntax.
And when I think of Haskell, it didn't do that. It wasn't trying to address the biggest pain points of everyday programmers in some other existing popular language. It was trying to be a whole new thing, an evolution of an already niche paradigm. It didn't meet anyone 70% of the way unless you were an ML programmer.
Now Squeak I find much more interesting, because it seem like it could have blown up, I mean Smalltalk too, not sure what happened, even Sun was working on Self, and the Java, Java won. I think it was due to performance at the time.
[+] [-] fluffything|5 years ago|reply
You missed Amazon, Google, the Linux kernel, Microsoft, Apple, ... which big company isn't using Rust at this point in production?
The main difference between Rust as Haskell is that, while I really like doing competitive programming with Haskell, what I really like doing with Rust is shipping products to customers.
In my free time, I don't use Rust, right now I mostly use Idris2. But the main reason I can do that is that since we moved from C++ to Rust, nobody really call us on the weekend anymore to fix something that can't wait till monday.
[+] [-] PaulAJ|5 years ago|reply
Marketeers have a saying: "Its a lot easier to sell asprin than vitamins."
In other words, if someone says "This is giving me headaches" then someone with a solution for that headache will find it a very easy sale. But if your product pitch is that your general health will improve, your immune system boosted, yada yada, that's a much harder sale to make.
[+] [-] mrh0057|5 years ago|reply
[+] [-] vore|5 years ago|reply
[+] [-] d3nj4l|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] bad_user|5 years ago|reply
I kept wondering why I'm wasting my time reading this, until the end, only to find that this is the style of Uncle Bob.
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] CJefferson|5 years ago|reply
Haskell suffered from people showing some great idea could be implemented in Haskell, without actually producing working finished code people could see.
For me the classic example is ripgrep. I remember seeing tutorials about how regexes could be nearly and efficently done in Haskell, but it was Rust and ripgrep which made a day-to-day useful tool, which gives me confidence I can also use Rust to do useful things.
Of course, I'm not saying everything has to be useful code, but having some commonly used programs in your language does help it seem practical. Haskell does have some great stuff (pandoc comes to mind), but very little considering its age, and compared to Rust.
[+] [-] eecc|5 years ago|reply
I guess what commercial-driven people don’t understand is that something isn’t a failure if it simply doesn’t play their “market domination” success game and doesn’t win by its metrics.
Go look at the photos of the first Haskell working groups; it’s an academic tool. It can be used for commercial workloads but it was never developed with that sole purpose in mind.
Haskellers play another game.
[+] [-] rfw300|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] the_mitsuhiko|5 years ago|reply
//edit: i just now realized that this post was not originally about Haskell but Smalltalk. That makes more sense to me.
[+] [-] sn41|5 years ago|reply
One of the least rigorous language in wide deployment has the best attitude towards its users.
If other languages also adopt a friendly and approachable attitude towards helping beginning, intermediate and advanced programmers, then I think that the ecosystems of languages would be much healthier.
[+] [-] blaisio|5 years ago|reply
[+] [-] natertux|5 years ago|reply
I just saw pandoc. It seems nice. I know parsec. But I would like to know what kind of haskell programs are actually used in real life ? I know Jane Street does all their dev in Ocaml. Is there similar company for Haskell ?
[+] [-] unhammer|5 years ago|reply
Facebook's Sigma and https://github.com/wireapp/wire-server may be the ones with the most non-programmer users?
http://postgrest.org/ and https://hasura.io/ seem interesting.
https://www.quora.com/What-is-the-largest-commercial-program... says the largest Haskell code-base is probably Standard Chartered trading system.
more at https://github.com/topics/haskell and https://serokell.io/blog/top-software-written-in-haskell
[+] [-] ywei3410|5 years ago|reply
[+] [-] codygman|5 years ago|reply
https://github.com/github/semantic/blob/master/docs/why-hask...
[+] [-] cannabis_sam|5 years ago|reply
If anyone reading this has published anything resembling this tripe, please stop programming and start crocheting, or some other, more useful hobby.
[+] [-] theonemind|5 years ago|reply
I don't get it.
[+] [-] ur-whale|5 years ago|reply
The vast majority software is performance driven, because the vast majority of software has end users who have better things to do with their lives than wait for software to do what it should.
But this point is lost on a large percentage of the people who build software. And those who do understand the point also often push performance down the priority stack because writing fast software is hard.
[+] [-] DasIch|5 years ago|reply
If you do very low level stuff, you might think about that a bit more but then you have to in any case.
[+] [-] tapirl|5 years ago|reply
[+] [-] MaulingMonkey|5 years ago|reply
It's still got a lot of low level building blocks in place but there are still gaps and mid-tier / high level frameworks are still missing for many problem domains.
It's strictness, while generally useful in the long run, can be more of a drag than a boon for quick and dirty projects (although the more I use it, the faster I'm getting with dealing with said strictness...)
It's got a nice hefty stdlib, which is usually a boon, but can be annoying to port for weird platforms. There's almost always a working C++ environment available, but Rust takes more work. A concrete example: https://github.com/MaulingMonkey/rust-opendingux-test . And yes, that "Rust" repository does have 2 lines of C code in it ;).
EDIT: Also, no standard/stable Rust ABI. And extremely limited dynamic runtime reflection via "dyn Any" (although pretty decent hygenic macros / proc macros and related crates makes the compile time stuff sufficient for most of my day to day needs). Still, C# DLL reflection is super nice at times, whereas Rust is "forced" to ship source code for libraries unless they want to jump through a bunch of hoops to limit the API surface to the C ABI...
EDIT: Also, a lot of rust libraries are quick to adopt new features of the latest stable compiler. Tools like rustup make it trivial to stay on the latest stable compiler, but can make things awkward if you insist on apt-provided rustc, or if you need to customize the compiler or stdlib for your particularly oddball target platform (read: consoles, but not opendingux like I linked above) - this can be a pain point.
[+] [-] higerordermap|5 years ago|reply
The ruby / javascript webshit culture creeping in - lot of microdependencies which can often be hard to audit. Projects like cargo-crev aren't getting any traction.
Crates.io - the package registry lacks namespacing. That means package names have to be choosen carefully and you might here phrases like "import data from cabbage to rabbit using chickenshit crate" etc..
Async runtime fragmentation because stdlib doesn't provide one.
Very small standard library. Many things need you install a crate which might come with 40 other dependencies. This kind of dependency counts are fine for creating webshit but sometimes you need to audit your dependencies, especially rust is intended for low level programming.
Horrible compile times. You might think rust has better compile times than C++ because it has a module system. But compile times are similar. Rustc emits large chunks of LLVM IR. Not faulting people working on rust for this - but they have a shortage of talent. And rust community's zealotry makes lot of people sceptical.
A very zealot community which also happens to be very active on programming link aggregators. You might get downvoted irrationally for simply critisizing some flaw of rust. You keep on hearing zero-information / out of context statements heralding rust. This is partly a consequence of influx of people from blogging-heavy ruby and javascript communities. Especially the javascript crowd has an Instagram feel to it. Some people among these have marginal knowledge of computer science concepts and still show up everywhere heralding rust.
No structural typing. This may be flaw or virtue - people from dynamic typed languages may like structural typing as in Go or OCaml than nominal typing.
[+] [-] moldavi|5 years ago|reply
[+] [-] tobyhinloopen|5 years ago|reply
I can’t imagine any language being 5 times as productive as current mainstream projects.
[+] [-] Galanwe|5 years ago|reply
What does productivity mean? Is it time / feature? How do you do a proper comparison?
I have been programming for 20 years, mainly in C, C++ and python. Very rarely have I felt slowed by the language itself. It's the architecture, the implementation tradeoffs, the understanding of the business, etc that take most of the implementation time.
[+] [-] danielheath|5 years ago|reply
I don't think 'several times more productive for the at least some of the cases where it was designed to excel' is a particularly strong claim; the devil is in asking 'which cases are those?'.
[+] [-] zik|5 years ago|reply
[+] [-] Aeolun|5 years ago|reply
[+] [-] cjfd|5 years ago|reply
[+] [-] smabie|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] adamnemecek|5 years ago|reply
[+] [-] three_legs|5 years ago|reply
[+] [-] 978e4721a|5 years ago|reply
The only problem with Haskell is that it's on a journey to dependent types and they haven't released new standard yet.
It's future will depend on how good that future standard will be.
Rust is becoming more popular than Haskell because It's in a different niche (no gc). Not because it's more productive to write Rust code.
Haskell is still much easier and faster to write than any other production language.
Try to compare merge function for merge sort in Haskell and in other languages.
[+] [-] devit|5 years ago|reply
They chose an unfamiliar syntax for no reason (and one that makes it hard to learn abstractions, e.g. the practice to not distinguish between a -> (b -> c) and (a x b) -> c), and non-strictness/space-leaks makes it unusable for anything serious; plus, it doesn't support dependent types, so it's not even good as a "theoretically perfect" language.
The only thing that can kill Rust is a better Rust, which means either a Rust with dependent types, or a Rust that is somehow much easier to learn while not sacrificing power and zero-cost abstraction (I believe the latter is likely impossible, but maybe I'm wrong).
There is also the possibility of limited success for Rust, i.e. the fact that it will kill C/C++ (which is inevitable), but fail to kill JavaScript and Java/Go/C#.
[+] [-] pmoriarty|5 years ago|reply
I guess this guy has never heard of OCaml or SML.
Though Haskell was a leader in the FP field, it was never the only language to epitomize FP.
[+] [-] ColeyG|5 years ago|reply
It would make the paper more readable to newcomers to explain this. The author was too smug and as a newer person in the Rust community I wish people who cared enough about writing papers also cared about making them accessible :/
[+] [-] hg35h4|5 years ago|reply
[+] [-] hg35h4|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]