This is what systems administrators with grey beards thought in the 1990s. A moment's thought about what an attacker who can run a compiler can do instead of running a compiler should be enough to inform you about how silly the idea is in practice.
Joy to ACLs, custom Solaris builds and proper kit (ultra enterprise units the size of a full 42u rack).
I miss those days.
> Funny thing about Go is that as a compiled language, folks often need
> to send the source-code to the deployment servers to compile on them too.
It is generally much easier to deploy a versioned statically compiled binary, compared to rolling out code to production in some languages (ruby, python, etc).
But when someone says they don't understand why someone else would want to do things differently I just naturally want to help them understand :-)
If you have differing operating systems then you have problems, but that's be a build process problem rather than a problem with Go.
The fact that Go relies on return codes instead of exceptions to express errors is what will fundamentally limit the language's adoption, in my opinion.
Anyone who was writing code in the 80's and 90's remembers how fragile and buggy software written this way is (Windows' HRESULT, anyone?). Exceptions have considerably increased the robustness and reliability of millions of lines of code, the software community is not going back to error codes.
Microsoft and Google eschew exceptions, because they cause huge invisible problems in large systems.
Doesn't seem like a situation precipitated by something in Go. I've found cross-compilation to be very easy and effective. Having your build setup on the deployment servers would negate the advantage of the dependency free single-binary deployment.
Not in my experience. Nearly everyone I know who deploys Go code does it by shipping a binary. One of the benefits of static linking.
I don't think the Go developers hide the fact that they mean go as a Systems level programming language. It has higher level features, but the developers don't really mind the fact that Go isn't going to be delivering a whole lot of high level features. Maybe if they come in the form of libraries...
Funny thing about Go is that as a compiled language, folks often need to send the source-code to the deployment servers to compile on them too. I seem to recall that deployment servers shouldn't need to have development tools which were themselves exposing the servers to bad intention by bad folks. It's just hard to keep the separation I guess.
Go error handling is not to be taken lightly just because you can ignore error codes or just print the error and be done with it. I seem to recall that the core developers of Go demanding that Go users try harder to handle errors. Something the compiler doesn't really "enforce".
I prefer Dart to Go because Dart starts from a higher level of abstraction already. Also Dart has been the result of two years of development even if many of the Dart developers also had plenty of experience with developing past languages and tools.
OOP already gives us a lot of bondage and discipline. No need for more incentive by the compiler. Sometimes a couple of extra tools can help our hands without it being forced by the compiler with every run. Say a tool that helps to tell us which methods or variables aren't being used. Go forces us to deal with that on every compiler run. (Even if it can be disabled, but the Go developers prefer to avoid proliferation of config options.)
It's good to have Go and Dart around. So it's not just legacy (Java) and Microsoft (C#) dictating the standards.