Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Go

talks.golang.org

Post reply on HN
Print view View original

161–170 of 172 posts

Re: The State of Go

#161

Post by nickysielicki »

iokevins wrote: post #21
nickysielicki wrote: post #10

Earlier quoted context omitted.

I came into the comments to say that I very much dislike this change. I much prefer the extra syntax to not really knowing what '{29.935523, 52.891566}' actually means.

They seem to say you may choose to continue specifying it, as you prefer (?)

Sure, I can write code the way I like. But the readability of code affects everyone, not just me.

Still, 4ad's comment above mine changed my mind. I didn't consider that you can do this with structs already (in spite of the fact that I already do that in my code), and I prefer the consistency to the lack of verbosity.

Re: The State of Go

#162

Post by learc83 »

pjmlp wrote: post #148
learc83 wrote: post #139

Earlier quoted context omitted.

In modern CS speak yes, but the creators of Go were apparently referring to infrastructure types of programs; web servers, database servers etc... Here's a quote from the announcement talk "And it's a systems language in the sense that we intend it to be used to write things like web servers"

If it has servers in the name it is distributed computing. How modern is modern CS? I took my CS degree around 20 years ago with focus on computer architecture, compiler design and distributed systems . Distributed systems literature used in the degree went back to the early UNIX days.

>How modern is modern CS?

The creators of Go were on the team that built UNIX, and they clearly have a different meaning for the word systems.

They were using it to refer to infrastructure, without making a distinction whether it was distributed or local. Something like a compiler would be "systems" program under this definition.

I agree that distributed systems, and systems programming are generally accepted terms of the art in CS now, and even 20 years ago.

Re: The State of Go

#163

Post by socceroos »

DrJokepu wrote: post #34
zak_mc_kracken wrote: post #28

Earlier quoted context omitted.

I'm puzzled about the asymmetry of the syntax. What's the reason behind map[Point]string as opposed to something more symmetrical?

It makes sense if you're used to Go. In Go, in function declarations return types come after the argument list, e.g: func doSomething(input string) string { ... } The go map declaration syntax is analogous to the function declaration syntax: the keyword (map, analogous to the func keyword) followed by the type of the keys in brackets (analogous to the argument type in parentheses) followed by the type of the values (…

I've never seen that explained so succinctly. Thank you.

Re: The State of Go

#164

Post by blt »

microtonal wrote: post #47
acomjean wrote: post #5

Pretty neat, go is now written in go "Go 1.5 has no C code in the tool chain or runtime.", go shared libraries interoperable with c. I'm really a go tinkerer, but I like the langauge. I didn't realize Garbage Collection was so expensive that the goal is to only have it run 20% of the time. But its a good goal. "Run Go application code for at least 40ms out of every 50ms."

go shared libraries interoperable with c. How does this work? As far as I understand Go is moving to a copying collector, so any pointers passed to C may become wild pointers when garbage collection is performed. On go-nuts, Go's developers have been warning that passing arrays to C by getting the address of the first element of the slice will be unsafe for this reason.

some GC languages pause garbage collection while calling out to native code. under this scheme it's no problem to call C to do something like multiply matrices or compute hash functions. the problems come when you want the C code to call back into GC code, for example an event loop or a huge computation that wants to report its progress.

it's hard. mixing manual and automatic memory management is tricky.

Re: The State of Go

#165

Post by justthistime_ »

kibwen wrote: post #160
jcranmer wrote: post #118

Earlier quoted context omitted.

Go was first publicly announced in November 2009, Rust in July 2010.

At the time of its announcement, Go was tremendously further along in its development than Rust was at its own public announcement. Knowing modern Go, you can go back and understand Go code from 2009. Knowing modern Rust, trying to read code from 2010 is essentially impossible.

I wouldn't say "further along". Deciding to not tackle any medium-to-hard problems just allowed them to be finished far earlier with their language.

Re: The State of Go

#166

Post by insertnickname »

ForHackernews wrote: post #140
insertnickname wrote: post #104

