[estavaro]

You need to be commended for defending Go.

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.

[tptacek]

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.

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.

[jlouis]

It may have slowed down the occasional attacker who had no access to a HP-PA RISC cross compiler for his platform. But in todays world there is no reason.

[meaty]

Well back in the 90s we kept the machines lean more because disk space was fucking expensive.

[tptacek]

I'm not saying that minimal builds are silly, just that the idea of keeping compilers off systems as a security feature is.

[wglb]

Did they have /bin/sh or /bin/bash or /bin/csh?

[meaty]

Yes but they were only available to one user and that could only log in via the console server.

Joy to ACLs, custom Solaris builds and proper kit (ultra enterprise units the size of a full 42u rack).

I miss those days.

[stock_toaster]

  > 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.

They do? Why not build as part of a CI run? Or via cross compile?

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).

[zaphar]

I don't know that I was defending Go so much as describing why someone would want to use it. It's fine for someone to say they really like the jvm. I like it to. Clojure and Scala are fun languages. The JVM has a lot of really cool technology behind it.

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 :-)

[djhworld]

From my experience if you're running Linux on your local machine and Linux on your server then you can distribute a Go binary to your server and it will run fine. Even if they are different distros.

If you have differing operating systems then you have problems, but that's be a build process problem rather than a problem with Go.

[laureny]

> Go error handling is not to be taken lightly

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.

[Evbn]

Go doesn't rely on return codes. Go has multiple return, and has error objects.

Microsoft and Google eschew exceptions, because they cause huge invisible problems in large systems.

[code_martial]

> 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.

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.

[enneff]

> 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.

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.

[jlouis]

Go is far more innovative than Dart. Dart is, roughly, "We want to have a Java-clone in the browser". Go actually makes an effort at cleaning up C while adding a structural OO model and building in concurrency.

[spankalee]

I'm sorry, but calling Dart a Java-clone is a ridiculous assertion. Care to back it up?