Live data from Hacker News

Go 1.6 is Released

blog.golang.org

221–230 of 367 posts

Re: Go 1.6 is Released

#221

I've been writing some gocode recently and huge chunk of code is if err != nil ... I know you can do if ; err!=nil but that not that much better and you end up in deeply nested if blocks. i have to mentally block out err !=nil to read any gocode linearly. How is this acceptable, I don't get it. https://blog.golang.org/errors-are-values We recently scanned all the open source projects we could find and discovered that…

Hard to say without specifics, but my experience writing server code in, say, Python, was, I ended up wanting to handle errors in the best possible way, so my code turned into:

    try:
        x := blah()
    except Foo:
        yadadad
which is worse (IMO) than

    x, err := blah()
    if err != nil {
        yadada
    }
Besides the extra syntactic clumsiness, it was really hard to know what was going to throw exceptions, and which exceptions, and when. Frequently I would get bugs from unexpectedly thrown exceptions.

You said "I have to mentally block out err != nil to read...code" -- for me, the error handling code is code, code I want to pay just as much attention to as the non-error path.

So for that reason I really like Go error handling.

For a client-side script or something, maybe this isn't true; feel free to use log.Fatal or panic if that makes sense for your use case.

Re: Go 1.6 is Released

#222

Earlier quoted context omitted.

I don't like Oracle. I don't like the JVM. I refuse to learn Java because I personally have a strong bias for native, compiled code. In fact, I really dislike everything about the Java way of programming. The mental image of a huge ram sucking IDE with code completion for frameworks is simply incompatible with what I would consider the ideal creative process for me as programmer. That being said, if I were starting a…

For my money, Java is a pretty good language; there are only a couple of things that I think were real mistakes in the core language. And the JVM certainly performs. But the ecosystem around Java is very complex and hard to manage. Dealing with JVM configuration, webserver configuration, build system configuration, IDE configuration and God knows what else takes up all kinds of brain-space. And every so often the com…

>there are only a couple of things that I think were real mistakes in the core language.

Type erasure was a pretty big one that I've felt the impact of a few times in the small amount of Java code I've written (99% being school assignments). One of the reasons I strongly prefer C#/.NET as a language/environment. What I've tried of ASP.NET coding seemed nice.

Re: Go 1.6 is Released

#223

Earlier quoted context omitted.

I don't like Oracle. I don't like the JVM. I refuse to learn Java because I personally have a strong bias for native, compiled code. In fact, I really dislike everything about the Java way of programming. The mental image of a huge ram sucking IDE with code completion for frameworks is simply incompatible with what I would consider the ideal creative process for me as programmer. That being said, if I were starting a…

> it would be very hard to persuade me to not choose Java...For better or worse, CS departments across the US produce Java programmers more than anything else. This is actually the reason I would not choose Java. I started programming Java in the 90s and spent the better part of 2 decades writing code in it. The last 8 years of that time, I was a lead developer, so I've interviewed hundreds of Java developers. The mo…

Do you know this essay http://paulgraham.com/pypar.html? Almost exactly your points.

Re: Go 1.6 is Released

#224

I've been writing some gocode recently and huge chunk of code is if err != nil ... I know you can do if ; err!=nil but that not that much better and you end up in deeply nested if blocks. i have to mentally block out err !=nil to read any gocode linearly. How is this acceptable, I don't get it. https://blog.golang.org/errors-are-values We recently scanned all the open source projects we could find and discovered that…

I agree, it's exactly why I stopped using the language. err != nil checks all over the place gave me a headache. I since moved on to Elixir and it's really great. I just wish that it would allow me to have just a single deployable binary. That's something I really miss about Go.

exrm provides a deployable tar file. Granted its not single binary.

Re: Go 1.6 is Released

#225

Earlier quoted context omitted.

Java SE and a fat jar... checks all the boxes and has generics and superior tooling. I still don't get the Go love.

There are less options in golang so its easier to get started or to jump into the middle of a project. For certain classes of problems the golang standard library is dramatically better than the java ones so you don't have to spend as much energy researching alternatives. It tends to perform well by default for web service and/or cli applications. Compared to java it is more terse (though not compared to some jvm alt…

abysmal tooling? ... extremely primitive concurrency support?? Are you talking about Go?

Re: Go 1.6 is Released

#226

Earlier quoted context omitted.

