Hacker News Reader

Comment by rad_gruchalski | Hacker News Reader

For me, Erlang was the ladder to functional programming. Once I’ve mastered Erlang to be able to write gossiperl (http://gossiperl.com, not maintained in a long time), all immutable programming became easy. Maps, flat maps, recursion, no side effects, all became clear.

After Erlang, I’ve enjoyed Scala a lot. Especially Akka.

I do tons of go now and when I need actors in go (not very often because channels are rather straightforward), I use proto.actor: https://github.com/AsynkronIT/protoactor-go.

Erlang is awesome. I can definitely recommend the “Designing for scalability with Erlang/OTP”: https://www.oreilly.com/library/view/designing-for-scalabili.... This is the book which finally made me “get it”.

View on HN

> all immutable programming became easy

Switching to the functional style of logic from the algorithmic style can be slightly tricky but as for immutability itself - since the introduction of for-each loops which freed us from incrementing counters I could never understand why is immutability not the default in all the popular languages. Programming algorithmically I rarely need to change a variable even in C# or Python. The fact they don't have a syntax for defining single-assign values (like val in Scala) annoyed me since I learnt Scala (which is extremely easy to start with - you can use it just as "better Java", advanced functional programming tricks are entirely optional) and realized I mostly use "val" naturally. If a variable I defined is changed - it most likely is by a mistake or some unexpected behavior taking place. Both C# and Python already have "var" to define a variable with its type inferred, why won't they add "val" to tell the compiler it can only be initialized once and never assigned again? To me it seems trivial for a compiler developer to add and also not breaking anything while bringing quite a lot of value by eliminating a whole class of bugs.

couldn't you use the readonly modifier in c#?

I do, occasionally. But it looks annoyingly verbose (which to me already feels enough to avoid using it too much) and IIRC has some limitations (I can't remember) as compared to Scala's concise and universal `val valueName = value`.

Is ”algorithmic” a synonom for ”imperative” in this case? I haven’t seen this usage before.

Yes. "Imperative" probably is the right word. I don't read much programming literature. You probably are correct.

I mean I understand "an algorithm" as a sequence of commands and a functional program as a pipeline of functions.

> I could never understand why is immutability not the default in all the popular languages

My take (could be wrong, happy to be corrected): Because most PL designers want speed to be pre-eminent in their language. One of the quickest way to never have your language adopted by large corporation is to have it be slower, without some obvious great benefit in productivity.

That's the catch though: Arguing for increase in productivity is harder, because it is qualitative, and ultimately subjective. Plus it's a crowded market these days in language productivity land, and unfortunately most of those languages are dynamically typed. Showing some benchmarks on paper is easy to do, and an easy way to sell a language.

So how does this all tie back in? Well, if you want to go fast, you need mutability (and up until most recent times: shared mutable memory, although this appears to be changing to non-shared mutation models). As memory and workloads get bigger and bigger, the cost of copying increases.

Immutability being the default does not prevent mutability.

Obviously. It's just makes it an available option and the default. And this already is helpful.

Immutability is not inherently slower. It provides for much better reasoning that may even result in superior performance.

Of course retroactively introducing them to a largely mutable language may not prove to have better performance, but eg. Haskell is most definitely not slow.

> I could never understand why is immutability not the default in all the popular languages

At what point do you shift the blame for bad code from the language to the programmer?

If you made variables const by default bad programmers will simply mark everything mutable.

The only way you enforce proper constness tags (or mutable tags) is through code reviews and teaching people better. So the default doesn't really matter.

Erlang was a gateway to functional programming for me too, specifically Haskell. (And Emacs!)

I have definitely noticed a functional programming to golang pipeline. Multiple people used Haskell and switched to Golang.

Interesting anecdotes.

When you're dying from the compile time of functional languages, you really appreciate Golang's near instant compiles.

That's mainly Haskell and Scala. OCaml and Elm have as fast or faster compile times.

Not all functional languages are made alike. OCaml compile times can rival Go's.

The cause is not being functional, but having dozens of extra features and multiple syntaxes for the same thing, both Scala and Haskell suffer from that. On the other hand OCaml is very fast and Elm is the fastest compiler I've ever seen. Edit: oops there was already a similar comment when I posted

> Elm is the fastest compiler I've ever seen

Compared to the other languages you mention there, I'm not surprised that Elm has the fastest compiler; compiling to an actual binary (or something low-level like JVM bytecode) definitely seems like it would take more work to compile to than something much higher level like JavaScript, especially if you're performing optimizations at each intermediate layer. That's not to knock Elm though; obviously having a fast compile time is a good thing regardless of the reason, and it certainly still would be possible for someone to accidentally write a slow compiler to JavaScript!

Compiling to binary can be plenty fast, especially JVM code. It’s optimisation that really takes time.

In a modern stack though, compiling a JS or Typescript project takes ages; I don't believe it's the rewriting, optimizing and minification per se, but more the huge amounts of code and files that need to be processed.

Elm is fast because it does only the subset of Haskell’s feature set. It doesn’t have as strong a type system, it uses eager evaluation and I guess it mostly falls back on the JS runtime for optimizations.

In reality the Elm compiler is probably orders of magnitude slower than clang, it just has much less work to do. A C++ compiler needs to parse / preprocess 100k+ lines of code even for something like hello world.

I would appreciate it if golang was any good. Unfortunately, it isn't. (It isn't functional either, so I'm not sure what point you were making)

I don’t think this comment adds anything to the discussion. Perhaps add a few of the anecdotes? Or even a theory as to what’s going on?

May you elaborate? Some Haskell users I know are not fans of Golang. What were the reasons for the switch?

If you like elaborate[0] typing and immutable everything, Go really is not the language for you.

[0] I don't know Haskell that well, but my understanding is that its type system is capable of expressing more intricate types than the Go type system.

I was tired of having to provision the runtime and dependencies.

Native binaries with no dependencies was the reason to change to go.

Reply on news.ycombinator.com