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

301–310 of 367 posts

Re: Go 1.6 is Released

#301

Post by bmurphy1976 »

autoreleasepool wrote: post #292
Myrmornis wrote: post #176

Earlier quoted context omitted.

This type of comment is common, but specious. It sounds nice: "what works for you; great! this works for me" but it undermines a large category of important discussions: e.g. analyzing which, out of several competing discussions, is a better fit for large classes of people, or on average. In other words, I think this sort of comment strays too far in the direction of niceness, and tends to undermine simple, and desir…

I didn't even interpret that as politie. That's the kind of "polite" comment I would make if I thought you were being an an aggressive idiot and I didn't care to help you. i.e. You think Andoid apps have the same revenue potential as iOS apps? That swell! Good for you buddy, whatever works for you is fine with me :) (Now go back to your cubicle and stop bothering me me.)

Well that's certainly not what I intended. Only further proves my point that our words can have unintended consequences.

Re: Go 1.6 is Released

#302

Post by randallsquared »

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…

> for me, the error handling code is code, code I want to pay just as much attention to as the non-error path.

You likely want to pay as much attention as required to make things work, but the purpose of your code isn't to generate errors -- errors are what get in the way of the actual purpose of your code.

For people who want to get an overview of what some code does, the error code is interesting only after you understand the actual purpose, and sprinkling the error code throughout the code that describe the purpose of the program causes distraction.

Re: Go 1.6 is Released

#303

Post by jernfrost »

Read the debate with Go vs Java here with interest. I'd like to add a point I think is missed by the Java crowd in favor of Go.

Complexity isn't free. Java might have and abundance of tools, IDE's, language features etc, but you can't claim that matching up every Go feature or tool with something superior found among the huge Java universe makes Java superior in every way.

I find that there is an unfair assumption being used by the Java advocates, here which is that every software developer has a deep knowledge of Java.

As one of those people who can certainly write Java code, but who is not familiar with the Java eco system and has not spend a lot of time with I must say that Go to me is a clear winner.

My exposure to professional Java development has been quite frustrating compared to writing Go code. Every Java project I have gotten has used some different built tool: Ant, Maven or Gradle. They have also all seem to use different IDE's. The complexity of each of these tools is staggering. Considerable time has to be spend learning these tools.

Go in comparison is laughably simple. You can get productive in less than a week without ever having used the dam thing. The tools and the libraries are very quick to get into. In fact I find Go code so easy to read that although I am an iOS developer by trade, I frequently read Go code to understand how various algorithms and network stuff works.

An organization would easily be able to add people to a Go project without much previous exposure to the language. Adding people with limited Java knowledge to a Java project however would be far more expensive. Considerable time would be needed for training.

There is a lot of money to be saved from having a well thought out standard library combined with a simple language with simple well thought out tools.

As a Swift/Objective-C developer, my major gripes with my development process is actually the complexity of the tooling. Both Swift and Objective-C are fairly straightforward languages IMHO. In this regard I greatly envy Go developers although I do enjoy the strong typing and generics in Swift.

Re: Go 1.6 is Released

#304

Post by jernfrost »

coldtea wrote: post #267
jug wrote: post #261

Earlier quoted context omitted.

Go feels similar to where Microsoft eventually wants to be with .NET Core and their native compilation. Other than that competitor, I don't think Go has too many others in the same niche. Maybe D? I love the combo of native code + high level language + single binary in a language that also tackles parallelism. It's as if the Go language designers took a good hard look at Python and went "This is what's wrong with it"…

> Go feels similar to where Microsoft eventually wants to be with .NET Core and their native compilation. Only in that it will end in a native binary. In any other sense Go is worlds behind.

In bloat, yes ;-)

Re: Go 1.6 is Released

#305

Post by prodigal_erik »

thebaer wrote: post #188
prodigal_erik wrote: post #177

Earlier quoted context omitted.

Thanks, I've never seen that used and didn't know they special-cased it until I found https://golang.org/ref/spec#Calls . I wonder why it's not more common...

I'm sure there are good uses for it, but I personally haven't found one yet. I mostly use Go's multiple return values to also return errors -- and that's really like using checked exceptions in Java. So whether it's a try/catch or an if statement, you have to code for these things one way or another.

A try-catch block can cover many complex statements and pushes the recovery code down where you aren't forced to continually reread it. Even if it's possible to write concise Go, nobody seems to be interested in trying, it always seems to become a mess that spends 2/3 of its time on errors.

