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

281–290 of 367 posts

Re: Go 1.6 is Released

#281

Post by jerf »

pcwalton wrote: post #173
jerf wrote: post #171

Earlier quoted context omitted.

The list of languages that permit that in a principled way is short, and the list of languages where it's a good idea is even shorter. I've come to the conclusion that it's generally not a good idea. (And it's not Go making me say that, it's more Haskell.) Keeping dependencies flowing in one direction seems to be a good plan.

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…

Are we talking about the same thing? That is the most full-throated defense of orphan instances I've ever heard. The reaction to such things is generally... less positive... to put it lightly.

Re: Go 1.6 is Released

#282

Post by mlvljr »

ilek wrote: post #265
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…

Visual Studio is more bloated than IntelliJ or Eclipse? Absolutely not. When I had the displeasure of using IntelliJ it would use 1.2GB RAM for a fucking 5 file project. Debugging would then use another 1GB RAM. Visual Studio uses 1GB RAM with a 150 project solution open, and it opens said solution about as fast as IntelliJ opened that tiny project. Adding something like Resharper (by your beloved Jetbrains) will mak…

Upvoting for bravery!

Re: Go 1.6 is Released

#283

Post by cies »

pori wrote: post #277

Seen a lot of Erlang mentions in this thread. Is that the native alternative to Go? Personally, I prefer to write code in a functional manner. While I've always thought Go looked like an amazing platform for programming in general, I haven't been keen on moving to another imperative language. It seems the landscape for functional alternatives are mainly Scala and Clojure which are both based on the JVM and require a…

> It seems the landscape for functional alternatives are mainly Scala and Clojure

Cannot talk about functional alternatives without mentioning Haskell. OCaml (when abstaining from the "O", as many OCaml'ers do; similarly Scala'ers often abstain from the "O" in Scala) is also an interesting option.

Finally there's Rust, which is besides being a bit more functional also more low-level than Go.

While being fairly young, Frege[1] also deserves a mention. Very similar to Haskell, but on the JVM.

1: https://github.com/Frege/frege

Re: Go 1.6 is Released

#284

Post by twistedpair »

bsg75 wrote: post #38
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.

When different code needs different JVMs, it gets to be a pain. The Go advantage is a fat binary, no dependencies.

> When different code needs different JVMs

With the JVM you can use HotSpot, Dalvik, WebSphere, or OpenJDK. The JVM is just a spec. With Go, you've only got one runtime to choose from. That said, if you code to the JVM spec, then you don't care what implementation you run on.

Re: Go 1.6 is Released

#285

Post by Ruhigengeist »

fleetfox wrote: post #244
no1youknowz wrote: post #64

Earlier quoted context omitted.

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

Any framework has their own. Yii implements active record, I've been working with that for a few years now and I really love the paradigm.

Re: Go 1.6 is Released

#286

Post by autoreleasepool »

pjmlp wrote: post #230
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…

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

I have to admit I'm jealous you had such a diverse exposure to programming paradigms.

I agree it's a problem. I've always found it odd that the AP test is in Java for example. I would imagine pseudo code would be a better choice for a conceptual test.

Re: Go 1.6 is Released

#287

Post by twistedpair »

EugeneOZ wrote: post #95
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.…

How different are people :) I personally prefer raw db queries as more flexible and performant way :) "Typing is not the bottleneck" (c) GeePawHill

As long as you don't want your queries parameterized/precompiled and inputs escaped, rolling your own SQL by hand should work.

Re: Go 1.6 is Released

#288

Post by loudmax »

twistedpair wrote: post #284
bsg75 wrote: post #38

Earlier quoted context omitted.

When different code needs different JVMs, it gets to be a pain. The Go advantage is a fat binary, no dependencies.

> When different code needs different JVMs With the JVM you can use HotSpot, Dalvik, WebSphere, or OpenJDK. The JVM is just a spec. With Go, you've only got one runtime to choose from. That said, if you code to the JVM spec, then you don't care what implementation you run on.

> With Go, you've only got one runtime to choose from.

Since Go compiles to a binary, the concept of a runtime doesn't apply the same way it does for Java. You can compile a Go program with the Go project's compiler or with the GCC. The GCC Go compiler uses different optimizations and may produce faster binaries in some circumstances. Since the Go language is also a spec, other compilers may arise if there's a demand.

Re: Go 1.6 is Released

#289

Post by golergka »

sigjuice wrote: post #175
golergka wrote: post #16

I just recently started with go, but I love how simple (apart from horrible $GOPATH) and effective that is. Still can't get over the moment I realized that in order to deploy my web server on an empty virtual box all I had to so was to build and upload. After all the languages and frameworks that required endless customization and setting up it was a true eureka moment.

What is horrible about $GOPATH?

The notion that you can't put the codebase wherever you want to on your own computer. A "project", as a folder, should be atomic and work regardless of where it is moved; the $GOPATH convention just breaks this encapsulation completely.

For example, when I create client-server projects, sometimes I put both client and server under the same git repository, in the same folder (whether it is a good or bad decision is another discussion). $GOPATH forces me, therefore, to put a client project in the $GOPATH tree, and this just feels ugly.

Of course, you can change $GOPATH per project, and I end up with `export $GOPATH` in makefiles, but this is rather ugly too.

Re: Go 1.6 is Released

#290

Post by pjmlp »

grey-area wrote: post #273
pjmlp wrote: post #238

Earlier quoted context omitted.

The team has already stated "The language design is done".

The issues list has a bunch of breaking changes they've put off to Go2. It won't come soon, but probably at some point they will produce a Go2, if only to fix a few small annoyances and things they got wrong in the stdlib which would otherwise break the Go1 pledge. Of course, that doesn't mean Go2 will introduce lots of huge changes to the language, I doubt very much it would, but it probably will happen sometime. ht…

It was done at one Strange Loop talk if I recall correctly.
Post reply on HN