Hacker News Reader

Comment by lkrubner | Hacker News Reader

If you have the slightest interest in the issue of concurrency then you should study Erlang and Clojure. Since Moore's Law has largely faded, and we now gain speed by putting more CPUs in each server (rather than having the individual CPUs be faster) concurrency is an increasingly unavoidable aspect of programming. Joe Armstrong (Erlang) and Rich Hickey (Clojure) have both spent an enormous amount of time thinking about how to support concurrency in a programming language. Armstrong talks about a paradigm that he calls "Concurrency Oriented Programming". Armstrong's thesis is surprisingly readable and I recommend it:

http://www.erlang.org/download/armstrong_thesis_2003.pdf

Rich Hickey's video presentation "The value of values" is also a good overview of some concepts that are important to Functional Programming:

https://www.youtube.com/watch?v=-6BsiVyC1kM

View on HN

I think you misunderstand Moore's law. It states nothing about speed, but about chip complexity (number of components in an integrated circuit). Moore's law has been following pretty closely since 1965 (and looks like we will maintain it until 2020 at least at this point).

What we have hit is is the max frequency the CPU can operate at. This is not something Moore claimed (as far as I'm aware). Physics got in the way when the transistors got so small that they can't operate any faster without causing problems.

EDIT: reddit discussion about MHz cap from 3 years ago: http://www.reddit.com/r/askscience/comments/ngv50/why_have_c...

How do you feel about Go?

I think Go is very interesting. One thing that I like about Go is something for which it is often criticized, which is the ability to create a binary that holds all dependencies. Some people are critical of these "fat binaries", but I have lost countless hours dealing with dependency issues, in various languages, and dependency issues are my least favorite kind of computer problem, so any language (and/or eco-system) that gives me an easy way to solve dependency problems is interesting. Likewise, when I work in Clojure I often go with the "uberjar" option to deploy, which often means the only outside dependency is the JVM itself. But Go can go further, as there is no need for some VM, like the JVM.

I agree, shipping the dependencies in a single binary is the easiest way to package software. Nim is the same as Go in this respect: native code generation via compilation to C without a VM. And for me, Nim's Pythonic syntax is hands down more pleasant than Go's or even D's. It's the only systems programming language I've come across where it feels like I'm coding at the speed of thought.

I haven't heard much about Nim (until reading this post). I saw that someone was comparing it to python in a way? What are your thoughts on it?

I believe Nim also has generics and macros.

Reply on news.ycombinator.com