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.
> Rust is trying to be a better C++. And it addresses C++ issues directly in ways that are relatable to C++ programmers.
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.
> 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.
Just because C++ is unsafe by default that doesn't make it less high level.
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.
Still, it makes testing and finding bugs much easier, because you can relatively easily ensure correctness of the safe part of code, and unsafe parts get visible.
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.)
> 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.
All our linux kernel module and driver development have been using Rust for a while. I've written a Linux kernel module in Rust that we use in production, and so have many others.
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.
> Google, ... which big company isn't using Rust at this point in production?
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.
> You missed Amazon, Google, the Linux kernel, Microsoft, Apple, ... which big company isn't using Rust at this point in production?
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 never get called to fix stuff on weekend unless I get a nice pay check for my weekend going bust, no matter what language we get to use, so is the beauty of union agreements affecting everyone across the company.
> 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.
I think introducing Rust would be great! 50% of the people at my company would suddenly stop producing any work at all, which is a huge improvement over the negative work that is currently produced.
I mean, given that Amazon, Google, Facebook, Apple, Dropbox, Mozilla, etc are all using Rust for important parts of their infrastructure, I think "making it easy to write useful programs" is not one of Rust's weaknesses.
Yes, it's not as "easy" to pick up as C or Python, but it also prevents footguns introduced by those languages.
No, the companies you listed wrote a PR blog posts or two saying they use Rust for a component or two, for a minor or internal product. Saying they are using it for "important parts of their infrastructure" is quite a stretch...
Is Dropbox's sync engine a minor product? The entire reason why Firefox has gotten much faster over the past few years? Linkerd? What about Amazon's Firecracker, powering Lambda and Fargate?
Rust is very niche within FB and not used by the overwhelming majority of teams. It is less important to FB than C++, Python, Objective-C, Java, Hack, and Ruby.
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)
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.
> You manage memory in Rust about as manually as you manage memory in Python,
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.
I haven't written a huge amount of Rust, but I feel like I understand it well enough to not have much of an issue with this. It seems like what Rust really want you to think about is not so much memory management directly, but ownership.
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.
I admit that this is to some extent memory management that you have to think about. However especially when it comes to concurrency, this is stuff you have to think about in any language.
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.
It is the experience you have once you get over the hump. It is not the experience you have at the start. This gap causes a lot of arguing on the internet.
That just isn’t true. Rust certainly gets easier with time, but managing memory is absolutely not as simple as in Python. I’ve been using rust full-time for a year and don’t consider myself a particularly stupid person.
I have incredible bias here, but this is my experience. I never think about memory management in Rust. I write code, the compiler yells at me when I make a mistake, and then I fix it. There’s no huge amounts of time thinking about this at all. That’s the compiler’s job!
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.”
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.
> Its 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...)
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.
> 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".
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)
> 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".
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.
Rc<RefCell<...>> / Arc<Mutex<...>> and borrowing or locking for micro-scopes, only exactly when you need the inner values, will get you pretty far when you're looking to turn off your brain. Sometimes they're even the correct choice! It's not entirely frictionless, but it can get pretty smooth. Cell / Atomic* can be nice too.
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.
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.
Well it is subjective. That's why I wrote it may be good or bad. But those from dynamic typing backgrounds may find structural typing more natural. I don't bother as long as there is a way to implement an interface without lot of subclassing boilerplate.
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.
I've been programming almost three decades, and I agree that the soft parts takes most of my time, almost all time honestly. But when I DO know exactly what todo then my colleagues are faster with a combo of Python and C, compared to just C. We can actually drop numbers for that. On the flip side you are probably right in the sense that this has more to do how we work than what language we use. I'm sure Rust would be fine, or if we had some C++ code base we were familiar with.
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?'.
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.)
I find this sort of comparisons dubious. For me, who's a total rust noob, C is 10x faster than rust, because I need to keep looking up rust syntax for basic things like for loop.
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 agree, if you're learning a language you will be slower with it. I wrote this from a perspective of having used them for a reasonable time, and I used most of the above fluently, except C#, Ruby, Perl, functional bunch, which I've only used for small side projects. (And I have not mentioned Fortran which we also used a bit, Borland Pascal, Object Pascal AKA Delphi, Visual Basic, C64 Basic, QBasic, x86 and ARM assembly.)
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.
Quite debatable. Yes, there are moments when I'm getting stuck for a long time, but I'm still learning. Java was definitely simpler to learn. But on the other hand Rust makes writing convoluted code almost impossible. I don't see reference hell like I often see in Java programs. Making dependency cycles and global state so hard is IMHO a big win in bigger projects.
That does not seem true at all. The only two things that slow you down is:
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.
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?....
I don't believe that. They are better at general purpose programming than regular languages. And I don't think they take longer to read in terms of distinct operations.
Do you have any code examples of array languages being used for general purpose tasks? Clis, web applications, anything with lots of branching, games, etc?
I'm experienced in both, and IME Rust isnt that much better than C++. It's generally more fun than C++ and a bit safer, but all in all it's not 5x better, not even 2x... I'd place it around 1.1x perhaps.
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.
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.
Nope. With the success of Rust, Haskell has won. Finally.
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++.
Not to mention C/C++ literally killed compiler optimizations research. C++ committee's ignorance towards practical concerns such as debug build performance, error messages, build times and ignorance towards prior art has kept programming world 20 years behind.
> Not to mention C/C++ literally killed compiler optimizations research
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.
You are conflating two different things. LLVM and GCC are __written__ in C++, that doesn't mean C++ is best language for optimizing i.e code written in C++ provides best opportunities for optimization.
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.
You didn't understand what I meant. I didn't move the goalpost. You understood what I meant only after reading that sentence.
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."
> Do you know what standard 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.
But it is a social aspect. When I started PL research, practitioners scowled upon academia because they considered their legacy issues so much more important than these "Sound typesystems" or even "verification". They basically acted like high schoolers confronted with mathematics: "Yeah, but who needs that stuff? We know how our language parses and we don't care that our compiler is turing-complete as it essentially interprets a half-assed meta language on top, because we cannot see any practical relevance for static analysis besides intellisense. Let us instead discuss this feature here for that special industry use case and how we can abuse some existing keywords to get it implemented."
> ...but it tought people what can be done with a thorough design.
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.
Before you criticise a programming language you should really at least try to learn a bit of terminology. Otherwise you might come across as an uninformed douchebag. There is no such thing as "lazy by default". Haskell is just lazily evaluated, which is one of the well known possible evaluation strategies.
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.
As a big Haskell fan I love laziness and completely disagree with otabdeveloper4. On the other hand, others are entitled to their beliefs and opinions. Even if we think otabdeveloper4's assertion was false I don't think it needs any response as it wasn't an invitation to discussion. I think the Haskell community will come off far better if we avoid petty spats.
As much as I love Haskell, once you start caring about performance, laziness and GC gets in the way.
Records are still a pain to deal with.
Prelude is not safe.
Async exceptions bit you like in most other languages.
String, bytestring, text exist.
There's also tons of extensions which I hope were a default in a production language.
The language is huge.
I doubt having dependent types is a factor.
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.
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 choose syntax that is similar, if not exactly based on math. I would argue that all other programming languages have chosen completely arbitrary syntax, we’re just used to them.
> 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 offers data-race freedom and in general correct concurrency (e.g. it's impossible to access mutex-protected data if you don't hold the mutex), correct handling of objects and invariant preservation due to shared xor mutable (e.g. can't pass an array to a constructor that stores it in a field, and then modify the array in unrelated code that kept a reference, breaking the class invariants), better exception safety since exception propagation is explicit, a macro system, deterministic finalization, no GC latency, reduced memory utilization, better code generation, better cross-platform support, ability to produce lighter C ABI dynamic libraries.
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.
> 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 not just a possibility. This is a certainty. Rust is never going to replace JavaScript or typescript.
No language has ever had total domination. Maybe C and C++ in the 1980's came the closest, but they brought Awk and the shell with them. There are always tasks for which a different language gets the job done faster, or more simply, or is subjectively prettier.
"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.
I'm using it right now while getting paid for it. In fact, my client suggested that we use Rust, and I was happy to comply.
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).
They do use it, but it is snowflake projects versus what they invest in C++, with seats at ISO C++ table and resources contributing to clang/LLVM, alongside their own in-house produced languages.
So it is more like having one tool more in the toolbox than anything else.
At least at Facebook, Rust usage is definitely not "snowflake projects". Last I heard, there's an entire team dedicated to Rust Developer Experience, and several pieces of extremely core Facebook infrastructure are now in Rust. This includes the front-end for Hack (the compiler for PHP that powers the vast majority of Facebook), Eden/Mononoke (the source control/file system manager at Facebook), and Libra (that weird blockchain thing).
Those sound big and important but they are a tiny drop in the bucket of FB infra.
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.
In these big companies, one can find pretty much any language being used somewhere.
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.
I more or less abandoned a hobby project because of this dependency bitrot. I was using a library that was using a lot of generics/traits and Tokio 0.1.
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.
You mean the Silicon Valley bubble of reality distortion. It's become so far disconnected from the information technology industry that it's rapidly becoming irrelevant. Outside, in the trenches, one won't find much Rust. Or Haskell.
Every one of those companies have extremely robust business models (ok npm I have no idea about), high profits and are not going anywhere. You are mistaking them for loss leader unicorn startups.
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.
You need to consider most of those companies are so big they probably use every one of the top 20 languages. You argue as if they were ONLY using Rust.
No, but they are using it in critical parts of some key products, and in those parts, Rust is enabling them to write better code that requires less maintenance.
On the opposite side of the world (Melbourne Australia), we’re seeing More and more people use Rust at work. I personally know about 8 local companies using it in production
"solving real problems of an average company, day to day problems" - like providing Windows and Mac computers to employees, and providing cloud computing / server services?
Just to throw some anecdata back at this overly broad statement, I use Rust full time at work and maintain some embedded crates with moderate download numbers. I suppose I mustn't exist then?
Languages, spoken or computer, are adopted following the laws of natural selection, learning curves matter. A lot. It's preferable to have 2 passable developers than a very competent one on a new awesome language.
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.
So do you mean there are 11 kinds of programming languages: the ones people discuss about, the ones nobody uses, and Rust?
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.
IMO what killed Haskell was weird syntax, and the lack of examples of practical problems that are solved in Haskell. No matter which tutorial you look at, it'd be this impenetrable high brow solution to some really trivial problems that do not exist in the real world. Spherical cow in a vacuum, if you will. If you wanted to learn by example, there, by and large, wasn't an example to learn from. There still isn't. Epic fail.
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.
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.
Hahahahaha - sure this got karma-killed on HN where people love Haskell without having written one line of code. I've been paid for writing code in 10+ languages over 35 years, I have written Haskell code and Haskell does not solve any real problem. Same goes for F# so no one uses it.
Ah sorry, took a look at your website, you're selling "Haskell consulting", so I might have insulted you personally with my post - which was not my intention.
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".
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.
I don't think this kind of thing really needs to be engaged with. Let such commenters stew in their own juice. Pushing back only adds flames to the fire.
Thanks though for helping my point. No argument that counters my post but an ad hominem attack [1]. The state of our industry in 2020.
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.
c++ advances fast there days and it has no problem to fend off rust to me. for C, there is no way, it is the root of so many systems, imperfect, but worked well so far.
plus rust is not as safe as expected in practice, the unsafe mode is underrated.
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.