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

Official Go support

stripe.com

Post reply on HN
Print view View original

51–60 of 117 posts

Re: Official Go support

#51

Post by Uhhrrr »

Swizec wrote: post #48
DigitalJack wrote: post #42

Earlier quoted context omitted.

Red/blue would be safer colors to differentiate for many colorblind people. Red/green colorblindness is so common it baffles me that comparisons using red/green are still so prevalent. Especially considering how heavily biased the tech population is toward men. And as Sanddancer points out, any colors that make use of red/green are going to be problems as well. (hence blue/purple being an issue as the difference is t…

> In a given group of 5 men, you have a 50% chance that 1 is red/green color deficient. Soooo, 1 in 10 men are red/green colour deficient?

I will let others dissect the different probabilities for at least 1 and for only 1 and say, yes! Nearly one in ten: http://www.colour-blindness.com/general/prevalence/

It usually doesn't come up in conversation. Even when I was working on an image processing toolkit, it was several months before I realized my boss was red-green colorblind.

Re: Official Go support

#52

Post by schrodinger »

schrodinger wrote: post #50
Swizec wrote: post #48

Earlier quoted context omitted.

> In a given group of 5 men, you have a 50% chance that 1 is red/green color deficient. Soooo, 1 in 10 men are red/green colour deficient?

I believe that implies 1 in 8 people are. Pc = Probability that someone is colorblind (1 - Pc) = Probability they aren't colorblind (1 - Pc)^5 = Probability that no one in group of 5 is colorblind 1 - (1 - Pc)^5 = Probability that someone in group of 5 is colorblind Solve .5 = 1 - (1 - Pc^5): http://www.wolframalpha.com/input/?i=.5+%3D+1+-+%281+-+p%29%... You get .129449, which is approximately 1 in 8

Although wikipedia shows 7% of males, meaning a group of 5 would have a 30% chance of one of them being colorblind.

Re: Official Go support

#53

Post by pjmlp »

skybrian wrote: post #46
higherpurpose wrote: post #37

Earlier quoted context omitted.

When Google will completely deprecate Java for Go on Android (could be a number of years, if ever), then Java should imminently become irrelevant (over a number of years, maybe a decade, or maybe it will never disappear completely, but the point is it will rapidly decline with new and existing developers).

I don't see any reason why Java usage would rapidly decline. The only thing that's likely to replace Java is Java 8, since everyone wants lambdas and there's a clear upgrade path. Even that's a big change and migration will take a while on Android. It's unclear what the big missing feature is after lambdas. I think there will be little incentive for further change, so large companies will keep on running it.

> It's unclear what the big missing feature is after lambdas.

- Value types, GPGPU, replacing JNI with an improved JNR, reified generics, making Unsafe an official package, modularity, AOT compilation, replacing Hotspot by Graal...

Some things discussed here,

http://www.oracle.com/technetwork/java/javase/community/jlss...

http://openjdk.java.net/projects/panama/

http://openjdk.java.net/projects/sumatra/

http://openjdk.java.net/projects/valhalla/

https://wiki.openjdk.java.net/display/Graal/Publications+and...

Re: Official Go support

#54

Post by MereInterest »

AnimalMuppet wrote: post #47
skybrian wrote: post #46

Earlier quoted context omitted.

I don't see any reason why Java usage would rapidly decline. The only thing that's likely to replace Java is Java 8, since everyone wants lambdas and there's a clear upgrade path. Even that's a big change and migration will take a while on Android. It's unclear what the big missing feature is after lambdas. I think there will be little incentive for further change, so large companies will keep on running it.

> It's unclear what the big missing feature is after lambdas. I agree. I think Java pretty much is what it is by now. As someone said, "For those who like this kind of thing, this is the kind of thing they like." Java-the-language is pretty complete. (Even though Haskell people complain about the lack of a decent type system, and Lisp users complain about the verbose syntax, and C++ folks wish they had destructors.)…

In terms of language features, lack of properties are the thing that is keeping me from using java. I would love to be able to have public variables, with the understanding that I could just convert them to properties later on if I need to. Instead, java conventions suggest that I always make a getter and setter for every single variable that I want to expose.

Re: Official Go support

#55

Post by skybrian »

pjmlp wrote: post #53
skybrian wrote: post #46

Earlier quoted context omitted.

I don't see any reason why Java usage would rapidly decline. The only thing that's likely to replace Java is Java 8, since everyone wants lambdas and there's a clear upgrade path. Even that's a big change and migration will take a while on Android. It's unclear what the big missing feature is after lambdas. I think there will be little incentive for further change, so large companies will keep on running it.

> It's unclear what the big missing feature is after lambdas. - Value types, GPGPU, replacing JNI with an improved JNR, reified generics, making Unsafe an official package, modularity, AOT compilation, replacing Hotspot by Graal... Some things discussed here, http://www.oracle.com/technetwork/java/javase/community/jlss... http://openjdk.java.net/projects/panama/ http://openjdk.java.net/projects/sumatra/ http://openjd…

Yes, there are many more features to come, but they don't look like they will be as important as lambdas (and default methods) for everyday coding.

Thanks for the links.

Re: Official Go support

#56

Post by darren2000 »

cnbuff410 wrote: post #2

It's both interesting and suprising that how steady this exponential growth curve is. The increasing speed of Go usage on stripe doesn't slow down as time goes by. Of course without knowing the base we don't know how big usage it actually is, also we don't know if it's counting one-per-client or one-per-request. Still nice to see that nonetheless.

Right, just look at August! Although I wish there were numbers on that graph. Was there a conference talk? Glad to know there'll be lots of fellow devs using it anyway.

Re: Official Go support

#57

Post by enneff »

methodology wrote: post #39
fizixer wrote: post #11

Can someone explain? I'm a big fan of C and python and I've never used Go. My initial impressions from readings were that Go is a better C. But then I came across a Go person who was lamenting that misunderstanding and that Go is python but with better performance. What's it all about? Also even if we compare it to C I don't like the garbage-collection thing at system level. Also what does Go let you do in terms of g…

Go's syntax and semantics seem ad-hoc, hard to remember, and inconsistent, but that's because Go was designed from uses cases and experience by prominent thought leaders such as Rob Pike and Ken Thompson, and Google. For example, sometimes you'll get Unicode code points, but sometimes you'll get bytes of UTF-8. The language was designed to give you the right one in the right case. UTF-8 is coupled with the language b…

> If any thread runs in an infinite loop that doesn't call built in functions, the entire runtime will freeze.

That's not entirely true. Go 1.3 introduced pre-emptive scheduling, so now only the most trivial (useless) of infinite loops will hog the scheduler. But if you're doing real CPU-bound work you won't block other goroutines from executing.

Re: Official Go support

#58

Post by skybrian »

MereInterest wrote: post #54
AnimalMuppet wrote: post #47

Earlier quoted context omitted.

> It's unclear what the big missing feature is after lambdas. I agree. I think Java pretty much is what it is by now. As someone said, "For those who like this kind of thing, this is the kind of thing they like." Java-the-language is pretty complete. (Even though Haskell people complain about the lack of a decent type system, and Lisp users complain about the verbose syntax, and C++ folks wish they had destructors.)…

In terms of language features, lack of properties are the thing that is keeping me from using java. I would love to be able to have public variables, with the understanding that I could just convert them to properties later on if I need to. Instead, java conventions suggest that I always make a getter and setter for every single variable that I want to expose.

Some Java conventions are unfortunate. Setters aren't a great idea, actually. The Guava team recently open-sourced AutoValue as a more modern approach:

https://github.com/google/auto/tree/master/value

Re: Official Go support

#59

Post by MetaCosm »

kyrra wrote: post #30
NateDad wrote: post #24

Earlier quoted context omitted.

Go is a very pleasant language to develop software products in. Unlike the dynamically typed languages, it doesn't trade speed for beauty of syntax. This means that sometimes syntax can be a little non-uniform, but there's always a reason. Unlike C and C++, it doesn't trade safety for speed of execution. There are no buffer overflow vulnerabilities in Go applications. It treads a fine line of where to let the languag…

The toolchain part of Go is very interesting (I only know the basics). Go doesn't use GCC, LLVM or other existing compilers. Go's compiler/linker originated from the Plan9 C compiler (that Rob and Ken worked on)[0]. Because of this, it allows you to create binaries for any target platform from any platform you have the Go toolchain on. So from my OSX macbook, I can compile Windows and Linux executables. When you star…

Yeah, a lot of magic lives at the tooling layer, and Go is going to leverage that with Go Generate in Go 1.4+. A lot of great tools already leverage that core.

I like that fact that a lot of the tooling/editor support is not picking a winner nor demanding an IDE. Tools like errcheck, goimports, gorename (announced today), oracle, gocode, godef, godoc, gofmt, golint, gotags, ... (on and on) ... all can be leverage by IDEs, emacs, sublime, vim and others equally... or just used from a console or in your own stacks.

Re: Official Go support

#60

Post by pkulak »

Sanddancer wrote: post #36
gonehome wrote: post #35

Earlier quoted context omitted.

Interesting - I thought it'd be red/green, but it's blue/purple (which I thought were colors chosen for the color blind). Is blue/purple color blind less common? Can you differentiate between red/green?

If you're red-deficient, then purple/blue is also a bad choice for colors because you can't see the red components of purple.

Blue and purple are the same color as far as I can tell.
Post reply on HN