3 ms·
I think it sums it up at the very last sentence, almost as if it isn't really relevant : "Racket programs build and run much slower than Go programs." Edit: B
by weavie 13y ago
I think it sums it up at the very last sentence, almost as if it isn't really relevant :
"Racket programs build and run much slower than Go programs."
Edit: By this I meant to be agreeing with the above statement that someone will come along and write a post about why Go is better - it's already been done in this one post. Sorry for the misunderstanding..
Obviously, sometimes execution speed is important, and sometimes it isn't - it depends on what you are trying to do.
- coldtea 13y agoIf you see the links after that (and the comments) there were some issues with Racket's GC, and there were some fixes offered. YMMV. That said, of course it isn't "really relevant". Or, at least, it's not all that matters, if Racket offers a superior experience otherwise AND its speed is adequate for the task. Else we'd use C all the time, and nobody would use Python or whatever higher level language.
- brudgers 13y agoThe author's postscript links to this follow-up blog post: http://cxwangyi.wordpress.com/2012/07/29/chinese-whispers-in-racket-and-go/ http://cxwangyi.wordpress.com/2012/07/29/chinese-whispers-in... To me, the speed at which the code executes is a second derivative problem - this is to say that if a language gets version 0.1 deployed two months faster, then it is faster in a more important sense. A hammer and screws is more useful than a screwdriver and nails - intact it is more useful than a Phillips screwdriver and slotted screws.
- agentultra 13y agoThat's only an implementation detail that could one day be overcome. PyPy is an excellent example of why, "X language is slow," is a silly statement. The implementation of the language runtime can be made to be faster. As well as speed being a secondary concern for all but a few application domains.