Live data from Hacker News

Go 1.4 is released

blog.golang.org

221–230 of 265 posts

Re: Go 1.4 is released

#221
post #130

Earlier quoted context omitted.

Maybe this will help people (like me, for instance) who are disgusted by the overengineered OOP-heavy approach of most Java frameworks but enjoy the concise and elegant simplicity of languages like Go to finally move over and try out Android development.

Sure, the java bloated ecoystem is a real issue. Yet, imagine yourself building UI component without classes or inheritance ? Can't even say something like "my custom button is a special kind of android button, with just those two methods being overriden". GUI is to me the field where inheritance actually makes a lot of things easier and natural. Now you may end up with something similar using struct inheritance and…

GUI is to me the field where inheritance actually makes a lot of things easier and natural.

I would invert that and say GUI frameworks are why bad OO/excessive inheritance is so ubiquitous. I have no idea why all the major frameworks have these horrible inheritance hierarchies, there's really no excuse for it.

In my UI days, I would avoid this by having a Window or Component class extend nothing, housing the necessary component as a field. I'd extend it only if I had to (rarely, and even then usually just one or two methods), and expose it with a getter. Cleaned things up a LOT.

Re: Go 1.4 is released

#222
post #206

Earlier quoted context omitted.

As with all performance, it really, really, really depends on what you're doing. I _hate_ the Benchmarks Game, but there are some that we are faster: http://benchmarksgame.alioth.debian.org/u32/rust.php

You _hate_ the Benchmarks Game because … ?

Because it's arbitrary, most of the benchmarks aren't useful or interesting, and it encourages a mentality that I find to be a net negative.

Many of the tests boil down to "Does your language have GMP bindings" or "Can you write non-idiomatic code to theoretically make this as fast as something else?"

In other words, I don't find it to be useful, except in the absolute broadest sense.

Re: Go 1.4 is released

#223
post #206

Earlier quoted context omitted.

You _hate_ the Benchmarks Game because … ?

Because it's arbitrary, most of the benchmarks aren't useful or interesting, and it encourages a mentality that I find to be a net negative. Many of the tests boil down to "Does your language have GMP bindings" or "Can you write non-idiomatic code to theoretically make this as fast as something else?" In other words, I don't find it to be useful, except in the absolute broadest sense.

"arbitrary" is just name-calling. What about benchmarks game is arbitrary in your opinion?

Exactly one task might be described as boil down to "Does your language have GMP bindings" and that shows:

1) differences with the same language implementation and same GMP binding

2) differences with the same language implementation with/without GMP (for example, Rust #2 and Rust #1)

3) differences with different language implementations' use of GMP.

None of the tasks boil down to "Can you write non-idiomatic code to theoretically make this as fast as something else?" -- if you don't want them to!

If the Rust programs shown on the benchmarks game are "non-idiomatic" it's because so-far that's been the choice of the Rust community.

You know what you mean by "in the absolute broadest sense" but we don't.

Re: Go 1.4 is released

#224
post #98

Earlier quoted context omitted.

Git is equally hostile to everyone! Long live Git. (Maybe the way to advance the poor Gui user interaction experience is to write frontends for it?)

If they're smart, Perforce will integrate their UI tools with Git. They have by far the best UI for a Git-style SCM.

Plastic SCM has gone this route. http://plasticscm.com/gitsync/info.html

They also offer a powerful diff/merge tool with language-specific support. http://www.semanticmerge.com/

Re: Go 1.4 is released

#225
post #151
post #120

Earlier quoted context omitted.

I see from another comment that this release first happened, and then , afterward , the release was pushed to its “official” Git repository. This is not the way real open projects do releases, and instead indicates that the real development is done in-house and the code thrown over the wall. A name is important, as it is a symbol . As long as the language is called “Go”, Google will always have power over it, no matt…

> I see from another comment that this release first happened, and then, afterward, the release was pushed to its “official” Git repository. You misunderstand. The release was made from the official open source Mercurial repository, and later pushed to the official Git repository, because this release coincides with the project's migration from Mercurial to Git. Every single change of this release was written in publ…

I see; thank you for clearing that up. I withdraw my comment about the release. I would edit it if I could.

Re: Go 1.4 is released

#226
post #143
post #54

This relatively recent trend of company-specific languages annoys and disturbs me. I don’t ever want to be tied to a language and library ecosystem under the thumb of a single (large) corporation. Not Visual Basic, not .NET, not C#, not Objective C, not Go (It’s even named after the company, for crying out loud! Yes it is. Don’t try to claim otherwise). I’ve used Basic, I’ve used Pascal, I’ve used C, I’ve used Python…

