Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.6 is Released

blog.golang.org

Post reply on HN
Print view View original

191–200 of 367 posts

Re: Go 1.6 is Released

#191

Post by logicchains »

dlsniper wrote: post #117
logicchains wrote: post #105

Earlier quoted context omitted.

What does the Go plugin for IntelliJ offer that Go plugins for Emacs don't? My setup right now has live error checking (highlights errors as they occur), gofmt on save, safe refactoring via gorename, jump-to-definition, proper autocomplete, and Go Oracle integration, for e.g. finding all callers of a method. Due to being Emacs it also has much better support for Vim keybindings via Evil mode.

Debugging, cross-platform, integration with a lot of other languages, and databases, local history, out of the box configuration for everything you've just mention (including the Vim key working mode, via a plugin) so that people don't spend time in doing all of that and so much more :)

In what way is IntelliJ more cross-platform than Emacs?

Re: Go 1.6 is Released

#192

Post by curun1r »

autoreleasepool wrote: post #43
meddlepal wrote: post #8

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…

> 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 most kind way to describe them, as a whole, is uninspired. If I were more honest, I'd say that the vast majority of Java programmers are completely unqualified. There are very few Java programmers who write code because they have a passion for it and it shows...most just learned Java to make lots of money.

On the other hand, if you were to choose a language like Go or Erlang, you'd get less than one tenth of the resumes for your open position, but the majority of those resumes would be highly qualified. The reason is that each of those candidates was motivated to learn a new language solely out of curiosity. You'd be automatically selecting for intellectual curiosity and that's a powerful tool that will save you hours upon hours sifting through Java candidates who are simply a waste of your time.

This isn't an indictment of the Java platform...it's no longer my favorite programming target, but there's nothing fundamentally wrong with it from a technical perspective. It's just a recognition that more != better when it comes to language ecosystem. Quality matters.

Re: Go 1.6 is Released

#193

Post by geoka9 »

logicchains wrote: post #105
StevePerkins wrote: post #79

Earlier quoted context omitted.

> 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. Java has long been my primary professional language, and over the past few years Go has taken on a strong secondary niche at my job. I'm big fan of both, and tend to play Switzerland in arguments between them. That being said, the best Go…

What does the Go plugin for IntelliJ offer that Go plugins for Emacs don't? My setup right now has live error checking (highlights errors as they occur), gofmt on save, safe refactoring via gorename, jump-to-definition, proper autocomplete, and Go Oracle integration, for e.g. finding all callers of a method. Due to being Emacs it also has much better support for Vim keybindings via Evil mode.

Are using go-projectile for all of that? If not, what did you use for gorename integration?

Re: Go 1.6 is Released

#194

Post by hacknat »

aikah wrote: post #179
hacknat wrote: post #97

Earlier quoted context omitted.

0. It does dynamic linking on most stdlibs (libc, etc) 1. What do you mean self-hosted runtime? Anyways, golang will likely never be a good candidate for kernel development, but in theory you could do it (go supports assembly) 2. Generics would be nice. Who knows, maybe they'll be in 2.0? Go wasn't developed in llvm, because they wanted to build something very fast, and they were planning on writing the compiler in g…

> 2. Generics would be nice. Who knows, maybe they'll be in 2.0? There will be no 2.0 and there will be no generics, at all.In fact there will never be any changes to the type system, cause it's impossible at this point.

Not that I even care that much, but that's total crap. Compile-time generics, which is what most people seem to be referring to when they say they want generics in Go, are eminently doable. It would not be hard to implement. Runtime generics are probably possible as well.

What are you even basing your assertion on?

Edit:

What do you mean, "there will never be a 2.0"? Do you have a crystal ball?

Re: Go 1.6 is Released

#195

Post by bschwindHN »

jonesb6 wrote: post #32

The reason I love Go is that every time I pull it out, I write a small amount of it and it runs beautifully. For example my company has a critical micro-service implemented in ~300 lines of Go, it's been running for six months now without a single hiccup, highly performant, very sexy. The reason I will almost never use Go for web apps is because interaction with databases is limited (almost entirely) to raw queries.…

> Maybe I'm spoiled by the likes of [...] Sequelize

Sequelize was a huge drop in efficiency for me any my team. As soon as you go outside of the typical select-where statements, it completely falls apart. I spent hours manipulating that horrible "almost-SQL" syntax to get it to spit out the query I wanted, and often I would just give up and fall back to using a raw query. Yeah, it's great that you can use raw queries when you need, but I soon realized that I almost always wanted to use them.

I switched to KnexJS which has syntax that is practically one-to-one with SQL and have had very few problems since then. Generated queries are much more predictable and easy to write, and it forces you to improve your SQL skills. I view that as a good thing.

