What killed Haskell, could kill Rust, too
gist.github.com
gist.github.com
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.
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.
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.
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.
What the Linux kernel is discussing is how to integrate these kernel modules and drivers into the Linux tree. They are not discussing whether this is worth doing, but how to do it. Linux is quite stable if you stick to the right APIs, and maintaining these out-of-tree is not too bad, but the current situation is not sustainable in general.
For us it doesn't matter, because our code is not open source. But it matters to quite a bit of people.
I'm freakin sold, gonna learn rust now.
I worked with C++ at Google recently. I didn't see any push to switch to rust and I don't know of a single production server running rust binaries.
Edit: The best evidence that Google doesn't use rust in production is that they don't have an official protocol buffer implementation in Rust. Until they have that nobody will use it for servers at Google.
https://developers.google.com/protocol-buffers/docs/cpptutor...
1. in ChromeOS, via crosvm (they collaborate with rust-vmm with Amazon, who originally forked crosvm for Firecracker)
2. in Fuchsia, whose employees also have helped significantly with the language and implementation on company time
3. Smaller projects, like sponsoring some font tooling work
Additionally, the Chrome team has a branch with Rust code in it and they're evaluating it currently. We'll see.
* ChromeOS: https://chromium.googlesource.com/chromiumos/platform/crosvm...
* Fuchisa: https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master... (I picked this bit sort of at random because it talks about a bunch of stuff)
* https://raphlinus.github.io/rust/druid/2019/10/31/rust-2020.... ("Runebender is generously supported financially by Google Fonts, for which I am very grateful, as it makes it more of a serious and professional project.")
* Chrome: https://chromium-review.googlesource.com/q/project:experimen...
This is as direct of links as I can give, but there's a ton of commentary around all of these topics; they've been covered on HN before, even.
You could have said the same thing about Haskell (hell, you could even say MS invented Haskell, or at least MS research people, fwiw) . It's absolute meaningless. Big companies have many projects and in random languages.
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.
Just as importantly, it's trying to be a better C++ and it addresses C++ issues directly in ways that are relatable to non-C++ programmers.
For devs used to higher level languages, C++ is horrifying, it's a footgun wrapped in grenades, with an internet as full of legacy bad advice as VBA. Rust is a promise that you can get C++-type performance without blowing your foot off or falling into a million traps along the way unless you really want to.
No. I mean what I wrote.
> C++ is quite high level and managed languages like Swift, D and C# offer similar concepts.
Languages like Swift and C# have memory safety and automated memory management by default, unlike C++. They also don't have C++'s unique blend of language features mis-interacting with one another in rather deadly way.
Languages like Swift and C#, or even Rust, while safe by default do also have their gotchas, do expose unsafe code capabilities, and when an application crashes or panics in the middle of a critical workflow, it is deadly no matter how it came to happen.
Specially deadly in the age of thin runtime libraries, that requiring installing half of the Internet for each basic dependency, without any sort of control quality.
For example, Rust libraries that make use of unsafe just because the authors gave up on writing the code in a proper way, but n levels deep on the whole dependency chain.
It's not as potent as say Isabelle/HOL prover or top of SML or SPARK Ada, but much easier to write, and safer than Java at memory management in practice.
(Where you get to write very thick foreign interfaces with no way to even try to make them safer, and cannot control memory allocation manually easily.)
A decent balance.
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.
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.
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.
//edit: i just now realized that this post was not originally about Haskell but Smalltalk. That makes more sense to me.
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.
Yes, it's not as "easy" to pick up as C or Python, but it also prevents footguns introduced by those languages.
That said, yes, it’s used some, but that reflects a few random teams having decided to use it (most notably hg and Libra), not some grand strategic decision.
Source: I worked at Facebook for four years, until one year ago.
(Incidentally, I’ve spent the year since then working exclusively in Rust for my day job, and I love the language)
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 ?
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
https://github.com/github/semantic/blob/master/docs/why-hask...
Also PureScript and Elm are to my knowledge written in Haskell..
If anyone reading this has published anything resembling this tripe, please stop programming and start crocheting, or some other, more useful hobby.
I don't get it.
If you do very low level stuff, you might think about that a bit more but then you have to in any case.
That's not true in my experience. Every single error the borrow checker throws at you is in a sense "memory management". Rust forces me to think very hard about memory, in all but the simplest toy programs.
You want anything to do with threads? Gear up for a long afternoon of fighting the compiler before you fully understand your memory model and use it properly. You want anything to do with linked lists? Same deal. You want anything to do with async. Plan to spend 3 hours just to figure out what you want to really do.
All this is memory management. Just in a different form compared to C/C++. Python OTOH simply lets you forget that the computer exists. It's just you and the problem you're solving. You pay for that with lack of speed and bloated memory usage.
The difference is just in when you get the error and what kind you get. Do you get errors at runtime or does the compiler complain?
I would argue that doing some of this in Python with no language support at all, is in some ways more manual than Rust, where you get at least assistance.
Ownership and borrowing in Rust is solving a much bigger problem than what has been traditionally understood as memory management. Put another way: Other languages even with GC only solve memory management partially.
Rusts approach has downsides with cyclic data structures, that’s true but how often do you implement those in real world code? Async can indeed be tricky, that requires a bit of time to wrap your brain around but I think it’s getting better.
Linked lists? Rust just really doesn't like them. Better to use something else instead. I can't remember ever wanting to use a linked list in a program I've written though. I think you could argue that it's tough to write a linked list implementation that really never leaks memory without a GC.
Threads? I'd argue that the stuff that Rust prevents are usually real bugs. You might not hit those bugs right away, especially in a language with a GIL, but they're there. Better to know they'll just never happen, no matter how hard you push your threads.
For async, I guess I've had good luck with it so far. I still feel like I don't really understand what's going on with Rust async and runtimes, but most of the code I've written with it just works.
> You manage memory in Rust about as manually as you manage memory in Python
Like, last week I wrote some code that had a use after free, because I wasn’t thinking. I wasn’t thinking because I didn’t have to. The compiler thinks for me. It told me my mistake, I immediately fixed it and moved on. This was like a ten second process. “Oh yeah that takes ownership but I wanted a reference, toss an as_ref on it and move on with life.”
I do have a lot more than a year though.
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.
That said, a lot of stuff is CPU-intensive, which is why Rust, C++, and similar languages are still alive.
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.
I wish cargo/rustc had a "I don't care about borrow checks right now, just don't reclaim any memory, I want to make sure my code does what I want first". Maybe I don't have enough experience writing Rust, but I don't enjoy switching from thinking about domain logic to thinking about memory management every time I want to run a unit test.
That's exactly what C is. The truth is you need to be always thinking of memory. If you care so much about the domain problem, you should choose a different language. Python and javascript are both very good at letting you grapple with your problem, without worrying about the computer.
Once you have solved it, and need a performant implementation, come back and write it in rust. And this time you need to be worrying about memory. C lets you ignore that and that's what rust was designed to prevent.
This couldn’t work because running destructors is sometimes required for actual correctness, not just reclaiming memory. (E.g., you might have a type that writes some records to a file and flushes the outstanding records in memory to disk when dropped)
Abstraction != OOP.
Also, I didnt claim abstraction == OO, but Rust struggles with both.
Luckily, Rust shines in cases where no abstraction is needed.
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.
Actually they are quite worse, because at least with C++ you can make use of binary libraries, so a "make all" only needs to compile your own code, whereas with cargo on its current state is like using Gentoo.
I can’t imagine any language being 5 times as productive as current mainstream projects.
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?'.
Each had a difficult learning curve to learn how to write safe code. At the end of both curves, I look back and see they were about the same.
Seriously, I see this quoted without context all time. They are domain specific languages.
Java with its verbosity and relative lack of language features, partly hidden by powerful but complex libraries? (Partly shared by more potent C#.)
C++ which is only slightly faster to write safely than Rust, you have to be careful to not use unsafe subset, and generic code is more verbose?
C which has even fewer language features than Java and is harder to make safe than C++?
Javascript where it is easy to write bugs, mostly of the null object kind, and hard to handle exceptional situations? With mediocre debuggers? (Also thus used with complex frameworks and libraries.)
Python or Ruby, where instead performance may require dirty tricks using extra time?
Perl? PHP? (Do these even have well working debuggers?)
(Last 5 require additional code for tests due to dynamic nature to ensure correctness too.)
Lisp, Haskell, SML or OCaml where there are fewer quality resources and libraries available to programmers?
Perhaps the less used JVM/CLR or JS languages? (Groovy, Kotlin, CoffeeScript, F# come to mind.)
It's the subsequent debugging that gets ya.
If I ever learn rust as well as I know C, I'm sure my speed won't be any faster or slower. For me, the time to think up a solution is the major chunk, writing it out seems to be nothing in comparison. So why would the language affect that in a meaningful way?
Now, the one way rust can really give you time savings is the lack of entire classes of bugs. I spend 90% of my time fixing bugs in the code my coworkers and I have written over the past year. And most of them are really subtle memory and thread safety problems that are difficult to track down. If rust can eliminate that, I am willing to spend a year getting comfortable with the language.
I also know and are fluent in much weirder, atypical languages, almost esolang, of CRM114 and Faust, and rare ones like Nemerle and Vala.
Rust is pretty pedestrian compared to some of these, rather powerful and generally nice. Writing in Rust feels like writing in a cross of C# and C++20 (less verbose) with a sprinkling of SML/OCaml inspired syntax.
Main slowdown I got was having to write some foreign function interfaces, but it was as nice at it as Python with Cython, nicer than say Vala or Haskell. Much nicer than Java FFI - JNI. Also the common build and package system Cargo was a bit different from what I'm used to, but not altogether bad.
1. The compile times. But those are comparable to C++.
2. The borrow checker and ownership rules. But you get used to those rules and eventually they are ingrained far enough into your brain that you barely run into problems with them anymore.
However one thing that is overlooked entirely here is that writing code doesn't just mean writing code, but also running and testing it, which due to the increased reliability are shorter if not even greatly shorter than most other languages.
So especially compared to C and C++ you end up writing code a lot faster.
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 thing is, designing programming languages is a science, but practitioners often considered a craft. Things like the syntax of C++, the undefined behavior of C, the erasure semantics in Java, the weird semantics of Scala, or the minimal type system of Go all stem from that misconception.
Haskell took the science part serious. It is an academic language, but it tought people what can be done with a thorough design. Rust is the first language, as far as I can tell, that takes that mindset and improves practical programming. Rust is just objectively better than C++ in so many aspects. But it would not exist if it were not for Haskell and a plethora of PL research done in that language.
Most likely Rust wouldn't exist had Java and .NET had been properly AOT native compiled since the first version like Delphi, Oberon, Modula-3, which would have taken away many use cases that people kept choosing C or C++ instead.
Or had AT&T not given up on Cyclone and eventually making into a common UNIX language, like it happened with C++.
It's Go who wouldn't then exist, not Rust.
Both of them wouldn't exist.
Go because it is basically Java 1.0 with AOT compilation.
Rust because C++ wouldn't have become as widespread as it currently is.
Stil trying to catch up with Xerox PARC,
They did what now?! I guess that famous 4-letter compilation/optimization library [1], which had its origins in academia, and which is extensively used by computer scientists as a base for their compiler optimization research, and which is written in C++, and which was originally targeted at compiling and optimizing C and C++ code, is just a figment of my imagination.
[1] It's LLVM.
The highest gains in optimization come not from bit twiddling transformations on integer arithmetic. They come from interprocedural analysis, especially since cache locality is so important these days. Optimizing compilers being written in X is not same as code in X being well optimizable.
C was considered slower in some cases than Fortran because aliasing information. __restrict flag in C fixed that. But C const is not transitive, and const-ness is convention rather than strictly enforced by compiler. This makes optimization hard across API / ABI boundaries. __restrict is also not transitive. If you analyse asm generated by sufficiently large program, you will sure find missed optimizations. C standard even permits any data to be accessed via a char *.
C++, while is C-speed because of direct compilation, value types and manual memory management, has too much of non-obvious performance traps in form of copy constructors, iterators etc.. std::vector can't use efficient realloc implementations, maps have to keep iterators valid, and you don't know when some copy constructor is going to be invoked and allocate memory. C++ is known as fast because its competitors in enterprise space were Java (which is often written with too many layers of indirection, has a memory hungry VM as most popular implementation and lacks value types) and unscientific [0] languages like python. Any sufficiently large C++ project that involves junior engineers will have undesired performance bottlenecks due to the idiosyncrasies of language and its ecosystem.
The massive layers of template implementations also cause performance bugs deep down, like those found in Microsoft's std::vector::insert implementation. Not to mention API practicess that encourage hidden object initialization / copying.
While I don't like the zealot instagram-ish community surrounding rust, I think the language is well designed and it has strong points in these areas. Any reference being immutable xor writeable provides ample opportunities for optimization[1]. Clone operations are explicit. And iterators are well designed. While there are small things like TrustedLen on iterators being introduced only recently, I think rust is much better optimizable than C++ is.
[1] These optimizations are held back by LLVM bug. No LLVM is not the best compiler possible as some people will make you believe. What it gets you in some more optimization passes, you lose in horrible compile times, and mediocre codebase. LLVM is mostly a proprietary-able version of GCC, while its existence has led to some good clang-based tooling in ecosystem, the monoculture is harming advances in compilers.
No, I'm not conflating anything. Your claim was hyperbolic and completely false, and I refuted it.
> [...] that doesn't mean C++ is best language for optimizing i.e code written in C++ provides best opportunities for optimization.
You're moving the goalpost.
It is hard for one to claim compiler research is affected because of most common implementation language. I don't know why you got that interpretation.
> Your claim was hyperbolic and completely false, and I refuted it.
Even GPT3 writes this after getting trained on some HN pages.
Your original claim was: "C/C++ literally killed compiler optimizations research." Your updated claim is: "C++ is [not the] best language for optimizing."
These practical concerns have no place in an ISO standard.
Do you even know what the C++ committee's purpose is?
Writing and selling more books.
All these are affected by evolution of the language. As the standards committee pushes more and more multi-layer templated library features as modern best practices, debug times suffer, error messages suffer, compile times suffer.
The C++ committee doesn't look at prior art in academic literature[0], they don't even consider many implementation concerns which only become apparent after implementations are widely used in real world. The gap between language designers and implementers is obvious.
There are C++ apologists who claim it is because of legacy. Yeah but I won't be buying those books every three years until they half-fix every misfeature in half broken template library way.
> Not in programming terms, but in social terms.
This attitude has changed drastically nowadays.
Lazy-by-default is clearly wrong and clearly a broken design. If that is 'thorough', I fail to see any advantages to 'thoroughness' compared to just making it up as we go along.
And regarding it being "wrong" and "broken", I presume of course that you found inherent problems in the G-machine that you just never came around to publish.
The alternative would be that you are just mentally unable to make the switch away from a strict call-by-value evaluation.
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.
Haskell is definitely my favourite language but I don't think it's the easiest language to write. It could be, with the right set of defaults but it's not - and it's by choice: Haskell wants to be a language to explore language design.
Rust is a production language and solves an interesting set of problems (safety, gc spikes). I don't like the language particularly, but it's concise and it has modern features. It gets stuff done and that's why it's getting popular.
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#.
This is the most probable issue. Rust doesn’t offer anything new or useful for a C# developer, yet have quite a number of drawbacks. Memory safety? Heck, this is exactly what the CLR is about, hence the usual name of "managed code".
Rust doesn't really have fundamental drawbacks other than the fact that there are more ways to store and refer to data (e.g. owned, borrowed, boxed, reference-counted, etc.) and thus you need additional code where you want to support more than one of them.
Of course there are ecosystem differences and learning curves.
This is not just a possibility. This is a certainty. Rust is never going to replace JavaScript or typescript.
There is no such thing as a "C/C++", so how can you kill something that doesn't exist?
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.
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 :/
(It stands for "higher kinded types", which is a feature Haskell is well-known for that Rust lacks.)
and get a valid story
Rust is present in quite a lot of spaces. But companies outside sillicon valley or even the US do not advertise what they are doing as much.
I am as far from SV as possible and a fulltime Rust dev.
So it is more like having one tool more in the toolbox than anything else.
I don't know if they're planning on changing the rest of the compiler to Rust - wouldn't be surprised if they did.
Note in particular that it’s mostly developer-facing infra. The vast majority of production infra - the stuff actually running on all those thousands of servers - is still all written in C++ or Hack.
Rust as a language is mature and pretty stable.
However, the ecosystem... not so much. Pretty much every crate is still at version 0.x, with breaking changes happening constantly. Major dependencies get abandoned.
What is often overlooked is that Rust projects have a very high maintenance cost. Once a project has been written, keeping all the dependencies up to date is a lot of work, that often requires complete rewrites of parts of your applications.
The dependency upgraded to Tokio 0.2.x and I whenever I spend a few hours trying to fix the compile errors I end up giving up. I like to write code to get things done and I don't take pleasure in the extra complexity that Rust brings.
If C or C++ cannot evolve because of backward compat, those language might naturally evolve to adopt features of Rust or haskell. C++ Lambdas are a good example.
It seems that C++20's concepts are a viable candidate to compete with rust safety mechanism.
No, that's not really something that concepts do. But there are ways of coding and tools using which you can get closer to Rust's safety features in C++. E.g. https://www.modernescpp.com/index.php/c-core-guidelines-life... or https://clang.llvm.org/docs/ThreadSafetyAnalysis.html.
There are 10 types of people in this world, those who understand the above summary and those who don't. Those who understand the above summary also understand binary.
Edit: This is far outside the Silicon Valley bubble, in a rather conservative industry (a very large German car parts supplier, though my code won't end up inside a vehicle).
Rust is in no danger of that. Lots of practical problems are being solved in Rust. Lots of great examples are available. And while syntax around borrow/reference annotations can be difficult to grasp, the rest of the syntax is not too bizarre and is largely conformant to what people are used to.
Language itself is a miracle of software engineering, and GHC and cabal are decent.
Many Rust crates are very difficult to understand and use, due to them using tons of abstractions. Macros don’t help either.
As people get more and more familiar with Rust, they write more and more code that only them can understand.
Languages such as Zig and Go are way more limited, and may require typing more characters to achieve the same thing as in Rust, but they force people to write simple, readable, maintainable code.
You are being down-voted for either lying or using such a ridiculous definition of "no one" to push your agenda while disregarding facts.
https://charliereese.ca/article/top-50-y-combinator-tech-sta...
"to push your agenda while disregarding facts. "
I have no agenda, what agenda would that be? What do you think my agenda is? I've written code in 20+ languages in 40 years from 6502 machine code to Prolog, LOGO and Blockly. Everyone of them has strengths and weaknesses. I like coding in most of them.
"while disregarding facts"
What are the facts?
If I have an agenda it's to split propaganda from facts. It's moving software development from strong opinions, fashion and cults towards facts and science, so as an industry and profession we can grow up.
"Haskell didn't solve a real problem"
lead to the downvotes, and not one reply with a counter example.
If Haskell solves a development problem the many people have and struggle with, what would it be? What problem does lazyness solve? I wrote 100k+ lines of Scala code with Monads and Monad transformers, it isn't better than my Typescript code. Purity? Good developers write pure methods in any programming language minimizing side effects. I could go on with immutability, which get's you down a rabbit whole of lenses ( I wrote a lengthy article here https://svese.dev/concurrency-with-immutable-data-primer/ ) with few benefits.
There are two possible prominent explanations for Haskells failure in the development world. First it didn't solve a real problem as Assembler (easier to read and write than machine code), C (everyone did 'C' already with extensive assembler macro collections), Perl (better shell programming), Lua (easy to embed), Java (garbage collection), PHP (everyone who can write HTML can write PHP), JS/Node (people allready know frontend JS), Ruby (Rails) and Typescript (JS with type safety) did and Rust (safe C) now does. Or every developer is too stupid to see the light.
If you disagree with my point of
"Haskell didn't solve a real problem."
you could have a counter argument. Like "From my experience many companies struggle with X, which is essential to their development effort. Haskell does solve X nicely, a magnitude better than competing efforts like A, B and C from working with Haskell in a larger company and B in a startup. My opinion that companies do not use Haskell though is not that it doesn't solve a real problem - as shown above - but because of S and T".
Or you could downvote
"Haskell didn't solve a real problem."
[1] I like to be labeled "such commenters" - though I would prefer "such people", it's meaner and has more punch. So if you go ad hominem, go right for it.
With "no one" I exagerated and meant a tiny fraction of companies [1][2][3]
I will not use "no one" but "a tiny fraction of companies" in the future or at least make a note explaining "no one".
[1] https://redmonk.com/sogrady/2020/07/27/language-rankings-6-2...
plus rust is not as safe as expected in practice, the unsafe mode is underrated.