In Go, am I supposed to seed the rand manually? http://i.imgur.com/Rw5afx9.png
Yes. The default seed is 1. You can set your own using something like this: rand.Seed(time.Now().UnixNano())
or, better yet, use crypto/rand to seed it.
Clojure core.async and Go: A Code Comparison
51–60 of 81 posts
Re: Clojure core.async and Go: A Code Comparison
#52Quick 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 do it with channels, but also by extending the go macro itself. The mini compiler behind the go macro is designed to be extensible. In the test suite for core.async the compiler is run through a series of tests using a "runner" implementation of the go macro: https://github.com/clojure/core.async/blob/master/src/test/c...
I've had generators working several times with an approach like this, but as it doesn't really fit with the rest of the library, I removed them.
All that being said, these APIs are internal and could change at any moment.
Re: Clojure core.async and Go: A Code Comparison
#53I 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?
One man's verbosity is another man's clear and maintainable code.
Re: Clojure core.async and Go: A Code Comparison
#54This is very cool and intressting. I have to think about something to do with core.async. This is also a good example why macros are just awesome. Go is a language design to work well with goroutins and channels, but the clojure code looks just as good and readable. You could simply not have such idiomatic use of these concepts without macros. Or am I wrong, can a flexible language like scala or python be extended to…
>but the clojure code looks just as good and readable.
But don't mistake this for having the same runtime characteristics- For what its worth the Computer Language Benchmarks Game shows Go as generally being faster, using much less memory and less code.
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
Re: Clojure core.async and Go: A Code Comparison
#55I 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?
One man's verbosity is another man's clear and maintainable code.
That does not follow. The more verbose code is, the more prone to error and less maintainable it is. Verbosity is never valued in prose; it's superfluous, pedantic and boring. Why should code be any different?
Re: Clojure core.async and Go: A Code Comparison
#56Earlier quoted context omitted.
One man's verbosity is another man's clear and maintainable code.
That does not follow. The more verbose code is, the more prone to error and less maintainable it is. Verbosity is never valued in prose; it's superfluous, pedantic and boring. Why should code be any different?
Verbosity is never valued in prose
Perhaps you don't value verbosity, but fans of Flaubert, Balzac, Henry James, Joyce, Poe, Dostoyevsky and Dickens would disagree with you. Your absolute statement is false when looking at most of the valued literature over the last few hundred years.
The more verbose code is, the more prone to error and less maintainable it is.
I think this is true, but only to a certain point. Past that point the code becomes more difficult to understand and less difficult to maintain (for example all variables with one-letter names, few new lines). So there's a continuum there between terse impenetrable languages, and verbose impenetrable languages on either extreme, and you disagree with the OP about where on that continuum Go falls. It's all a matter of opinion and frankly is more subjective than objective and depends on things like the standard library and culture of the language far more than the syntax.
There are also many other factors in being maintainable and error prone - verbosity is only one of them. So saying that Go is more verbose than language X doesn't really tell us much about how prone to error or maintainable Go is compared to language X on its own. For what it's worth, I find it comparable to languages like C, Ruby or Python in terms of verbosity, which feels about the right place to stop being terse to me. YMMV.
Re: Clojure core.async and Go: A Code Comparison
#57Earlier quoted context omitted.
One man's verbosity is another man's clear and maintainable code.
That does not follow. The more verbose code is, the more prone to error and less maintainable it is. Verbosity is never valued in prose; it's superfluous, pedantic and boring. Why should code be any different?
Try this:
1. Step One Goes Here
2. Step Two Goes Here
3. Step Three Goes Here
Step One Goes Here|Step Two Goes Here|Step Three Goes Here
Re: Clojure core.async and Go: A Code Comparison
#58I 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?
No, it's "just right" for the human mind. It's not too verbose and not too concise.
Re: Clojure core.async and Go: A Code Comparison
#59Earlier quoted context omitted.
One man's verbosity is another man's clear and maintainable code.
That does not follow. The more verbose code is, the more prone to error and less maintainable it is. Verbosity is never valued in prose; it's superfluous, pedantic and boring. Why should code be any different?
So APL is the most maintainable and least error prone language?
Re: Clojure core.async and Go: A Code Comparison
#60Totally off topic, when i see ")))))))" it makes me want to run the other way.
I'll add the classic response of "once you let your editor just handle it for you you forget about it entirely". Because, really, truly, when you code in lisp you're just traversing a very simple syntax tree. If you use emacs/paredit you literally stop typing and start using keyboard commands to "descend down the left branch" or "prune upward 4 times" or "delete this entire branch".
Seconding emacs and pardedit.
The power of such a simple approach to editing is very hard to grasp (even more so believe) until you've actually tried it yourself.