5 ms·

I suspect that the kind of scaling Go was intended for was programming scale. A lot of the design of the language seems specific for large scale projects (stat

by afhof 14y ago

I suspect that the kind of scaling Go was intended for was programming scale. A lot of the design of the language seems specific for large scale projects (statically compiling everything, not having unused variables, explicitly naming all imports, fast compiler, test and benchmarking as builtins, code changing via go fix). These are problems I have seen with larger java projects with unused imports, unused variables, library dependencies, long compile times, etc. I think that Go's niche is for extremely large projects, but it remains to be seen if it will work.

enneff 14y ago
> I suspect that the kind of scaling Go was intended for was programming scale. Your suspicions are well-founded! http://talks.golang.org/2012/splash.article http://talks.golang.org/2012/splash.article
taligent 14y ago
IDEs have flagged and/or auto-corrected unused imports/variables for well over a decade now. And the issues with library dependencies/compile times generally only exist for large projects. And many frameworks e.g. Play don't have compile cycles. Personally I see Go being perfect for smaller web apps that would be super fast on an EC2 Micro. For the higher end apps the JVM is proven and far more flexible.