But look at other examples. JavaScript became ECMAScript, where ECMA is there to define standards, but still there are a couple of big players from certain companies and still they do Dart, which is mostly a Google thing and is a direct competitor to ECMAScript.. well, ECMAScript 6 at least. Even though it's not a bad language one can see a lot of company interest there. And when you look at Go you see that it is con…

Since you ask: Rust, being a Mozilla thing and Mozilla being a foundation, is certainly a less risky and “fearful” (so to speak) platform in this regard. Go, however light a hand Google might have on it at the moment, still has Google’s hand on it, which makes me wary. Sure, it’s better than Dart (or C#), but everything can point to something which is worse – that is not a good enough reason to accept a thing’s drawbacks.

Re: Go 1.4 is released

#227
post #69

Earlier quoted context omitted.

You should be able to get up and running with Go extremely quickly if your default language is C. If there's a reason you must be using C rather than another language (require manual memory management, require code to be as fast as possible, etc.), then Go might not be applicable. Otherwise, Go feels like an updated C and I don't see a compelling reason not to invest a little time in checking it out for yourself.

> require code to be as fast as possible It's also pretty easy to write the performance critical parts of the code in C and call them from Go.

This will likely not have the desired effect if you are calling into the C code from within a tight loop. Go's C FFI is not low overhead.

Re: Go 1.4 is released

#228
post #66
post #58

Earlier quoted context omitted.

You can still get segfaults in Go. "panic: runtime error: invalid memory address or nil pointer dereference"

But you also get a stack trace without needing an IDE and debugger.

But you can get that in C++ if you really wanted to as well.

I just wanted to point out that not having to worry about segfaults is clearly wrong.

Go doesn't really take any steps from preventing pointers from being null or forcing you to deal with possibly null pointers, or accessing uninitialized maps or slices.

Re: Go 1.4 is released

#229
post #223

Earlier quoted context omitted.

Because it's arbitrary, most of the benchmarks aren't useful or interesting, and it encourages a mentality that I find to be a net negative. Many of the tests boil down to "Does your language have GMP bindings" or "Can you write non-idiomatic code to theoretically make this as fast as something else?" In other words, I don't find it to be useful, except in the absolute broadest sense.

"arbitrary" is just name-calling. What about benchmarks game is arbitrary in your opinion? Exactly one task might be described as boil down to "Does your language have GMP bindings" and that shows: 1) differences with the same language implementation and same GMP binding 2) differences with the same language implementation with/without GMP (for example, Rust #2 and Rust #1) 3) differences with different language impl…

> What about benchmarks game is arbitrary in your opinion?

For example, look at the history of D being in the game vs. not. Generally speaking, all of http://benchmarksgame.alioth.debian.org/play.html#languagex is incredibly arbitrary. I don't think that the maintainers of the game have some sort of moral obligation to support things they don't want to, but it is an arbitrary line which influences what kind of benchmark it is.

As another, the domain of the examples, which are largely related to numeric computing and/or memory usage. Which is fine, but isn't going to give me information about other use cases.

> None of the tasks boil down to "Can you write non-idiomatic code to theoretically make this as fast as something else?" -- if you don't want them to!

Yes, they do. Because one man is not an island: people use the raw numbers of the Benchmark Game to claim "X is faster than Y", even if the implementation of X and Y are totally different than what their implementation would be.

> that's been the choice of the Rust community.

I'm actually not thinking of Rust here. I'm thinking more of languages like Haskell, who have implementations that look significantly more like C than like Haskell.

But regardless of if the implementations are idiomatic or not, it means that The Benchmark Game is useless for evaluating if a program I write in a language is going to generally be faster or not than if I did it in another. Because this isn't the code that I'd write: it's code that takes advantage of every little last corner to get as small a number as possible.

Re: Go 1.4 is released

#230
post #66

Earlier quoted context omitted.

But you also get a stack trace without needing an IDE and debugger.

I've been working with Go daily for a few months now at my job and I'd like to point out that Go stack traces have a really big signal to noise ratio. There is a lot of cruft that mostly nobody cares about and sometimes it can be hard to pinpoint exactly where something crashed (at which line) with a panic. Just saying, they should probably improve it to be less verbose and more concise.

The stack trace contains the stacks of all the goroutines. The running goroutine which caused the panic is printed first, so it should be pretty easy to find the source of the problem. At least I haven't had any issues in debugging complicated apps with thousands of goroutines...
Post reply on HN