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

231–240 of 271 posts

Re: The State of Go

#231

Post by config_yml »

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…

is this documented somewhere on github?

Re: The State of Go

#232

Post by Skinney »

rsarsarsa wrote: post #225

I think go is failed, compare to rust. 1. not memory safe on multi-thread 2. no generic support 3. error handle is full of pain compare to rust's Result , Option and try! 4. gc can't be disable 5. no RAII support, defer can be forgot light-weight thread (spawn) and channel (thread safe FIFO) already exist in rust that make golang more meanless. If you think still any advantage of go please tell me.

Go is stable, wheras Rust is not. Go also targets other use cases than Rust, and so the two are not directly comparable. 1. Rust cannot guarantee multi-threaded memory safety in all cases. Care, as in Go, must still be taken. 2. I agree with you here, I think Go would be better with generics. But apparently, most people don't have a problem with this. 3. Rust and Go's error handling is based on the same principle: force the user to deal with errors, instead of ignoring them. While Go's way of handling things can be a little more verbose, in principle I don't see the big difference. 4. Alot of people will argue that this is a good thing. Using a GC by default makes certain things easier, like writing datastructures (especially immutable ones) without reaching for 'unsafe' code. Having a GC also means you don't have to mind memory fragmentation, as you do with a manually malloc/free based allocation. 5. RAII is great, but loses some of it's use in GC based language. Defer is, IMHO, a much better option than the other solutions I've seen in other GC languages (Javas try-with-resources and C#s using)

Just because you can do the same thing in language X, doesn't make language Y obsolete.

Advantage of Go, for me, is less verbose code (implicit interfaces for the win) and a fantastic, stable and huge standard library. I also like the strict compiler, and that the language has a GC by default, makes certain things easier, and for most tasks I don't need the predictability that you get with manual memory management.

Re: The State of Go

#233

Post by pgeorgi »

hueving wrote: post #55
enneff wrote: post #51

Earlier quoted context omitted.

That's exactly what we do, and we need to change the commit hash because we want to include the review information in the commit message. Not sure why this is "insane."

It's essentially rewriting history. As a contributor it's nice to know a commit went in exactly as you wrote it, which is not the case when the commit hash changes. Git is powerful because it was written with the ability to merge trees. The cherry pick workflow is throwing all of that in the trash. Why not use SVN at that point? Because of cherry picking in Gerrit, dependent patches are a nightmare to maintain. Say p…

The "don't rewrite history" train has left a _long_ time ago, when mercurial and monotone were still relevant.

Re: The State of Go

#234

Post by bovermyer »

rsarsarsa wrote: post #225

I think go is failed, compare to rust. 1. not memory safe on multi-thread 2. no generic support 3. error handle is full of pain compare to rust's Result , Option and try! 4. gc can't be disable 5. no RAII support, defer can be forgot light-weight thread (spawn) and channel (thread safe FIFO) already exist in rust that make golang more meanless. If you think still any advantage of go please tell me.

You are, of course, entitled to your opinion. But "go is failed" is a little strong, don't you think? Wouldn't it be more accurate, and less ornery, to say that you personally don't like Go?

For my part, I like Go because it offers a great, if nascent, alternative to PHP. That's the gist of it, anyway.

Re: The State of Go

#235

Post by WorldWideWayne »

enneff wrote: post #214
krenoten wrote: post #153

Earlier quoted context omitted.

Google is a huge place. I don't pretend to know what everybody, most people, or even a sizeable fraction of people there think. But a significant majority of the people I have spoken with strongly disagree with the choice not to invest more in the type system. Take it with salt, but that is the noise I hear from my position on the outside. It may not match your experience, but it isn't nonsense. Just another datapoin…

When first you say > Most Googlers I've spoken to despise this guy's reactionary lordship over the project and then water it down to > a significant majority of the people I have spoken with strongly disagree with the choice not to invest more in the type system. then it seems like you're editorialising. Bear in mind that you're talking about real people and real relationships. Fanning the flames of hatred is unneces…

Did anyone expect all commenters to be hard-facts-only journalists here? I come here for the rumors.

And this is the 3rd time in a few months that I've heard that Googlers generally don't like Go and don't use it. So, that's kind of interesting.

Anyway, I don't think you can call an activity sociopathic if the vast majority of humans take part in it. (Having opinions and spreading rumors didn't start with the Internet either.)

Re: The State of Go

#236

Post by Gankro »

cbr wrote: post #145
bdarnell wrote: post #90

Earlier quoted context omitted.

>> Comments are sent as they are written; you cannot "draft" comments. > How is that different from pull requests via emails? (Also, on the website itself the comments can be edited.) With github PRs, notifications are sent as soon as you write your first comment; in systems like gerrit and rietveld (and email) they are not sent until the reviewer chooses to send them. This leads to either awkward interactions if you…

