I know a guy who writes everything in Haskell.

He started learning it because his parents got him into a math school (and math schools in Russia use either Python or Haskell), he liked it, but later he dropped out. Today, apart from Haskell, he only really knows HTML and CSS, and maybe some JavaScript.

He writes backend AND frontend in Haskell and uses some kind of JRPC stuff to manage all that. He told me that his life is a pure heaven. He IS RELEVANT (!!!!!!), his apps always run without bugs (because in Haskell you can mathematically prove that there are no bugs), they are performant, faster than C (because you can't write a complex enough app in C that will be as efficient as compiled Haskell, because it's you vs compiler). He doesn't have any problems in life whatsoever. He never got burned out, he never got anxiety or depression. He doesn't act pretentiously and stuff, he's just a normal person who rarely even mentions that he can program.

Science says it can't be done! You can't only know Haskell and be a relevant software engineer! You know what, he didn't _know_ it was impossible. He's like that grandpa from a meme, he got Alzheimers, but because of it he forgot that he had Alzheimers, and now remembers everything.

The fun thing is that he looks like a typical gopnik, with adidas suits and stuff.

What a gem of a person.

I think I'm gonna write something in Haskell over Christmas to finally learn it. Maybe that will make things better - or I'll get enlightened yet more miserable because I wouldn't find a job where I can use it..

that's cool but can he explain what a monad is?

Tried Haskell and hated it. Language server is so freaking slow. Type signature is not really human readable. Have no idea how to optimize performance.

Show us one app he has written, well be the judges of whether it is faster than it is in c

Of course you can write complex stuff in C - e.g. the Linux kernel, or most of Blender. It will also be faster than Haskell because there aren't tons of superfluous copy operations.

@oraro

I took a shot at this yesterday.

https://devrant.com/rants/5000950/...

I think the whole "monads are impossibly complex meme" actually makes people pretend it's an unlearnable thing, it scares people off.

Functors and Monads sound scary, but pretty much any medior/senior developer is most likely already familiar with the concept -- when you call it "a class which implements mappable or flatmappable".

The catch is that for a Functor, a mappable type should be taking in a very generic sense.

And for a monad, both "mapping" and "flatting" are very generic.

What that means is that "a Monad" isn't necessarily a mappable in the sense of being a list/array/collection, but can also be a result, a tree, an option, future, reader/writer, buffer, I/O, etc.

And that "flatten" doesn't strictly mean "eliminate a layer of wrapping", but means "join layers of wrapping using some operation".

@Fast-Nop @h3rp1d3v @EpicofGilgamesh

I've written a lot of production Haskell code.

Most of it for a large pharmaceutical company.

It's NOT faster than C. It's also not easier to write or organize at scale than C.

Of course, you can optimize the fuck out of a Fibonacci generator until it produces near-perfect assembly code. That's possible in pretty much any compiled language.

I would argue that Rust is a great contender for equaling C in performance, while beating C in organizational/scaling aspects.

Haskell gives you extreme control over "compile time type correctness".

That means you can write a Web backend which doesn't just handle all exceptions related to SQL queries and injection -- It can also make sure your HTML/XML/SVG is correct and xpath-traversable, it can make sure your route bindings are type safe at compile time, etc.

For pharma, it allowed us to develop a DSL for polymer simulations where the type checker could easily verify the validity of certain molecular structures/interactions even before running more expensive CUDA simulations.

But Haskell doesn't give you control over the low level "this is how the computer should do it" stuff.

@bittersweet Rust is no contender for C, but for C++. Unfortunately, the Rust folks totally forgot about C programmers because they started that in a company whose main product is one of the largest C++ codebases around.

@Fast-Nop Yet Rust is being adopted as the Linux Kernel's second language -- To replace C in certain parts (mostly for drivers).

Rust is very much unlike C++.

Just like C, it is not object oriented, it has no classes or inheritance.

But my main point is that for all the languages claiming to equal C in terms of machine performance and beat C in terms of human performance, I think only Rust comes close.

Certainly not Haskell. Amazing language for pharma, banking, academia, math proofs -- Not for writing kernels.

Certainly not Go. Great language for DevOps and infra -- Not for writing kernels.

Rust certainly won't replace C completely, but can replace C in some areas, especially places where memory issues/vulnerabilities need to be mitigated proactively.

@bittersweet Rust is what C++ programmers might think C programmers would want - but that is not the case because otherwise, they would be using C++, not C.

Interesting read: https://drewdevault.com/2019/03/...

I expect the tone to become increasingly shrill when it turns out that Rust doesn't get much foothold in the areas where C dominates today.

@bittersweet when I think Rust, I think smoothly running native apps. Code editors, CLI tools, native clients, browsers, etc.

@kiki There's certainly some truth to that -- but there is no reason you can't write a complete operating system including kernel and drivers in Rust.

