Live data from Hacker News

Clojure core.async and Go: A Code Comparison

blog.drewolson.org

31–40 of 81 posts

Re: Clojure core.async and Go: A Code Comparison

#31
post #4

I have never used Go or Clojure, but this is the first time I have heard of Go as being verbose - or is that just in comparison to Clojure?

It's the difference between "programmable programming languages" (which the lisps are, as are haskell and ruby) versus "languages for programming in" (exemplified by go and java).

Go code is very terse compared to the general run of "languages for programming in". And if you know the language, you can just read it.

On the other hand, you've got some serious digging to do if you want to understand a clojure macro. Metaprogramming like that is seriously brain twisty.

Re: Clojure core.async and Go: A Code Comparison

#32
post #30

Quick question for anyone here familiar with core.async: Would it be possible (and if so what would be the simplest way) to implement something like Python's generators and `yield` statement in Clojure using core.async? I'm thinking something like: (defn range [n] (generator (loop [i 0] (yield i) (when ( 0 (generator) ;; => 1 ;; etc )

You could presumably do this with core.async, but the more idiomatic solution to generators would be lazy sequences.

Re: Clojure core.async and Go: A Code Comparison

#34
post #30

Quick question for anyone here familiar with core.async: Would it be possible (and if so what would be the simplest way) to implement something like Python's generators and `yield` statement in Clojure using core.async? I'm thinking something like: (defn range [n] (generator (loop [i 0] (yield i) (when ( 0 (generator) ;; => 1 ;; etc )

I dunno, but I can do it in go :-P

  func generator(values ...interface{}) func() interface{} {
    c := make(chan interface{}, len(values))
    for _, v := range values {
      c 

Re: Clojure core.async and Go: A Code Comparison

#35
post #28
post #27

Earlier quoted context omitted.

terseness is not a feature Go is striving for. That being said, it's still more terse than most other statically typed languages, simply due to type inference. You do have to write out some loops that other languages provide syntactic sugar for... people from those languages call that verbosity. Gophers call it clarity :)

Well, it's not so much syntactic sugar as having the power to abstract them away via generic functions like map, which I'd argue are both more clear and less error prone.

> power to abstract them away via generic functions

It will take a while for that in Go, if ever.

Re: Clojure core.async and Go: A Code Comparison

#36
post #16
post #8

Earlier quoted context omitted.

The i is scoped differently in clojure than in golang so it doesn't have the same potential pitfall. I think golang people consider their scoping here a mistake (and have tooling to check it?).

C# had the exact same pitfall and it was recognised years ago. It's unfortunate that it made it in to Go.

Did they introduce a language solution for it in C#?

Re: Clojure core.async and Go: A Code Comparison

#38
post #32
post #30

Quick question for anyone here familiar with core.async: Would it be possible (and if so what would be the simplest way) to implement something like Python's generators and `yield` statement in Clojure using core.async? I'm thinking something like: (defn range [n] (generator (loop [i 0] (yield i) (when ( 0 (generator) ;; => 1 ;; etc )

You could presumably do this with core.async, but the more idiomatic solution to generators would be lazy sequences.

Oh for sure, more as an exercise in curiosity than anything else. (Although I am also playing with generator- and iterator-like abstractions as part of a resource-scoped foldable stream abstraction to help process big files.)

Looks like I managed to answer the 'is it possible?' part of the question anyway -- something like this:

    (defn range
      [n]
      (let [c (chan)]
        (go
         (loop [i 0]
           (>! c i)
           (if (

Re: Clojure core.async and Go: A Code Comparison

#39
post #26

Small bug irrelevant to the main point of the article: The very last golang example has a leak. If the timeout does occur, main will exit after a timeout and the spawned go routine will hang on the channel push. I think the easiest fix is to make the channel buffered. "make(chan string)" => "make(chan string, 1)" Not sure if there is a more idiomatic golang way to accomplish this.

Once main exits the program does as well, so all other goroutines will be terminated.

True. Leaks don't matter for programs that exit immediately. I was pointing it out because it is often relevant when using the timeout pattern.
Post reply on HN