|
|
|
|
|
|
by Groxx
3442 days ago
|
|
|
Yeah... no, they're not focusing on large. Look at the vendoring hell, the weak typing / nonsense around no-generics vs oh-but-maps-are leading to error-prone switch statements, and lack of control-of-the-language. Larger than Python projects tend to support without pain, absolutely (and that's an important area), but not large. Service-units in a large system, sure, which is likely what many will use it for, but it's just not friendly to millions of lines of code and tens or hundreds of developers. Their solution to things getting out of hand or having performance problems is to divide the system, not to have a system that can handle it. edit: oh boy, right at the top, a winner: Go's design considerations include rigorous dependency management, ... Heck no it doesn't. It has been hacked on by the community, which has thankfully adopted things like Glide and GPS that do things properly, because it abandoned this whole area. As it did with e.g. debugging, for which their official stance is "use GDB, which doesn't really work". |
|
|
What do you mean?
> nonsense around no-generics
What nonsense?
> error-prone switch statements
What makes them error-prone?
> lack of control-of-the-language
What do you mean?
> not large. Service-units in a large system, sure, which is likely what many will use it for, but it's just not friendly to millions of lines of code and tens or hundreds of developers.
There are go-projects like this on github. Not to mention the fact that several large companies run central parts of their infrastructure on go (I recently started working on a go-project that qualifies). I think your belief that the flaws of go disqualify it for large projects is biased on a certain, subjective perception to do things, not the objective absolute truth you are trying to make it out to be.
But even if it was correct, at best you are arguing that their efforts to focus on large software was in vain, but claiming that they don't focus on large software at all is, again, simply completely false. Please try to be constructive, here.
> Their solution to things getting out of hand or having performance problems is to divide the system, not to have a system that can handle it.
Can you give an example?
> As it did with e.g. debugging, for which their official stance is "use GDB, which doesn't really work".
I don't believe that's the official stance anymore. And IMHO, most large applications don't particularly profit from an interactive debugger anyhow (I can't just attach a debugger to a server serving thousands of requests per second and have any hope of getting useful answers). The debugging story of go is much more bound to things like "import _ net/http/pprof" and the like and systems like stackdriver.
Anyway. All of this is pretty off-topic, anyway.