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

101–110 of 367 posts

Re: Go 1.6 is Released

#101

Post by zenlikethat »

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…

I agree Erlang is probably not the correct fit for the average startup, but for some areas it is essentially unparalleled (and businesses have had great success with it). Consider the online advertising industry, for instance -- in order to guarantee the kind of uptime and debuggability that real-time bidding and decision making on ads requires, Erlang is an excellent choice (cf. https://www.youtube.com/watch?v=qURhXHbxbDU).

Re: Go 1.6 is Released

#102

Post by alblue »

duaneb wrote: post #47
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.

Green threads are awkward to express with the JVM threading/memory/io model. The runtime is massive (contrasting to the go model of statically linking deployment binaries). Some semantics (such as unsigned 64-bit integers) are difficult to express. Java's JNI is a PITA. I don't believe go's c bindings are much better, but the JVM definitely has its sore points. Finally, the object-oriented nature of the JVM is someti…

FWIW there have been methods added to the Math class that perform math operations on unsigned integers, allowing a Java int to be treated as an unsigned int (cf long). In addition there have been other libraries such as JFFR and JNA that make it more sane to inter operate with C libraries in a much less painful way. There's even a future enhancement request to add this info a future release of Java.

Re: Go 1.6 is Released

#103

Post by iainmerrick »

StevePerkins wrote: post #79
autoreleasepool wrote: post #43

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…

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

(4) Xcode? There are lots of iOS programmers out there.

Re: Go 1.6 is Released

#104

Post by bmh_ca »

Cyph0n wrote: post #65
bmh_ca wrote: 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…

Oh yes for 4). Why can't I include a package from the current directory? Would it be that difficult to first search for a directory containing a `main.go` before jumping to GOPATH - similar to how Python defines packages with a __init__.py? In addition, once your workspace increases in size, GOPATH becomes a mess in my opinion.

I noted the `vendor` path support in 1.6 (and experimentally in 1.5): https://golang.org/cmd/go/#hdr-Vendor_Directories

Re: Go 1.6 is Released

#105

Post by logicchains »

StevePerkins wrote: post #79
autoreleasepool wrote: post #43

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…

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

Re: Go 1.6 is Released

#106

Post by lobster_johnson »

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…

For a real dependency manager, look at Glide, I think it's nearly as good as Bundler: https://github.com/Masterminds/glide.

It's not a package manager per se — Go doesn't have a package system with manifest files like RubyGems and NPM — but it does manage dependencies in the same way, with versioning constraints and lock files.

Re: Go 1.6 is Released

#107

Post by grey-area »

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

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 Active Record, Sequelize, Mini-mongo, Sql-alchemy, etc, but it's a huge drop in efficiency to spin my own SQL.

There are plenty of ORMs and query builders available for golang, many of which have a very similar interface to AR. I personally use a query builder and let structs be in charge of reconstituting themselves from the db rows returned, and am quite happy with that tradeoff, in fact I prefer it to having objects magically instantiated behind the scenes as in AR. There's no need to restrict yourself to raw sql if you prefer a query builder of some kind or even an ORM (if you don't mind using reflection).

Re: Go 1.6 is Released

#108

Post by aacanakin »

meddlepal wrote: post #8
sinatra wrote: post #5

Go checks a lot of boxes for my ideal language for developing web services: Static type, C derived, has garbage collection, generates a single binary, supports concurrency very well, is opinionated, is small/simple, its community prefers to just use standard lib for most work, etc. Yes, Generics is an issue and so is debugging. But, overall, I can't think of many other options that check so many boxes. EDIT: I must h…

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

Please watch this. https://www.youtube.com/watch?v=5kj5ApnhPAE

Re: Go 1.6 is Released

#109

Post by poooogles »

zenlikethat wrote: post #101
autoreleasepool wrote: post #43

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…

I agree Erlang is probably not the correct fit for the average startup, but for some areas it is essentially unparalleled (and businesses have had great success with it). Consider the online advertising industry, for instance -- in order to guarantee the kind of uptime and debuggability that real-time bidding and decision making on ads requires, Erlang is an excellent choice (cf. https://www.youtube.com/watch?v=qURhX…

Go is great for RTB as well. Easy concurrency that scales very well. Anecdotally it seems a lot easier to hire for than Erlang/functional languages.

Re: Go 1.6 is Released

#110

Post by kasey_junk »

jdcarr wrote: post #90
lobster_johnson wrote: post #60

Earlier quoted context omitted.

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…

What's your use cases where you've found startup time to be a significant issue?

Long running processes without a lot of events can also deal with "startup issues", in that they won't trigger JIT.
Post reply on HN