Comment by centimeter | Hacker News Reader

Comment by centimeter | Hacker News Reader

> FP's conceit is trading performance for correctness.

This isn't even remotely the case. The most popular functional languages are substantially faster than the most popular imperative languages.

Haskell or OCaml both smoke the top 3 imperative languages: Python, Java, JavaScript.

The "conceit" is trading the conceptual model most people learn in high school/trade programming classes for correctness, with little to no bearing on performance.

> Rust is, as far as I'm aware, the first language that allows you to deploy functional concepts as zero-cost abstractions.

This is definitely not the case. You can deploy zero-overhead functional concepts in C++ using template programming, constexprs, etc. Also, "zero-overhead" compared to what? Plenty of functional language have abstractions that can reasonably be described as zero-overhead, like newtypes in Haskell or functorial modules in OCaml. You can even translate the non-monomorphically-recursive subset of Haskell to pure hardware, which is pretty much the definition of "zero overhead".

This article reads more like a regurgitation of taglines than original thinking.

The article shouldn't have brought up points about FP performance that it couldn't really support.

But it's interesting content overall and that was a side point.

I am not too familiar with FP languages, but I must say I have never seen a FP language in low level embedded or GPU code.

Of course there are garbage collected imperative languages which are slower than say Haskell, but can Haskell's speed compare to the most efficient C implementation of a code without making it unreadable?

This is what Rust's promise of "zero cost abstractions" means: if you went all in and handcrafted every pointer it wouldn't become more efficient then it is in it's abstracted form.

Again, I don't know enough about FP languages to make qualified statements, but I thought this was a Rust novelty.

OCaml allegedly has some success stories for this.

Thanks for the tip

https://clash-lang.org/ is a functional HDL. Compiles to VHDL, Verilog, or SystemVerilog. That's lower level than just about anything else you can get code for (I suppose SPICE is even lower level in this sense...)

You're mixing compiled versus interpreted languages here.

I'm responding to the article, which made the claim that the tradeoff when using a functional language is performance vs correctness. This is obviously not true in any meaningful capacity, when the vast majority of imperative language deployments are using languages slower than the vast majority of functional language deployments. The fact that the most popular imperative languages are usually JIT compiled (not interpreted, except python) instead of statically compiled is not relevant to the argument.

The claim wasn't "most popular vs. most popular". Why don't you choose "highest performance `FP language` vs highest performance `imperative language`"?

Also, `FP language` and `imperative language` aren't well-defined concepts (nor can they be, frankly). These are paradigms that languages have varying degrees of support for. So the entire foundation of the argument is meaningless.

It's actually even worse than that. Functional programming is on pretty much all accounts FASTER than imperative programming by design. Imperative programming heavily relies on state mutation and branching. FP relies on immutability, purity and streaming. Essentially all those are properties that make code faster/parallelizable. Yes, you can usually write SOME imperative form of an algorithm that is faster than its FP counterpart, but generally it will be much less readable and maintainable. The beauty about FP is that you can get readable, maintainable code that is often on par or faster than "good looking" imperative code and also parallelizable. Writing imperative, parallel code is often an absolute nightmare, that any entry level programmer and even experienced programmers will get wrong.

In theory purity unlocks optimizing potential, but in practice I don't think what you're saying holds true.

Mutating a value is almost always cheaper than allocating a new version of that value and collecting the old one. I think you're vastly understating the "you can usually" and overstating the "much less readable and maintainable".

Almost every point made here is basically false.

The best performing languages are imperative (C, C++, Rust), with functional languages being at least an order of magnitude slower both in benchmarks and real-life workloads. Whatever properties were supposed to make it faster/parallelizable have clearly not manifested themselves very well after decades.

Imperative and parallel code also does not have to be a nightmare at all, as evidenced by Rust and even Go.

> functional languages being at least an order of magnitude slower both in benchmarks and real-life workloads

Not even the most contrived benchmark games place functional languages an order of magnitude slower than C. Maybe 2-5 times slower on average. Of course, this doesn’t actually matter, because 95% of apps are performance constrained because of architectural reasons, and functional languages tend to scale better in terms of architectural asymptotics.

> Imperative and parallel code also does not have to be a nightmare at all, as evidenced by Rust and even Go.

Go is, by all accounts, a massive nightmare. I think this claim calls your judgement into question.

> Go is, by all accounts, a massive nightmare.

All accounts? That's a pretty strong claim. Go works well at Google.

The final remark about Go is the only possibly valid remark.

I've used Go for both "web routing" and business logic apps and found it fairly nice. In what context and in what way do you find it a bad?