Re: Go 1.6 is Released

#306

Post by pori »

cies wrote: post #283
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,…

Well, I was tempted to mention Haskell. Problem is, I haven't found a practical use for it. Of all the FP languages, this is actually the one I am most tempted by.

I had forgotten about Rust. Are there major projects being used for this yet? I've heard it's picking up quite a bit.

Re: Go 1.6 is Released

#307

Post by kampsy »

I fell in love with python because it was clean and easy to work with. Like most developers, I used to use c when I needed a performance boast. Then I got fade up and decided to learn a new language that could give me the feel of python and the performance of c. Two languages from a list of 10 passed the above criteria Go and Rust. Java did not even make the list because I Don't use languages that are owned by evil empire's(Oracle).

I went with Go because it was easy to use and understand. I could read other people's code easily( Even with a large code base, I have never found myself scratching my head trying to figure out my own code does), could set up my workspace in less than a minute and all the text editors I used (sublime, Atom, Vim) supported it. I Don't really care about the fancy IDE's. Just syntax highlighting and code completion is good for me.

I started learning go on September 2015. And I have managed to implement the porter stemmer algorithm and an inverted index in it. Miss generics but LOVE interfaces. The fact that any concrete type that implements method 1 satisfies interface 8 is awesome. You can easily reuse code from different package without changing anything.

Re: Go 1.6 is Released

#308

Post by dilap »

randallsquared wrote: post #302
dilap wrote: post #221

Earlier quoted context omitted.

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…

> for me, the error handling code is code, code I want to pay just as much attention to as the non-error path. You likely want to pay as much attention as required to make things work, but the purpose of your code isn't to generate errors -- errors are what get in the way of the actual purpose of your code. For people who want to get an overview of what some code does, the error code is interesting only after you und…

A reasonable attitude for client-side code, perhaps, ('oh it blew up, I'll reopen the app and try again/rerun the script'), but I think not so reasonable for server-side code..

There's element of personal preference here.

The longer I program the more I favor systems and styles that minimize unexpected problems; explicit error handling is very much in that vein.

Another complication is that the word "error" actually encompasses two very different kinds of situations:

(1) expected-but-non optimal external conditions (there's no file at that path, the tcp connection got closed) and (2) unexpected conditions caused by a bug (array index out of bounds, the regular expression typed into the code is invalid).

Handling (1) gracefully is very much part of the actual purpose of your code: files WILL be missing sometimes, network connections WILL die, so it behooves you and your program to think about these situations as first class.

(2) is not part of the purpose of your program, it's an error IN your program. These are best handled by crashing/exceptions/panic.

A lot of languages mix the handling of (1) and (2), e.g. Python and some styles of C++, which use exceptions for everything. Go uses explicit error returns for (1) and panics for (2), which feels right to me.

Re: Go 1.6 is Released

#309

Post by prodigal_erik »

munificent wrote: post #55
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…

> Is there a reason why one of these hasn't emerged/been adopted by the community? Personally, I believe package management is one of those things that really does need an official blessed solution. Otherwise, you have a nasty bootstrapping problem: if there are ten competing package managers, how do you install them, and how do package developers know which one to put their packages in? Collection types have the sam…

Use the platform's blessed solution (rpm or dpkg). It's ridiculous for a language to consider a solution worthy of blessing when it doesn't interop with the one my platform was already using or even the ones other languages have.

Re: Go 1.6 is Released

#310

Post by golergka »

sigjuice wrote: post #294
golergka wrote: post #289

Earlier quoted context omitted.

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

I completely agree that a developer should have the freedom to put the "project" folder anywhere. As a golang newbie, I went through the motions of setting up GOPATH, but did not give it too much consideration. It also isn't clear to me how one might have multiple copies of the same project.

> It also isn't clear to me how one might have multiple copies of the same project.

A lot of technologies employ temporary, cache data storage to build for specific platforms and/or configurations. This data is derived from the actual project, and is not saved in the repo, but it often takes significant time to generate.

For example, I work with Unity3d. Unity3d has a great graphics pipeline; if you release the same project for different platforms, you still have the original PSD textures in source control, and they are automatically exported to relevant graphic formats when you switch between different platforms. However, this generation takes a LONG time on different projects, and you usually have several copies of the project on your hard drive, each with a different platform selected.

git even introduced a feature that is usable precisely for that scenario, worktree.

Post reply on HN