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

221–230 of 271 posts

Re: The State of Go

#221

Post by tracker1 »

kasey_junk wrote: post #159
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…

People use mmapped files all the time in performance critical Java. Typically using the unsafe packages. In fact, if you want to communicate with C/assembler level things, this is the way people who do fast Java do it because JNI is very slow. If you want to use an abstraction around ByteBuffers that feels like value types take a look at the javalution structs. As a counter to your argument, C# has had value types fo…

I don't think C# vs Java performance can always be directly compared.. C#'s SuppressUnmanagedCodeSecurity attribute for PInvoke interfaces, when you can use it, reduces C#'s call overhead to something like 20% over using a Managed C++ library as a bridge. If you don't need to pass complex numbers (doubles) it isn't bad at all. Just depends on your needs.

Then again, depending on your needs, being able to scale out or up is far more important than raw performance characteristics... just depends on your needs.

Re: The State of Go

#222

Post by kasey_junk »

lomnakkus wrote: post #170
kasey_junk wrote: post #63

Earlier quoted context omitted.

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.

I'm not sure I understand. Vetting a changeset is basically the same thing as verifying the repo. Just look at the hash of repo A (your clone), check that it matches B (upstream), check that your repo A + "patch" matches pull request. What am I missing?

Branches and the ref log.

Re: The State of Go

#223

Post by ldng »

nkurz wrote: post #175
Mithaldu wrote: post #59

Earlier quoted context omitted.

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

I also am scared off by the public aspect, and find it a very awkward requirement. If there was an option to create a private branch on Github, I'd probably use it often. I'd love if there was an easy way to submit a quick patch using only the Github interface. As it is, I've clicked once in my life on the fork button, realized that it created something visible to the outside world, and have never used it again. Inst…

So, if I understand correctly, it's the user oriented approach of Github that put you off ? Gitorious is project oriented, does that suits you more ?

Re: The State of Go

#224

Post by kasey_junk »

rdtsc wrote: post #204
lomnakkus wrote: post #171

Earlier quoted context omitted.

Git != github. (Does this really need to be said?)

Saddly it does. There is probably a significant number of developers who never used git without Github. As a funny aside, when Github breaks the thing to say is "I wish one day someone would invent a decentralized version control system" ;-)

For many developers the only reason we use git is github. I for one much prefer mercurial but to collaborate with others (and now for my job) github is a de facto standard.

Re: The State of Go

#225

Post by rsarsarsa »

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.

Re: The State of Go

#226

Post by kasey_junk »

tracker1 wrote: post #221
kasey_junk wrote: post #159

Earlier quoted context omitted.

People use mmapped files all the time in performance critical Java. Typically using the unsafe packages. In fact, if you want to communicate with C/assembler level things, this is the way people who do fast Java do it because JNI is very slow. If you want to use an abstraction around ByteBuffers that feels like value types take a look at the javalution structs. As a counter to your argument, C# has had value types fo…

I don't think C# vs Java performance can always be directly compared.. C#'s SuppressUnmanagedCodeSecurity attribute for PInvoke interfaces, when you can use it, reduces C#'s call overhead to something like 20% over using a Managed C++ library as a bridge. If you don't need to pass complex numbers (doubles) it isn't bad at all. Just depends on your needs. Then again, depending on your needs, being able to scale out or…

That is exactly my point. Value types vs lack of value types is largely immaterial to the performance story.

Re: The State of Go

#227

Post by rsarsarsa »

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.

Just downvote if that make you feel good because your poor head can't prove go is better anywhere :P

Re: The State of Go

#228

Post by 4ad »

slyall wrote: post #120
georgemcbay wrote: post #19

Earlier quoted context omitted.

Yeah, what an outrage this is. 1.3 megabytes. That's like $0.00004 USD worth of hard drive space. Does the go team think we are all rich or something?

Plenty of CPUs out there with cache sizes smaller than that, or other things running on the machine that would also like to use the cache.

The size of the binary is completely irrelevant when considering if the code fits in the CPU cache. What's important is the size of code that actually executes. Go binaries have huge DWARF tables, and a lot of the code is dead code.

The code that actually executes is not bloated. It's not the most efficient code in the world, because the compilers don't have an optimizer as advanced as gcc's, but it's not unreasonably large.

Re: The State of Go

#229

Post by farresito »

Mithaldu wrote: post #166
enneff wrote: post #125

Earlier quoted context omitted.

Half your post is saying we should just use different tools, but we are. We're using Gerrit, that lets us work the way we want. On the contributor instructions: note that if you just want to use plain git (and not our git-codereview tool) then you can stop at "Register with Gerrit." We created the tool to provide a more familiar review process for the people that used our previous system. If we took your advice and u…

Thanks for the direct answer. I think my stance wasn't clear enough, so i'll reword what i wrote in another comment here. My issues are two-fold: You could have just said on that slide: "We want a central code review system, so people do not have to learn Git. Github isn't terrible, but Gerrit is much better." Instead you ended up putting up a list of points that make github seem like some kind of fatally flawed thin…

If they need to learn something new, they will. It's part of being a programmer. For me, github's way of doing things is way more flawed that gerrit.

Re: The State of Go

#230

Post by insertnickname »

skybrian wrote: post #160
noir_lord wrote: post #46

Earlier quoted context omitted.

I was generating 7-15Mb binaries out of Delphi in the late 90's (it had a similar kitchen sink approach) and it simply wasn't an issue then and it certainly isn't an issue now. I'm actually racking my brain for a case where a 500kb vs 5Mb binary would be a deal breaker, outside of embedded stuff I can't think of much.

It matters when you have to download the file over a slow network. "The ideal size is 10-15MB globally. Idea size for an app for tier 2/3 countries (like India) is below 5MB. 500MB+ is a non-starter. At 50MB+ the conversion rates fall off dramatically." http://time.com/3589909/internet-next-billion-mobile/

Go binaries compress well in my experience. For example, I have a Go program that compiles to an 8.2 MB binary when compiled with gc 1.4.1. With bz2 compression, which takes about half a second on my box, it can be shrunk down to 2 MB.
Post reply on HN