Re: Go 1.6 is Released

#196

Post by lopatin »

eddiezane wrote: post #34

I've really enjoyed the time I've spent with Go but feel like the state of dependency management has kept me away. Am I being stubborn in my longing for an npm, Ruby Gems, or pip? Is there a reason why one of these hasn't emerged/been adopted by the community? (I'm aware of the 1.5 experiment with vendoring.) Semver and pinning versions has always just made sense to me. I can easily adopt new features and fixes autom…

I agree that it's necessary to pin dependency versions down somehow. So I commit my Go dependencies into my project's version control. I heard Google does this internally too, but I can't confirm that. But I can say that I've had zero problems using this dependency approach for building web systems in Go.

There's just something about the ecosystem of dependencies. Most of the deps I use are considered to be done. They are simple, small, and orthogonal to each other.

Maybe it's because of the convention to make your library implement interfaces defined in the standard library. Maybe it's some kind of ingenious magical feedback loop where, since there is no package version manager, authors are encouraged to write once and then publish finished products instead working on overreaching and interconnected packages that get API changes every month. Therefore alleviating the need for a package version manager.

My point is just that I wouldn't want people who are considering Go to immediately write it off because of the lack of a standard dep version manager. You can lock dependencies with godep. Or you can check in your dependencies to your project's source control. Either way, even though it's unconventional, it most likely won't be a problem.

Re: Go 1.6 is Released

#197

Post by iofj »

Others wrote: post #186
fleshweasel wrote: post #39

Earlier quoted context omitted.

Is "alternates" a euphemism for "code duplication?"

Or code generation?

I'm getting furstrated by code generation. I have a big project with has 3 files with (only) generated code. It's essentially repeating the same 15 lines about 50 times with slightly different types.

And yet I far prefer all of them over an interface{} solution. Works so much better. But the files are just so ugly, and changing them is rather hard.

Worst of it all, I've been thinking about generating other pieces of the code. For instance, I hate the http handlers and structure surrounding them being the same thing all the time.

Http handlers = decode and basic argument validation, then authentication and CSRF protection, and then conversion (to be done ad-hoc because no types in http parameters), some using strconv, some using json encoding, all with "error handling" (essentially if error then bailout 502), followed by calling the actual method. All of them are the same (save for small bugs due to me not paying attention).

I'm thinking of replacing it with generated code.

Re: Go 1.6 is Released

#198

Post by pa7ch »

tptacek wrote: post #187
kasey_junk wrote: post #165

Earlier quoted context omitted.

Oh my god...is that new? I swear I've tried that and it didn't work. You are my new hero. [edit] Though maybe I was thinking of adding parameters like https://play.golang.org/p/FKUMlQzCI5 In any case 'thebaer continues to be my hero.

It's how html/template.Must works, isn't it? We have a small library of functions for sweeping up error returns, and for collecting errors from multiple functions and checking them all at once. It helps a lot . Golang is very much on to something with it's "errors are values" philosophy, but I'd be the first to acknowledge that it's not a fully baked philosophy. It is weird to discover fundamental things about how to…

Would you, by chance, be able to link or share that error lib? I'd love to see more solutions for error handling to get a better grasp.

Re: Go 1.6 is Released

#199

Post by iends »

iofj wrote: post #197
Others wrote: post #186

Earlier quoted context omitted.

Or code generation?

I'm getting furstrated by code generation. I have a big project with has 3 files with (only) generated code. It's essentially repeating the same 15 lines about 50 times with slightly different types. And yet I far prefer all of them over an interface{} solution. Works so much better. But the files are just so ugly, and changing them is rather hard. Worst of it all, I've been thinking about generating other pieces of…

Have you looked at http://goa.design/ which kinda describes what you are talking about a bit (for REST apis).

Re: Go 1.6 is Released

#200

Post by dominotw »

jimjimjim wrote: post #166
dominotw wrote: post #89

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…

No point in raising an error if you aren't going to do something about it. If you don't care about an error then don't check it. If you do care then handle it. and you don't need massive if blocks, you can use more early returns as part of the err checks.

I don't exactly understand what you are suggesting. Ofcourse, I care about error and want them to be handled. Problem often is that method I am in doesn't know how to handle the error and have to bubble it up to a place where there is knowledge about how to handle it.

Here is Erik Meijer talking about golang exception handling

https://www.youtube.com/watch?v=a2ihmMmSfwk&t=577

The golang guy doesn't answer the question properly and repeats "exceptions are not for control flow". Really disappointing answer and cringeworthy interview.

Post reply on HN