Go was designed as a language with fairly good performance, but with limited capability so that programmers with limited skills would find it hard to get too far into the weeds. It is well suited to undemanding tasks.

Most programming tasks are undemanding, and most programmers have limited skills, so it is a good match for a great deal of routine work. It fits in the same niche as Java, where Java's OO apparatus imposes complications that are superfluous for simple applications, and an actual obstacle in most. So, a language that abandons all that is better in those applications.

Simple tools are not bad except when you need something more. So, my agreement was with the idea in mind of writing Pandoc in Go, which would be madness.

Thanks for the details. I hear what you've said. I agree that Go was built with limited capability in order to make it easy for junior developer. And I agree it can slow down more senior developers at times. Although not nearly as much as I expected when I first started using it.

I don't know Pandoc so I'll take your word for it. I'll also agree that there are entire of classes that Go isn't sell suited for, but we'll have to disagree as to whether it's limiting for the types of applications it was created for. I must not be building the same class of application as you are.

By definition, it is not limiting for the types of applications it was created for. We might disagree on where to put the boundary around those applications. Historically, tools have always found uses beyond their intended purpose, and Go is unlikely to buck that.

It really comes down to whether, while working on a big system, you will discover a necessary task that a language cannot do well. This might be because it lacks a key feature, like bit twiddling operations, first-class functions, or operator overloading. It might be inherently just not fast enough to meet a deadline, or not consistently so. It might not know enough about types to prevent common mistakes, or might lack operations on types needed to direct compilation. It might lack the organizational features needed to make a large system manageable. That doesn't make it a bad language, but would make it an unwise choice for a project that might, as time unfolds, be found to need one or other such quality. Generally, the bigger a project is, the more unexpected requirements surface.

This is where we get to the idea of "dynamic range". A language with a wide dynamic range takes correspondingly long to learn. People skilled in it are harder to find and more expensive to hire, you have fewer of them ready to hand, and those you have are likely to be already busy. Yet, you might need more, and any you have more than earn their keep.

Both of your comments would have been upvoted if they didn't have offensive judgements in the last sentence.

You speak the truth, functional programming languages have excellent performance characteristics when compared to other GC'd or JIT'ed languages.

I'm not sure about FP leading to better architecture, it might just be the type system there, which Rust has adapted (in a slightly less powerful form) as well.

Maybe if you had used Go to solve the sort of problem that it's meant to solve you wouldn't have judged it such a nightmare.

You need to stop reading fp propaganda

This mixes up a few things.

Immutable data means lack of aliasing problems (two pointers to a mutable cell). There are other languages that have this property, notably Fortran. It does allow many speed optimizations, in both parallel and single-thread cases. Yes, this is one of the reasons why Fortran is routinely faster than C on numeric code, and even Haskell sometimes is, too.

It is theoretically proven that any algorithm which uses mutable data can be converted to use immutable data with a penalty on memory and time not exceeding O(log n). In absolute terms, such a penalty can be low, or pretty high (consider working with large bitmaps). There's no silver bullet.

Functional code is often preferred due to its clarity, both humans and machines have easier time reasoning about it, and even formally proving its properties. Sometimes it is just more important than raw speed, but sometimes allows for more aggressive optimizations (rewriting by the compiler) and higher speed.

>Functional code is often preferred due to its clarity, both humans and machines have easier time reasoning about it, and even formally proving its properties. Sometimes it is just more important than raw speed, but sometimes allows for more aggressive optimizations (rewriting by the compiler) and higher speed.

I'm curious if that's really the case in practice. Functional code allows for clever concise implementations and clever concise implementations are notoriously hard to read. Go, for example, is often lauded for it's readability due to it's more verbose and non-clever nature.

edit: To clarify, I mean readability by the above-average programmer not by a world expert who has spent 15 years becoming one with the language.

Where are all the FP competitors for fast programs then?

It's very easy to disprove this comment.

Haskell is pure functional language and uses linked lists as their main list data structure. This is because it is difficult to modify individual elements in an array in a purely functional manner without copying the entire array. Meanwhile using arrays in C or Rust and changing individual elements is not only very easy, it's very fast as well.

The default string implementation in Haskell is built on a linked list of characters and it performs horribly, so Haskell has multiple string implementations. The default string implementation is still often used because it is more convenient. This is an example where writing more readable code also involves making it perform worse. Rephrased: Faster code is less readable in Haskell.

https://stackoverflow.com/questions/13865420/why-is-haskells...

The text type everyone uses in Haskell is Data.Text, which is packed. String is not used for anything performance-sensitive.

Reply on news.ycombinator.com