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

241–250 of 367 posts

Re: Go 1.6 is Released

#241

Post by aikah »

hacknat wrote: post #194
aikah wrote: post #179

Earlier quoted context omitted.

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

> Compile-time generics

I don't even know if it's possible at this point, since it would break Go's reflection library. No IMHO it's designed not to be extendable at all.

Re: Go 1.6 is Released

#242

Post by logicchains »

geoka9 wrote: post #193
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.

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

Just http://melpa.org/#/go-rename.

Re: Go 1.6 is Released

#243

Post by _0w8t »

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?

Fast compilation and minimal startup time in Go allows for very fast development feedback similar to what one gets with interpreted languages.

Re: Go 1.6 is Released

#244

Post by fleetfox »

no1youknowz wrote: post #64
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 > but it's a huge drop in efficiency to spin my own SQL. Sorry, I have to disagree. I come from PHP, where when you sneeze an ORM appears. I actually am a DBA also. I am very familiar with SQL and I love writing out raw SQL. I don't see this as a limiting feature. It doesn't affect me at all. There are ORMs for Go as…

What are these ORMs you are speaking of? Only usable ORM i've seen for PHP is Doctrine.

Re: Go 1.6 is Released

#245

Post by dominotw »

dilap wrote: post #221
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…

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

But, You don't immediately handle an exception right there in the same method majority of cases. If I have function for copying files, that function doest know how to handle filecorruptionexception it just bubbles it up.

Re: Go 1.6 is Released

#246

Post by pcwalton »

aktau wrote: post #240
pcwalton wrote: post #173

Earlier quoted context omitted.

I totally disagree. It's not only a good idea, it's essential for certain core functionality to work at all. Take serialization, for example: without this feature it's impossible to write a good serializer as a library without code generation (messy and brittle) or reflection (very slow). To give another example, try writing a linear algebra library that's generic over the data type without this feature (and such lib…

> To give another example, try writing a linear algebra library that's generic over the data type without this feature (and such libraries are essential for high performance graphics programming). I disagree. My best, fastest to compile code has always focused on just one type. You mention graphics programming: for 99.999% of the cases you want to pick a type. Usually, this will be float, and thus for SIMD a 4 or 8-v…

It's very useful to use different types (for example, fixed point) in VBOs in order to save space and/or reduce CPU side processing.

Re: Go 1.6 is Released

#247

Post by oofabz »

fuddle wrote: post #150

Go is great, but I wish they would add terany operator support.

They won't. The Go authors value simplicity. Many people dislike ternary syntax and find it hard to read. Go errs on the side of verbosity and readability. It is sort of the opposite of Perl in that respect.

Re: Go 1.6 is Released

#248

Post by alkonaut »

mwcampbell wrote: post #168
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…

Can you explain why using a plain text editor for a typesafe language is a bit daft?

Because if it's a text editor it doesn't have all the info and functionality you have available in an IDE. Run tests for your current function, navigate to definition, manage large projects, configure builds, see test coverage, step with interactive debuggers, REPLs, vcs integration, symbolic refactorings, autocomplete, etc.

Most of this can be added to emacs too. Then it's an IDE.

Re: Go 1.6 is Released

#249

Post by merb »

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…

Actually JNA is actually way better than Go or JNI. And if you are looking at Kotlin / Scala you won't find yourself inside the object-oriented pain. The JVM is actually not that bad.

Re: Go 1.6 is Released

#250

Post by _pmf_ »

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…

> C derived

What is that even supposed to mean? The semantics and memory model are nothing like C and the syntax even less so.

> generates a single

Just link against static libraries; it's literally a single switch.

> supports concurrency very well

Better than C; much, much worse than C# and I'd argue even worse than Java with j.u.concurrent (want channels? use j.u.concurrent.BlockingLinkedQueue)

Post reply on HN