Everyday hassles in Go

Post by davecheney » Wed, Dec 31, 2014, 7:29 AM UTC

threeseed wrote: post #249

vardump wrote: post #43

Earlier quoted context omitted.

The big thing people miss is that while lack of generics might cost them effort worth X, other Go features benefits them Y. The value of Y is pretty large in case of Go, when it comes to concurrency and language level simplicity. It's hard to go wrong in Go. Whoever designed Go seems to have some experience debugging and maintaining large concurrent systems. When you design a language, you have to be so careful of th…

Nobody is saying Go should rush to implement generics or any other feature. The issue is more the dismissive attitude towards them.

Post by ominous_prime » Wed, Dec 31, 2014, 12:26 PM UTC

TheHydroImpulse wrote: post #257

ominous_prime wrote: post #183

Earlier quoted context omitted.

You don't lose "type safety", as interfaces retain all type information -- you're not casting `void*` pointers (without the unsafe package), and type conversions are limited and well defined. It however does pass the type checking to run-time instead of compile-time, which is a trade-off that some feel is worth the language simplicity.

> It however does pass the type checking to run-time instead of compile-time That's absolutely still loosing type safety. Reflections don't substitute type safety.

Post by NateDad » Wed, Dec 31, 2014, 2:37 PM UTC

ominous_prime wrote: post #104

frou_dh wrote: post #47

Earlier quoted context omitted.

> And in cases where a function returns an error and a value (where the error generally indicates the validity of the value), you'll get a compile error if you don't check the error. This compiles: package main import "errors" func main() { x, err := f() if err != nil { return } y, err := g() h(x, y) } func f() (x int, err error) { return 1000, nil } func g() (y int, err error) { err = errors.New("boo"); return } fun…

This looks more like a bug. The second err is a valid redeclaration, and so should be checked for usage on it's own. Though the redeclaration through multiple assignment is itself a bit of a wart that the programmer hast to be wary of, so it may not be a big deal. In any case, the go compiler is very helpful in most cases, and better tooling can improve things further.

Post by TheHydroImpulse » Wed, Dec 31, 2014, 5:39 PM UTC

ominous_prime wrote: post #283

TheHydroImpulse wrote: post #257

Earlier quoted context omitted.

> It however does pass the type checking to run-time instead of compile-time That's absolutely still loosing type safety. Reflections don't substitute type safety.

No, it's still type safe ( http://en.wikipedia.org/wiki/Type_safety ), memory safe, and free of undefined behavior. There's is no way to use a type contained in an interface as the incorrect type (without the unsafe package, but that wouldn't need an interface anyway), or to inadvertently access or modify arbitrary memory. I also wouldn't consider Go type assertions to be in the same class as reflection. A type asser…

Post by vorg » Wed, Dec 31, 2014, 8:06 PM UTC

Xorlev wrote: post #193

vardump wrote: post #103

Earlier quoted context omitted.

Well, you don't need the JVM and any dependencies it pulls . That's also worth something in the era of "cloud" services. Less to install. Less to update. Ideally you only need to update the deployed application. Which in case of Go is that one binary. Another big thing is that same app written in Go just takes (significantly) less RAM than when written in Java. Go has arrays (and slices) of structs, not just struct p…

Java also has arrays. And on heap/off heap RAM allocation. We deploy all our services as uberjars, we have a single Amazon AMI with JDK 8 installed. It's pretty frictionless. It goes from a simple Gradle project, to a single jar on S3, and pulled from S3 by our AMI. Automatically launches via an upstart script. I'll give you less RAM usage for sure. But when I'm launching a whole VM for a service anyways, I don't car…