Earlier quoted context omitted.

>I can't tell if you're being sarcastic or not here - why would a package such as this be outdated? Because of the way software is packaged in most Linux distributions. The upstream version is frozen in that particular release.

One would hope that being six to ten months behind the development branch wouldn't make very much difference. If it does, I'd argue Go isn't mature enough for general use yet.

It's not behind the development branch, it's behind the stable branch. The stable branch is called stable for a reason, because it's stable. You can still use the older versions and they're not bad, but the newer versions have brought improvements, and I see no reason why Ubuntu shouldn't package new stable versions when the Go team is committed to stability.

Re: The State of Go

#167

Post by insertnickname »

gbersac wrote: post #134
insertnickname wrote: post #110

Earlier quoted context omitted.

To install simply download the tarball, extract it to /usr/local/ and add /usr/local/go/bin to your $PATH. If you want to install it to a different location (I like to keep it in my home directory), you just to set $GOROOT to that path and set your $PATH accordingly. To update, just remove the old go dir and extract the new tarball in the same place. I'm ok with it.

Simply is never that simply. There is always something that happen to suck in IT. You think you have done everything right and sometime, you just made a little misinterpretation that screw everything and you can lose a lot of time figuring out what. That being said, I had no problem installing go on my ubuntu, despite the fact that I consider that the installation process sucks.

$ wget https://storage.googleapis.com/golang/go1.4.2.linux-amd64.ta...

$ tar -C /usr/local -xzf go1.4.2.linux-amd64.tar.gz

$ echo "PATH=$PATH:/usr/local/go/bin" >> /etc/profile

That's it, it is that simple. All you have to do now is set your $GOPATH, and you would need to do that even if you had installed Go through a package.

Re: The State of Go

#168

Post by enneff »

aikah wrote: post #85
zak_mc_kracken wrote: post #28

Earlier quoted context omitted.

I'm puzzled about the asymmetry of the syntax. What's the reason behind map[Point]string as opposed to something more symmetrical?

makes little sense but since go doesn't have user defined parametric types, it makes no difference. Now I wish I had 1 million dollars and a better brain to work full time on a proper language that would fix go's issues. What a missed opportunity to create something everybody would be comfortable with. It could have been the biggest language of the next 20 years in webdev, CSP is a great concurrency model. At least i…

> something everybody would be comfortable with

Not possible.

Re: The State of Go

#169

Post by enneff »

ForHackernews wrote: post #140
insertnickname wrote: post #104

Earlier quoted context omitted.

>I can't tell if you're being sarcastic or not here - why would a package such as this be outdated? Because of the way software is packaged in most Linux distributions. The upstream version is frozen in that particular release.

One would hope that being six to ten months behind the development branch wouldn't make very much difference. If it does, I'd argue Go isn't mature enough for general use yet.

The Go project makes stable releases every 6 months. They are extensively tested and fully compatible with all previous major releases. But we do introduce new tools, libraries, and minor language features. Developers almost always want to be using the latest stable release of Go. (There's seldom a reason not to.)

Re: The State of Go

#170

Post by enneff »

microtonal wrote: post #94
mkpankov wrote: post #91

Earlier quoted context omitted.

> similar timeframes I hope you understand first stable release of Rust happened less than 2 weeks ago (15 May 2015), vs. Go's Go 1 in March 2012. 3 years is pretty big difference.

I hope you understand first stable release of Rust happened less Of course, but Rust has been in tech news for a while already. E.g., the Rust 0.1 post garnered 82 comments[1], over 3 years ago. Rust seems to be first mentioned in a submission title 5 years ago. Of course, their inception was not exactly at the same time. But if we look back in 20 years, it's the same timeframe. Just like e.g. Python and Ruby, despit…

I find your perspective a little bizarre. For instance, if we look on a galactic time scale, Lisp and Go were created at pretty much the same instant!

It's not fair to Rust to compare it to Go, as if they are at the same stage of their adoption and development. Several years is makes a big difference in the tech world.

Post reply on HN