My favorite are the comments like: 1:12pm line 33: Why are you doing this? 1:13pm line 33: I see, sorry, ignore my earlier comment. A system that lets you draft comments and then send them out in a batch can avoid a bunch of noise. On the other hand, though, people who aren't expecting it can get stuck with draft comments they don't send out.

Usually if this happens, it's a good hint that this piece of code could use a good comment. Not always, of course.

Re: The State of Go

#237

Post by jaimeyap »

piotrkaminski wrote: post #203
jaimeyap wrote: post #202

Earlier quoted context omitted.

@piotrkaminski Comment nesting seemed to run out. So replying to myself. Our team is currently using Rietveld. But I've used Gerrit in the past, as well as internal tools of the same flavor back when I was at Google. I don't particularly love Rietveld. But it's simple to maintain and does the job. That being said, I'm genuinely looking forward to one day being able to just use Github for this.

Heh, that's almost exactly like me: used internal tools at Google, brought up a Rietveld instance after I left. Except that I got frustrated with Rietveld and built https://reviewable.io -- you might want to check it out. :) FullStory looks awesome, BTW, I just wish I could afford it.

Shoot me an email and let's see what we can do.

Also, I'll definitely have to check out Reviewable!

Re: The State of Go

#238

Post by krenoten »

enneff wrote: post #214
krenoten wrote: post #153

Earlier quoted context omitted.

Google is a huge place. I don't pretend to know what everybody, most people, or even a sizeable fraction of people there think. But a significant majority of the people I have spoken with strongly disagree with the choice not to invest more in the type system. Take it with salt, but that is the noise I hear from my position on the outside. It may not match your experience, but it isn't nonsense. Just another datapoin…

When first you say > Most Googlers I've spoken to despise this guy's reactionary lordship over the project and then water it down to > a significant majority of the people I have spoken with strongly disagree with the choice not to invest more in the type system. then it seems like you're editorialising. Bear in mind that you're talking about real people and real relationships. Fanning the flames of hatred is unneces…

Editorialization is a trivial truth of human expression. Real people really hate decisions that significantly increase the amount of work that it takes them to express complexity. This particular influencer of the project happens to have been blamed fairly harshly by internal users for doing so. As someone who is partially responsible for the progress of this tool, it's probably a good idea to try to improve user's productivity rather than claim that it's nonsense for people to have strong opinions against its decisions.

Re: The State of Go

#239

Post by eropple »

crawshaw wrote: post #140
eropple wrote: post #96

Earlier quoted context omitted.

I don't believe that this is true. You use the exact same patterns and tricks in both for perf-critical code: off-GC primitives and object pools rule the day. What are you considering a "much better" option available in Go? (I considered stack-allocated structs in Go, but honestly that doesn't strike me as a particularly major thing; it may be slightly more terse, but fundamentally the same behavior.)

Go gives you data structures with fewer pointers than Java, which helps cut down on GC pressure. type point struct { x int16 y int16 } points := make([]point, 1e6) The value points uses 4 MB of memory and contains one pointer, not a million.

Sure. Now do this in Java (I have no idea why I'm getting downvoted for this thread because I think this stuff is fairly straightforward and nobody's actually making an argument to the contrary, but whatever):

  short[] x = new short[1000000];
  short[] y = new short[1000000];
4MB of shorts. Now you can use the argument of locality of reference, to be sure--but you're already throwing out the window by keeping around a million items.

This is why I'm saying that in the what I would call most perf-critical cases, value type structs are a convenience much more than a tool to realize significant benefits. They are nice-to-haves. They don't make your code magicfast.

Re: The State of Go

#240

Post by geodel »

sanxiyn wrote: post #165
justinsb wrote: post #54

Earlier quoted context omitted.

If you're mmaping a file and processing the majority of it, you really are typically doing that in C today if you care about performance. You can get acceptable performance in Java with ByteBuffers, but because of the lack of value types it doesn't feel like Java any more. Go should be able to get much closer to C's performance, while still being closer to idiomatic Go code. And Go can plug in small pieces of C code…

JNI is un-fun, so JVM developers are working on the solution. I think Panama will arrive sooner than Go making any inroads. http://openjdk.java.net/projects/panama/

Good thing. Though Go made inroads in all kids of Web / Cloud infrastructure considering Java should be the first(only?) choice with production grade application servers etc already present. I think Panama shows Java was late to realize that native code easy access is getting more important for Java even with better hardware.

Where I work ~16GB Java heap makes gc pauses huge and unpredictable. I think Java performance is great in benchmarks but the way code is written in most enterprises Java is hugely memory hungry and slow.

IMO Java position remains secure till management is on Java side. Technical merits limit to evaluating different Java technologies not Java vs Non Java technologies.

Post reply on HN