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

61–70 of 271 posts

Re: The State of Go

#61

Post by ori_b »

perturbation wrote: post #58
eternalban wrote: post #28

Earlier quoted context omitted.

You jest? Go is GC'd just like JVM. The only possible benefit -- even if Go catches up at runtime -- is the compact form of memory objects in Go vs Java object. But then again, if you are writing such systems (in either language) you are very likely to spend quite a lot of time in 'unsafe' land.

Doesn't Go have the potential to be faster than Java since it's compiled to native code (rather than compiled to byte code)?

Java is also compiled to native code, but only after it runs for a bit.

Re: The State of Go

#62

Post by lmm »

Mithaldu wrote: post #52
admax88q wrote: post #38

Earlier quoted context omitted.

They're probably using Gerrit. Although I agree, I don't think merge commits are ugly. I think people coming from SVN/CVS where history is strictly linear have this obsession with keeping it that way. In fact I find lots of developers just have an obsession with "clean" history, and fetishes for particular tools. It baffles me.

> I think people coming from SVN/CVS where history is strictly linear have this obsession with keeping it that way. This has absolutely nothing to do with those, especially since they didn't even allow cleaning up histories. There is one very simple reason for why some developers prefer a linear history of master: It makes debugging very easy. With branch merges, especially when the branch lines cross, or the merge i…

Linearized histories are much harder to find bugs in. You end up looking through revisions that never existed; in SVN you merge the remote history into your local history without it ever showing up as a merge. The explicit git approach tells you something much closer to the truth.

Your condescension is only hurting yourself.

Re: The State of Go

#63

Post by kasey_junk »

Mithaldu wrote: post #59
kasey_junk wrote: post #53

Earlier quoted context omitted.

> What exactly is weird about that? I have no idea what they specifically mean, but I can tell you, that the github requirement of pr to come from public repositories on github is something that bothers me occasionally. There are lots of reasons why I may not want my github fork to be public or I don't want to have a github fork at all but do want to contribute to a repo hosted there. This is a distributed version co…

Honest curiosity here. Given that there's nothing stopping you from deleting your fork after the PR is done, what reasons can you name for this: There are lots of reasons why I may not want my github fork to be public or I don't want to have a github fork at all

The simplest reason is if what I was contributing was done on my employers time and they have strict IP restrictions. It is much, much easier to vet a single changeset than it is to a) verify a whole repo history and b) coordinate around my public/private github identities.

Re: The State of Go

#64

Post by enneff »

tylertreat wrote: post #60
enneff wrote: post #37

Earlier quoted context omitted.

> if you are writing such systems (in either language) you are very likely to spend quite a lot of time in 'unsafe' land. I don't think that's necessarily true. Go does a much better job than Java at letting you manage your allocations and re-use memory. You can write tight, performance-critical code in Go without resorting to 'unsafe'; it just requires care, as it does in any language.

I don't know if I completely agree with this. To write truly performance-critical Go, you end up throwing away many of the language's qualities. Channels are slow, defers add overhead, interfaces add overhead (e.g. I2T), etc. Don't get me wrong, I like Go, but in my (and others I work with) experience, it's not the right choice for performance-critical systems.

I disagree with "channels are slow". They may be faster than you think. Defers needn't add as much overhead as they do today; this can be fixed.

I think it really depends on your definition of "performance-critical". I agree Go isn't suitable for all performance-critical tasks, but it covers a vast swathe of them quite comfortably.

Re: The State of Go

#65

Post by justinmk »

Mithaldu wrote: post #41

Edit: This commit was written to the original submission: https://talks.golang.org/2015/state-of-go.slide#7 -------------- It seems like these people simply don't understand Github very well. Can only view diffs on a single page (can be very slow). Cannot compare differences between patch sets. Accepting a patch creates a "merge commit" (ugly repo history). Don't use the merge button, just add the requester's repo as…

> Don't use the merge button, just add the requester's repo as a remote to yours