I think C has been stretched too far for monolithic kernel development. It has been used for areas where a language like Rust fits better.

Using Rust to completely replace C, would probably reversely stretch Rust too far into C territory.

@Fast-Nop

I think comparing Rust to C++ because Go is more like C... that's where that article goes wrong.

Go is a language with automatic memory management, with a built-in garbage collector. It's simple, low on features, but not low-level in terms of execution/memory interaction.

But I fully understand there are reasons to still consider Rust "too young" or "too unstable" for many use cases.

I also think Rust can be overkill in some areas. You could rewrite the PHP interpreter, from C to Rust. But php-src is not that complex, and well-tested, so is the extra safety worth it?

@kiki when I think of C i picture , shit that works and shit that works fast

@bittersweet You're thinking too much of the implementation instead of the language. Go's GC completely misses the whole point of the article.

@Fast-Nop

But yeah whether to use Haskell or Rust or Blockchain or Machine Learning or whatever shiny thingie catches the eye....

-- The first question should always be "Why the fuck should I?"

Special tools should only be used when you have been scratching your head and thinking "We have a problem, and we need to solve it, and this language/technology/tool provides a real solution".

If you work on a supply chain system which must be transactionally consistent at any cost, and have been plagued by uncaught NullPointerExceptions in Java, sure, rewrite the transaction system in Haskell.

Same for Rust: Browser rendering engines have always been plagued by memory leaks. The chat app Discord found that Rust eliminated latency on their servers because there were no GC spikes anymore.

The tool needs to solve a problem.

@bittersweet As I already said, it's not about GC vs non-GC, that's completely irrelevant in that article. If that's your take-away from the article, then you can't understand what argument it is making.

Why does this smell like a deliberate troll post to me...(in the "haha, got you!" sense, not a negative sense). Also,

"because in Haskell you can mathematically prove that there are no bugs" F*, ATS, Idris, etc. can do that to a reasonable extent, because they have general dependent types which can encode arbitrary constraints. Haskell's type system isn't powerful enough. And pedantically, asking a system if there are no bugs at all is also asking to reason about its own consistency, which from Gödel's incompleteness isn't possible...

@Fast-Nop you may find this interesting https://dl.acm.org/doi/10.1145/... (it's ACM so idk if it's behind a paywall, but it also says "open access").

@RememberMe Looks nice in deary, but the problem is that that's a fake Greek antique city, so that's pretty much dead in the water. A Pascalised C is more or less what MISRA-C already provides, as brain-dead as it is in some aspects, but it is actually wide-spread, including tooling and recognition.

@Fast-Nop ? This is about writing low level mechanically verified code. As in, proved via theorem proof and SMT solving. What does that have to do with MISRA?

@RememberMe MISRA aims at the most problematic issues of C already, and it is wide-spread. Academic research is nice, but pretty much irrelevant these days.

Where is the tooling? Where is the ISO standard? Oh, there is none, it's just a paper? Well, there you go. Publish or perish works well within academic circles, but has also relegated academic research into irrelevance.

C did not originate in academia, and for all its faults (among them, no ISO standard), neither did Rust. There is a pattern to that.

@Fast-Nop hmm, I guess a paper does take long to read. Also if your response to anything new is "where's the ISO standard", that's kinda circular and useless, because it's new and standards by definition take time...the point is to discuss the idea. It took CompCert like 11 years to get used in an IEC 60880 project. That's not a very useful standard for discussion.

This has zero overlap with MISRA. It has nothing to do with "fixing" C. It's very much an industry project because Microsoft. The tooling is open source, actively developed, and available on GitHub. It's used in EverCrypt which has contributed code to Linux and Windows, among other things.

The point is to prove high level properties (like straight up resistance to path based side channel attacks) via theorem proof and then extract (not *compile*) readable-enough-for-security-review C. You get to write the C as a C program modulo syntax, apart from some restrictions on references and stack usage and stuff.

My point was that this is how C can be used for low level code with guarantees as well, the Rust way isn't the only way. Also, MISRA only addresses very basic C language issues like undefined behaviour and basic memory safety, and besides it's not widely used outside safety-critical systems. It will do nothing for higher level safety properties like "when someone tries to DDOS this code, will they expend a roughly equal amount of effort as the code needs to respond to the traffic (good) or relatively little effort (bad)?". Also, this particular paper was for cryptography anyway.

"Academic research is nice but pretty much irrelevant these days" sure, dream on lol. Academic research contributes a lot of value to industry, among other things. They sure pay a ton for it.

@Fast-Nop to make things worse Haskell is garbage collected

@saucyatom I downloaded an Haskell manual and as soon as I noticed which it’s more than 1000 pages I understood which that manual is likely to wait for my retirement before being opened again

@EpicofGilgamesh when I think C I think thing that works fast and is prone to memory leaks and buffer overflows.

I'd love to do that. Too bad my math abilities are complete kaka