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

131–140 of 172 posts

Re: The State of Go

#131

Post by virulent »

ubercore wrote: post #127

At the risk of lazy-web, I just came off an attempt at writing a small service in Go. I liked the language, but found vendoring and package/dependency management sucked most of my time, and I never reached a workable conclusion. I'd really like to give Go another, heh, go. I know it's an open topic, and there's no true "one way", but I'm wondering how people here would handle this situation. And perhaps it's my Pytho…

I have a similar feeling. I don't really like GOPATH, but I'm trying to come to terms with it.

Your Go "project" goes in $GOPATH/src, i.e. your git repo would be in $GOPATH/src/github.com/user/repo

If you have your main pkg in $REPO/service, then you can build like so: go build github.com/user/repo/service (this can be ran from anywhere as it uses $GOPATH)

If you need to add a dependency, use: go get github.com/.... and go get will add it to $GOPATH/src/ which you can then import.

Re: The State of Go

#132

Post by ubercore »

virulent wrote: post #131
ubercore wrote: post #127

At the risk of lazy-web, I just came off an attempt at writing a small service in Go. I liked the language, but found vendoring and package/dependency management sucked most of my time, and I never reached a workable conclusion. I'd really like to give Go another, heh, go. I know it's an open topic, and there's no true "one way", but I'm wondering how people here would handle this situation. And perhaps it's my Pytho…

I have a similar feeling. I don't really like GOPATH, but I'm trying to come to terms with it. Your Go "project" goes in $GOPATH/src, i.e. your git repo would be in $GOPATH/src/github.com/user/repo If you have your main pkg in $REPO/service, then you can build like so: go build github.com/user/repo/service (this can be ran from anywhere as it uses $GOPATH) If you need to add a dependency, use: go get github.com/....…

Hmm, ok. I think I get that -- I'll have to see if I can symlink into the GOPATH; I feel like I read somewhere you can't. I'd like to avoid making my GOPATH be a subdir in the containing repo.

Thanks!

Re: The State of Go

#133

Post by fitzwatermellow »

From the penultimate slide, a list of upcoming Golang community conferences:

GoCon - Tokyo, Japan - June 21 http://gocon.connpass.com/event/14063/

GopherCon - Denver, Colorado - July 7-10 http://www.gophercon.com/

GolangUK - London, UK - August 21 http://www.golanguk.com/

GothamGo - New York, NY - October 2 http://gothamgo.com/

dotGo - Paris, France - November 9 http://www.dotgo.eu/

Re: The State of Go

#134

Post by gbersac »

insertnickname wrote: post #110
est wrote: post #74

Earlier quoted context omitted.

> extract it somewhere and set some environment variables That's exactly the problems package would solve, well, plus easy update capabilities.

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.

Re: The State of Go

#135

Post by kzvezdarov »

ubercore wrote: post #127

At the risk of lazy-web, I just came off an attempt at writing a small service in Go. I liked the language, but found vendoring and package/dependency management sucked most of my time, and I never reached a workable conclusion. I'd really like to give Go another, heh, go. I know it's an open topic, and there's no true "one way", but I'm wondering how people here would handle this situation. And perhaps it's my Pytho…

There are some good dependency managers out there. I personally like gb: http://getgb.io/, but there is GoDep and GPM as well (which are more similar to Rust's Cargo in the way they work).

Re: The State of Go

#136

Post by Daemon404 »

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.

Dang, I always figured that would be unsafe eventually.

I wonder, does this make stuff like this unsafe:

var thing C.thing; C.somefunc(&thing)

i.e. can stack address change now?

Re: The State of Go

#137

Post by learc83 »

olavk wrote: post #75
learc83 wrote: post #32

Earlier quoted context omitted.

Go gets compared to Rust because go was originally labeled a "systems" language. But the designers had a different older view of what "systems" meant than what is commonly used to day. People heard systems and thought they meant low level/operating system/embedded systems. That is not what Go is good for because it's garbage collected. They also planned to attract C++ programmers, but they've basically been attractin…

Can you elaborate on the different meanings of 'systems programming'? I just thought it meant OS development.

Apparently the creators meant infrastructure like web servers, and database servers.

There is some argument that using systems programming the way it is used today is a relatively modern convention. Here is a hacker news thread where this is discussed a bit

https://news.ycombinator.com/item?id=7009563

Re: The State of Go

#138

Post by pjmlp »

steveklabnik wrote: post #128
pjmlp wrote: post #114

Earlier quoted context omitted.

Besides the sibling post. Xomb, Mesa/Cedar, Oberon, SPIN, Singularity were all written in GC enabled system programming languages.

Yeah, but at least with XOmB, we weren't actually _using_ the GC, as you can turn it off in D.

Thanks for the heads up.

Although given my Oberon knowledge, I would say that was more a consequence of D's GC implementation quality than anything else, right?

On Oberon and all the derived OS, the Kernel module was the only one where GC wasn't used, as it needed to be implemented somewhere.

All the other modules enjoyed access to an OS wide GC.

Re: The State of Go

#139

Post by learc83 »

pjmlp wrote: post #96
_ak wrote: post #87

Earlier quoted context omitted.

The "systems" in "systems programming" can also be interpreted to refer to Google's systems. After all, Go was designed to solve Google problems in a Google environment. That's how I always understood it.

In CS speak that is actually known as "distributed systems", not "systems programming".

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"

Re: The State of Go

#140

Post by ForHackernews »

insertnickname wrote: post #104
rattray wrote: post #92

Earlier quoted context omitted.

> If you really want to install Go via your package manager, Don't most people want to install X via their package manager? > However, this package is naturally on an outdated version of Go I can't tell if you're being sarcastic or not here - why would a package such as this be outdated?

>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.
Post reply on HN