Actually, you don't need to do that. GitHub provides a special pulls remote "namespace" on the upstream repo, so you can add it as a fetch pattern to your .git/config like so:

    [remote "upstream"]
      url = https://github.com/neovim/neovim.git
      fetch = +refs/heads/*:refs/remotes/upstream/*
      fetch = +refs/pull/*/head:refs/pull/upstream/*
Then when you `git fetch --all`, you will have ALL pull requests available in your local repo in the local pull/ namespace. To check out PR #42:

    git checkout -b foo refs/pull/upstream/42

Re: The State of Go

#66

Post by Mithaldu »

lmm wrote: post #62
Mithaldu wrote: post #52

Earlier quoted context omitted.

> I think people coming from SVN/CVS where history is strictly linear have this obsession with keeping it that way. This has absolutely nothing to do with those, especially since they didn't even allow cleaning up histories. There is one very simple reason for why some developers prefer a linear history of master: It makes debugging very easy. With branch merges, especially when the branch lines cross, or the merge i…

Linearized histories are much harder to find bugs in. You end up looking through revisions that never existed; in SVN you merge the remote history into your local history without it ever showing up as a merge. The explicit git approach tells you something much closer to the truth. Your condescension is only hurting yourself.

Your building strawmen does not help your credibility much, nor your attempt to convince me of your view. "Revisions that never existed" do exist, and if you put a rebase of a branch on master without verifying the rebase, then you may end up in a mess, but it's your fault. Code review is a thing that is done for a reason.

Frankly, i find your style of argument through implication, and through trying to disregard something because it doesn't fit your definition of truth to be much more condescending than anything i wrote before.

Re: The State of Go

#67

Post by CHY872 »

Mithaldu wrote: post #41

Edit: This commit was written to the original submission: https://talks.golang.org/2015/state-of-go.slide#7 -------------- It seems like these people simply don't understand Github very well. Can only view diffs on a single page (can be very slow). Cannot compare differences between patch sets. Accepting a patch creates a "merge commit" (ugly repo history). Don't use the merge button, just add the requester's repo as…

Just out of curiosity, have you ever used a tool such as Gerrit or Atlassian Stash? There are different mindsets, and both have their advantages.

Re: The State of Go

#68

Post by Mithaldu »

justinmk wrote: post #65
Mithaldu wrote: post #41

Edit: This commit was written to the original submission: https://talks.golang.org/2015/state-of-go.slide#7 -------------- It seems like these people simply don't understand Github very well. Can only view diffs on a single page (can be very slow). Cannot compare differences between patch sets. Accepting a patch creates a "merge commit" (ugly repo history). Don't use the merge button, just add the requester's repo as…

> Don't use the merge button, just add the requester's repo as a remote to yours Actually, you don't need to do that. GitHub provides a special pulls remote "namespace" on the upstream repo, so you can add it as a fetch pattern to your .git/config like so: [remote "upstream"] url = https://github.com/neovim/neovim.git fetch = +refs/heads/*:refs/remotes/upstream/* fetch = +refs/pull/*/head:refs/pull/upstream/* Then wh…

That is great, and i thank you for bringing that to my, and everyone else's attention! :)

Re: The State of Go

#69

Post by enneff »

arsv wrote: post #44
enneff wrote: post #23

Earlier quoted context omitted.

> "Run-time support and type information", why is it linked into a an executable that never allocates memory and does no introspection of any kind? fmt.Print does use reflection. Besides, bickering over the size of hello world is pretty pointless; better to compare the size of programs that actually do something. We do recognise that Go binaries can and should be smaller, but probably not as small as you might hope.…

> Besides, bickering over the size of hello world is pretty pointless; better to compare the size of programs that actually do something. It is not about the size of hello world executable, that is just a symptom. A code smell if you like. There is something badly broken in the dead code (or dead data) elimination area. And I hope that code is in fact dead, because if it is not, add code generation to the list of sme…

> The bigger one is why do I see about 600 reflect. entries in the resulting ELF instead of a single one for the string type.*

There is definitely work that can be done to improve dead code elimination in the Go tool chain. The transition to Go will make this easier to achieve.

> What I suspect I see here is a kind of C++ vtable problem built deep into the language design somewhere.

Don't suspect. Dig into the problem and make some informed commentary. Idly speculating on HN is just spreading FUD, and benefits no-one.

You should read about Go's implementation of interfaces. It's not the same as C++'s vtable issue. http://research.swtch.com/interfaces

Post reply on HN