Re:Real Go Projects: SmartTwitter and web.go
by acqq on Thursday October 21, 2010 @09:13AM
(#1815221)
> so doesn't depend on a VM
But "dependence" on VM is nothing tragic if the GC is not in the game. If you'd imagine a VM without GC then what remains is just the potential for run-time JIT and optimization which can actually be a good thing! There's a long history of p-code interpreters which provided the more compact code, see http://en.wikipedia.org/wiki/UCSD_Pascal and http://en.wikipedia.org/wiki/Microsoft_P-Code At that time tracing and JIT would have been too heavy thing to do but today it could maybe be interesting to have something like that.
And as far as I know, Go doesn't "depend" on VM but does on GC, but D also generates the native code but doesn't have to use GC and I think that is an important advantage for such a kind of the language.
On a related note, you sound very "dynamic language" centric. Some people actually like static typing, and i won't relaunch the debate here but both sides have pretty good argument, especially when you throw type inference into the mix.
In the static camp, here is a few advantages i can see to go (i'm not actually an user of the language) :
- Easier to get your head around than Ocaml/Haskell - Arguably better than java (pros: actually has proper closures, and a sane system for polymorphism. cons: no generics) - Compiles to machine code rather than byte-code, so doesn't depend on a VM. Can be important for some tasks.
I actually think Go has quite a lot going on for it. It just doesn't have any 'wow' factor. But that's not necessarily a bad thing