For my money, Java is a pretty good language; there are only a couple of things that I think were real mistakes in the core language. And the JVM certainly performs. But the ecosystem around Java is very complex and hard to manage. Dealing with JVM configuration, webserver configuration, build system configuration, IDE configuration and God knows what else takes up all kinds of brain-space. And every so often the com…

> culture really needs to learn the value of the simple and explicit. This is true for any programming community.

This is my favorite thing about Go.

All language arguments aside, Go coders are usually pragmatic and humble and Go code is usually simple and explicit.

Re: Go 1.6 is Released

#227
post #58

Go has a lot going for it. That said, there were a few points I noted, based on a recent go I gave it (pardon the pun), at least in relation to my style of development for this project: 1. It's hard to tinker, mostly because it's fussy about what variables are defined or used. This is a strength in the usual course, but when one is trying to posit what a poorly documented 3rd party API is doing it can be a serious pa…

As zenlikethat points out, "goimports" works around this weakness. For Atom, this package works great [1]. It's so damn arbitrary, though; it refuses to let you have unused imports (which is not a source of bugs) but will happily allow you to shadow variables (which is a serious source of bugs) without even warning you. Super weird. [1] https://github.com/abiosoft/atom-go-imports

You're looking for go-plus [0]. Set the Format Tool to goimports, check Run Lint Tool on Save, check Run Go Vet Tool on Save, and add these vet arguments: "-shadow=true -shadowstrict=true".

You may have to leave off that last argument for your own sanity. I found that 'shadowstrict' drives you mad at first, but you end up making better code for it -- mirroring my general experience with all the things about go that annoyed me at first.

[0]: https://atom.io/packages/go-

Re: Go 1.6 is Released

#228

Earlier quoted context omitted.

I don't like Oracle. I don't like the JVM. I refuse to learn Java because I personally have a strong bias for native, compiled code. In fact, I really dislike everything about the Java way of programming. The mental image of a huge ram sucking IDE with code completion for frameworks is simply incompatible with what I would consider the ideal creative process for me as programmer. That being said, if I were starting a…

> it would be very hard to persuade me to not choose Java...For better or worse, CS departments across the US produce Java programmers more than anything else. This is actually the reason I would not choose Java. I started programming Java in the 90s and spent the better part of 2 decades writing code in it. The last 8 years of that time, I was a lead developer, so I've interviewed hundreds of Java developers. The mo…

I have a similar experience with interviewing Java developers in offshoring projects, and I started to think like that, until I was involved into similar projects done in other languages and came to the conclusion any mass market programming language suffers from the same sins.

Re: Go 1.6 is Released

#229

Earlier quoted context omitted.

Java SE and a fat jar... checks all the boxes and has generics and superior tooling. I still don't get the Go love.

For me, I like Go's slim profile. Native compilation, aggressive allocation, low memory usage, static compilation. JVM suffers from slow startup times and tends to eat a lot of RAM, even when the app doesn't technically need it around. It has an object model that spawns a bazillion tiny objects, and much of the JVM's GC design exists to cancel out those tiny object allocations. JVM has many upsides (the portability a…

Startup times are largely going to be a thing of the past in Java9. Improved code cache, out of the box optional AOT compilation, and the modularization work is going to be great.

I am running several (albeit Kotlin) daemons right now that are using less than 256MB of ram on my machine. Everything on the JVM is configurable.

At some point, I think it's just simply a matter of taste. If you want to be closer to the metal, then Java (and I'd even argue Go) isn't really the right language for that.

Re: Go 1.6 is Released

#230

Earlier quoted context omitted.

Java SE and a fat jar... checks all the boxes and has generics and superior tooling. I still don't get the Go love.

I don't like Oracle. I don't like the JVM. I refuse to learn Java because I personally have a strong bias for native, compiled code. In fact, I really dislike everything about the Java way of programming. The mental image of a huge ram sucking IDE with code completion for frameworks is simply incompatible with what I would consider the ideal creative process for me as programmer. That being said, if I were starting a…

> For better or worse, CS departments across the US produce Java programmers more than anything else.

That is real a problem of quality of those CS departments.

My humble Portuguese CS department teached me about Pascal, C++, C, Prolog, Caml Light, Smalltalk, Java, Lisp, MIPS and x86 Assembly.

Having a quick look at their current curriculum, now around 25 years later, they seem to still provide a good mix.

Post reply on HN