Hacker News Reader

Comment by swiftcoder | Hacker News Reader

I'll grant you that is probably too complicated an example to appear early in the docs, but how often are you actually building multithreaded job dispatch systems from scratch (which appears to be what this example is doing), and how simple would it be in other languages?

View on HN

Transparently parallel, lightweight tasks are part of the language in Elixir. Fully multithreaded and able to utilize all cores out of the box.

Yes, but the Rust code is the kind of thing you'd write if you wanted to build that kind of thing yourself. I do think normal Rust can get too typey, but this is probably not the best example of that.

This is how simple it would be in Clojure, for comparison:

    (defrecord Task [future task-sender])

Probably used something like this:

    (defn create-task []
      (let [future (atom nil)
            task-sender (async/chan)]
        (->Task future task-sender)))

Not sure it makes sense but a pretty much direct translation as far as it goes.

Having never used a lisp outside an AI class a quarter century ago, that isn't comprehensible to me, and I don't think it is just my lack of caffeine. The rust example makes more sense, but I've used rust for almost a decade at this point and c++ for over three. Familiarity matters.

Yeah, of course. If you show me Brainfuck or APL code I won't be able to make head or tails of it either. But familiarity should never stop one from learning new things, otherwise we miss out on a lot of simple, interesting and useful stuff :)

But honestly only for a very short time. It took me two weeks of learning for Clojure to start looking completely natural to me. Surface syntax is such a trivially minor thing, which is why it seems ridiculous to me that the OP author even mentions things like "Swift uses switch rather than match, such familiarity" among other much more solid points.

So it's the same but without type annotations? Meaning that the clojure IDE has a much harder time providing completion and that you need to write all sorts of tests to get the same guarantees as the rust compiler provides for free. Type systems aren't just about memory representation, they also tell the next programmer about the intent and performance characteristics of the code at hand.

If you really badly want types, you'd slap something like this below it:

    (s/def ::future atom?))
    (s/def ::task-sender async/chan?)
    (s/def ::task
      (s/keys :req-un [::future ::task-sender]))

    (s/fdef create-task
      :ret ::task)

    (stest/instrument `create-task)

But then I don't think you'd reach for something like Clojure if static typing is something that you require.

That's why I moved from Scheme to Common Lisp, it's nice being able to do...

  (defstruct Task
    (future :type Future)
    (task-sender :type Sender))

And have SBCL warn me when I try to jam the wrong type in.

It would be ridiculously simple in go with channels.

Would it though? Just running things 'async' is simple, but it's also simple in Rust. I wouldn't figure writing an Executor would be any easier in Go than the Rust example at https://rust-lang.github.io/async-book/02_execution/04_execu...

As I understand, the idea an executor is to emulate an event queue using threadsafe (hopefully lock-free) queues. Since the language already has goroutines, channels and group waits, I don't think this is something that needs to be built in Go. I mean you can do your rate limiting and retry handling logic outside the language primitives. If you do have to make a task spawning executor, you can do that with channels as well. But it would just be a very thin wrapper.

In golang I think just

    type Task struct {
        Sender chan Task
    }

no?

Reply on news.ycombinator.com