Comment by zackmorris | Hacker News Reader

Comment by zackmorris | Hacker News Reader

This is great, I've waited 20 years for this (computer engineering degree 1999). For all the naysayers - what has gone wrong with computing, why Moore's law no longer works, etc etc is that we've gone from general purpose computing to proprietary narrow-use computing thanks to Nvidia and others. VHDL and Verilog are basically assembly language and are not good paradigms for multicore programming.

The best languages to take advantage of chips that aren't compute-limited* are things like Erlang, Elixir, Go, MATLAB, R, Julia, Haskell, Scala, Clojure.. I could go on. Most of those are the assembly languages of functional programming and are also not really usable by humans for multicore programming.

I personally vote no confidence on any of this taking off until we have a Javascript-like language for concurrent programming. Go is the closest thing to that now, although Elixir or Clojure are better suited for maximum scalability because they are pure functional languages. I would give MATLAB a close second because it makes dealing with embarrassingly parallel problems embarrassingly easy. Most of the top rated articles on HN lately for AI are embarrassingly parallel or embarrassingly easy when you aren't compute-limited. We just aren't used to thinking in those terms.

* For now lets call compute-limited any chip that can't give you 1000 cores per $100

I would argue that Elixir is far closer to being a "JavaScript-like language for concurrent programming" than Go, due to it's dynamic typing and relative freedom it affords in comparison to the others you mentioned (except for Clojure, which is actually quite similar in a lot of ways).

Although it is technically a purely functional language, you can almost mutate variables (in reality it is creating a new immutable variable with the same name, which takes precedence)

  a = 1
  # a == 1
  a = 2
  # a == 2

Concurrency feels very natural:

  # concurrent
  numbers = [1,2,3,4,5]
  doubles =
    |> numbers
    |> Enum.map(fn(n) -> Task.async(fn -> n * 2 end) end)
    |> Enum.map(&Task.await/1)
  # doubles == [2,4,6,8,10]

  # consecutive
  numbers = [1,2,3,4,5]
  doubles = numbers |> Enum.map(fn(n) -> n * 2 end)
  # doubles == [2,4,6,8,10]

> Although it is technically a purely functional language [..]

This (purity) stirred my interest, but as far as I can see it's incorrect. This[1] Wikipedia page on pure languages does not list Elixir, and the Elixir Wikipedia page itself does not mention purity at all.

Can anyone clarify?

[1] https://en.wikipedia.org/wiki/List_of_programming_languages_...

> The best languages to take advantage of chips that aren't compute-limited*

FPGAs may or may not deserve that distinction, depending on your point of view.. but even if you concede that, they're still heavily bandwidth limited. An SDRAM interface takes up quite a bit of floor space, especially if you want more than one FIFO to move data with -- and even then, you're still standing behind relatively slow memory interface. There's SRAM on newer chips, but it's still too paltry an amount to really do anything close to general purpose computing on.. especially with the languages you've mentioned.

> why Moore's law no longer works

Moore's law no longer works because we hit 4GHz in silicon, there's nowhere to go but sidways now, and that's true whether you're in dedicated or reconfigurable chips.

> VHDL and Verilog are basically assembly language and are not good paradigms for multicore programming.

Err...I respectfully disagree. They're HDLs and more akin to hardware design than any traditional software abstraction, assembly included.

It sort of depends on coding style - if you're hand instantiating gates and wiring them in verilog then yes it is a lot like assembly ... on the other hand if you're coding in a high level way and having your design compiled to gates then no, it's not at all like assembly

It also may depend on where you learned your craft - my decade as a logic designer seemed to show people who started life as an EE and went straight into logic design coded at a lower level than people who started as programmers (who tended to be more productive as a result) ....

Does your comment imply that people who started as programmers tended to be more productive at FPGA design?

Well (from a VERY VERY small sample) I think yes (I was referring more generally to people doing logic design in Verilog, not just FPGAs) - in my experience they tended to write at a higher level and knock out gates faster .... that left them with more time to optimise their designs

But this is old data - the world changes

In my experience although limited most software developers write terrible HDL code. They think too serially, step wise, and aren't very good at parallelizing their code on the level necessary for good hardware design.

The exception to this are those with good hardware sympathy. They can after carry over that detail oriented thought process.

Maybe, but I'm not talking about beginners here, I'm talking about people who already have years of experience

Actually there is already a Scala version that is well defined. From the website https://chisel.eecs.berkeley.edu/ 'Chisel is an open-source hardware construction language developed at UC Berkeley that supports advanced hardware design using highly parameterized generators and layered domain-specific hardware languages.'

Not sure why they wouldn't use it instead.

It seems to be a particular phenomenon of the Go community that they want to reimplement everything in Go.

You could argue the same thing about Scala too...

Reply on news.ycombinator.com