In the comments he says he changed his mind about Go, and the necessity of the efficiency gain over Racket. So there's some confusion apparently.
https://cxwangyi.wordpress.com/2012/07/22/why-go-use-racket/...
Why Go? Use Racket
11–20 of 59 posts
Re: Why Go? Use Racket
#12I'm sorry you lost me after your outrageous claim that one must learn everything about the standard types of Go before one can program effectively. You should know about how your types are passed around if you are using any language. The example given was arrays in Go. Arrays are passed by value, but slices (pointers to arrays) are passed by reference. This is very simply described in the Effective Go reading. It's n…
Yes, thank you. This was an instant head-scratcher:
"However, the type system of Go is so complex"
The type system is anything but complex, even in the non-system complaints expressed.
Re: Why Go? Use Racket
#13No. Because static typing. However much Go's type system might lack some means of expression, the type system is there, and it prevents many bugs that can easily crop up while using a dynamic language. I'd rather say 'use OCaml' or 'use F#' or even 'use Haskell'.
Or 'use Typed Racket'.
Unfortunately, the article in question did not mention words 'typed' or 'static' at all.
I didn't know about Typed Racket; I suppose it might be a kind of gradual / optional typing somehow simila to what Clojure has.
Re: Why Go? Use Racket
#14No. Because static typing. However much Go's type system might lack some means of expression, the type system is there, and it prevents many bugs that can easily crop up while using a dynamic language. I'd rather say 'use OCaml' or 'use F#' or even 'use Haskell'.
Or Clojure or Erlang. Funny enough out of "functional" languages those have probably just as much (or even more) been used to develop distributed, fault tolerant systems than F# or Haskell. Just saying. BTW both Clojure and Erlang allow a form a gradual typing. From personal experience. I've used both static (C#, C++, Java) and dynamic typing (Python, Erlang), and have to say, the prevents-many-bugs excuse as the mai…
> Or Clojure or Erlang. Funny enough out of "functional" languages those have probably just as much (or even more) been used to develop distributed, fault tolerant systems than F# or Haskell. Just saying.
(I generally agree with the gist of your comment, I think. This just stuck out.)
I don't believe Clojure belongs in that class (as "proven" for writing reliable software), but whatever.
If you want truly reliable software and have the budget, then you just need to throw process at the problem -- it doesn't matter much which language you use. Several (if not all) the Mars landers were programmed in C -- with very few critical flaws experienced/discovered[2]. The Ericsson switches that achieved previously-unheard-of reliability were programmed in Erlang, but they used process and a huge number of engineers to achieve that. (Plus they're mostly stateless and so can just reset if they do it fast enough and don't lose important state when doing so.)
For large-scale software which has to evolve fast, I belive strong type systems do win out. It's not so much that they prevent bugs which could be caught by test suites, but having a strong type system means that you can be certain that there are a lot of tests that you actually will never have to write or, more importantly, rewrite as the system evolves.
There have been actual studies which may be of interest[1], but even if I'm on the "winning" side, I don't think I would put too much stock in the methodology/analysis of this particular study. (E.g. concluding that JavaScript suffers from few concurrency bugs relative to other languages is kind of being oblivious of the fact that JS is single-threaded (semantically) and that all the other languages in the comparison permit "real" concurrency/parallellism, and that it should thus perhaps be excluded from the category or at least treated separately.)
[1] http://macbeth.cs.ucdavis.edu/lang_study.pdf
[2] https://www.usenix.org/conference/hotdep12/workshop-program/...
(Sorry, references out of order because edited-post-facto)
Re: Why Go? Use Racket
#15It's a chicken and egg problem, but the real reason for me to use Go vs Racket is that learning the former will further my career significantly, while latter won't at all. Sad, but true.
Re: Why Go? Use Racket
#16Earlier quoted context omitted.
Or 'use Typed Racket'.
Unfortunately, the article in question did not mention words 'typed' or 'static' at all. I didn't know about Typed Racket; I suppose it might be a kind of gradual / optional typing somehow simila to what Clojure has.
Clojure's gradual typing system is heavily inspired by Typed Racket, which preceded it.
https://twitter.com/ambrosebs/status/262387983339098113
For more information, see Ambrose Bonnaire-Sergeant' dissertation:
A Practical Optional Type System for Clojure
https://cloud.github.com/downloads/frenchy64/papers/ambrose-...
Re: Why Go? Use Racket
#17I'm sorry you lost me after your outrageous claim that one must learn everything about the standard types of Go before one can program effectively. You should know about how your types are passed around if you are using any language. The example given was arrays in Go. Arrays are passed by value, but slices (pointers to arrays) are passed by reference. This is very simply described in the Effective Go reading. It's n…
> I'm sorry you lost me after your outrageous claim that one must learn everything about the standard types of Go before one can program effectively.
I can't help but be amused to see the complaint that Go's type system is, of all things, too complex.
At the time I first picked up Go, Racket was my favorite language of choice[0]. One of the biggest things I noticed about Go was how little I needed to think about types and implementation. Part of this was simply having a static typechecker[1], but part of it is how the rest of the tooling is designed as well.
> How many people programming with Go pass arrays around?
Most people using Go shouldn't be using arrays at all, since they really don't fit most use cases (fixed size and size is part of the type).
[0] For the record, I still like Racket, but I've found I'm undeniably far more productive in Go.
[1] Type Racket exists, but at least at the time, most libraries were untyped, which meant I had to write typed wrappers for everything.
Re: Why Go? Use Racket
#18No. Because static typing. However much Go's type system might lack some means of expression, the type system is there, and it prevents many bugs that can easily crop up while using a dynamic language. I'd rather say 'use OCaml' or 'use F#' or even 'use Haskell'.
Or Clojure or Erlang. Funny enough out of "functional" languages those have probably just as much (or even more) been used to develop distributed, fault tolerant systems than F# or Haskell. Just saying. BTW both Clojure and Erlang allow a form a gradual typing. From personal experience. I've used both static (C#, C++, Java) and dynamic typing (Python, Erlang), and have to say, the prevents-many-bugs excuse as the mai…
Of course everything is a tradeoff; using a static type system is not free. If anything, types also serve as always-in-sync documentation.
Gradual typing that Erlang and Clojure (both excellent languages) introduce is also a tradeoff: you usually want strict static checks on the outer interfaces of your modules, and/or along the most critical chains of computation. So you build it on top of your dynamic language; I've seen such things done in Python, too.
Re: Why Go? Use Racket
#19I'm sorry you lost me after your outrageous claim that one must learn everything about the standard types of Go before one can program effectively. You should know about how your types are passed around if you are using any language. The example given was arrays in Go. Arrays are passed by value, but slices (pointers to arrays) are passed by reference. This is very simply described in the Effective Go reading. It's n…
There are many valid criticisms of go, but the one presented in this article make no sense. Or maybe only make sense if you're a huge dynamic languages fan and can't stomach static typing. Personally, as someone who used to be a huge fan of dynamic languages like Python, I've sobered up as I've grown older and had to fight with large python and JavaScript code bases. A compiler that is fast with clear error messages…
If using dynamic typing like Python's is being drunk, then at least Go is like being tipsy - not quite sober, but quite functioning.
Re: Why Go? Use Racket
#20Racket's website (http://racket-lang.org/) has an "explain" button by the code snippet. Is the existence of such a button perhaps a statement about the quality of the syntax?