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

91–100 of 117 posts

Re: Official Go support

#91

Post by NateDad »

general_failure wrote: post #74
shadowmint wrote: post #64

Earlier quoted context omitted.

I'm not the greatest fan of Go; the pain points of api weirdness and generics are too irritating for me. ...but you've got to admit: look at the graph. That's an exponential increase in people using go to access the service. If you're a service based company you can't just ignore the people who use your service. If people are using go? Provide a go library. If you see an exponential curve of people accessing it using…

The graph has no numbers.

Developers & managers at Stripe decided that Go was being used often enough to spend precious dev time writing an official library which will have to be supported from here on. They wouldn't do that if the numbers didn't justify it.

Re: Official Go support

#92

Post by NateDad »

linguafranca wrote: post #61

I'm a bit baffled by Go. The majority of developers I know (across several camps) strongly oppose Go, often to the point of ridiculing it. But then I see Go support being added to everything, usually by a few key people who strongly prefer it. In fact I hear Heroku is internally adopting Go pretty rapidly. So every time I see an announcement like this, I look up whether Go has added some kind of generics yet. And as…

People often ridicule what they don't understand. People who haven't written real code in Go don't understand why it's good. And what makes it good isn't that it has X feature, so it's hard to explain to people who haven't used it.

Missing generics is not a major problem. Yes, it means you can't write a generic red black tree in the language that doesn't require type-casting. However, for real software solving real problems, you don't often actually need generics. I work on Juju, which is a couple hundred thousand lines of code, consisting of a client and networked servers deployed across an arbitrary number of machines in the cloud. The number of times we might have wanted to use generics in the codebase is approximately 2... and only one of those pieces of code is actually used by more than one type.

Sure, some software really benefits from generics. But most of the time, generics just complicate the code with little to no benefit. Many things people do with generics can be accomplished with interfaces and just writing code that has fewer assumptions about the outside world.

Re: Official Go support

#93

Post by EdiX »

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…

>For example, sometimes you'll get Unicode code points, but sometimes you'll get bytes of UTF-8.

This isn't true, you only get code points when you convert to []rune, I'm not aware of any situation where you would magically get codepoints.

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

This is not true, since 1.3 all function calls can potentially yield. Also it only happened if you had as many goroutines running infinite loops as you had kernel threads.

Re: Official Go support

#94

Post by pjmlp »

NateDad wrote: post #88
pjmlp wrote: post #84

Earlier quoted context omitted.

There are languages for those who can and those who can't...

The problem with "languages for those who can" is that they get relegated to pet projects, because real teams need code that everyone can understand, not just the "rock stars". I actually hope that Rust does not become that kind of a language. I think it has a lot going for it, but I do agree that it's a pretty dense language, and that will cause problems in uptake for real projects.

And the problem with "languages for those who can't" is the rise in off-shoring and erosion of working conditions for everyone involved, in both sides.

Not targeting any specific language, as I imagine all of us that went through this, have own hard earned war scars.

Re: Official Go support

#95

Post by NateDad »

pjmlp wrote: post #94
NateDad wrote: post #88

Earlier quoted context omitted.

The problem with "languages for those who can" is that they get relegated to pet projects, because real teams need code that everyone can understand, not just the "rock stars". I actually hope that Rust does not become that kind of a language. I think it has a lot going for it, but I do agree that it's a pretty dense language, and that will cause problems in uptake for real projects.

And the problem with "languages for those who can't" is the rise in off-shoring and erosion of working conditions for everyone involved, in both sides. Not targeting any specific language, as I imagine all of us that went through this, have own hard earned war scars.

Suggesting that offshoring is a result of languages that are "too easy" is both insulting to those who work offshore, and totally inaccurate.

There's plenty of off-shore C++ programmers, and I doubt anyone would say that's an easy language.

And yes, offshored work is almost always of poor quality, but I actually think this is due to the inherent problem with paying people to write a product that they are not fully invested in. The same thing happens with contract work done in your own country. If the developers don't work for your company, they don't have your culture and they don't know your business. This is compounded by the communication inefficiencies from being outside your trusted mediums.

I have seen pay-for-code (contracting, offshore or not) fail many times. The only times I have seen it succeed is when the contractors are hired to work for the company directly, are taken inside its boundaries, and given full access to the company communication facilities and culture. But then, they may as well be regular employees.

None of this has anything to do with the language being used. As they say, you can write bad code in any language, and even the best code doesn't help if it's not doing the right thing.

Re: Official Go support

#96

Post by skj »

EdiX wrote: post #93
methodology wrote: post #39

Earlier quoted context omitted.

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…

>For example, sometimes you'll get Unicode code points, but sometimes you'll get bytes of UTF-8. This isn't true, you only get code points when you convert to []rune, I'm not aware of any situation where you would magically get codepoints. >If any thread runs in an infinite loop that doesn't call built in functions, the entire runtime will freeze. This is not true, since 1.3 all function calls can potentially yield.…

If you range on a string, you get runes.

http://play.golang.org/p/CqLnT4m4GI

Re: Official Go support

#97

Post by pjmlp »

abritishguy wrote: post #83
p0nce wrote: post #79

Earlier quoted context omitted.

Go is a slower C[1] with worse syntax and oversold ideas. Stockholm syndrom is a builtin feature that comes with it and not much else. It doesn't provide basic stuff like generics, warnings, or exceptions because the authors want to make a bold statement about how they are in the Right and their potential users are wrong. Meanwhile system software will continues to be built in C and C++ since Go addressed some real p…

your entire comment is crap but the following bit definitely is: >Go isn't very successful at Google Go is used heavily for networking and server stuff at Google. The entirety of dl.google.com runs on go (ported from C).

There are currently three public projects.

- dl.google.com

- vitess

- Google App Engine, that used to be maintained by someone on the Go team not the Google App Engine team, if the Google IO information is still valid.

Chrome is focusing on Dart support and Android team was very explicit at Google IO about Java being what really matters.

So any other very successful Go projects at Google that can be shared?

EDIT: For those that bothered to provide answers. Thanks.

Re: Official Go support

#98

Post by fedesilva »

NateDad wrote: post #88
pjmlp wrote: post #84

Earlier quoted context omitted.

There are languages for those who can and those who can't...

The problem with "languages for those who can" is that they get relegated to pet projects, because real teams need code that everyone can understand, not just the "rock stars". I actually hope that Rust does not become that kind of a language. I think it has a lot going for it, but I do agree that it's a pretty dense language, and that will cause problems in uptake for real projects.

In my experience most people won't even learn the ins and outs of the "for those who can't" languages. Worst yet, it's not about the language: most people won't grasp more important concepts that maybe "for those who can" languages force them to know upfront. And clearly while not knowing upfront some things is easier in the short term, it is a recipe for disaster as problems get more complex. So maybe it's about problems "for those who can" and "for those who can't".

Re: Official Go support

#99

Post by swah »

bad_user wrote: post #73
methodology wrote: post #39

Earlier quoted context omitted.

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…

> It doesn't have a GIL On platforms like Go and the JVM, the garbage collector acts like a GIL, which is why they'll never replace C/C++.

That's a good insight. Thanks!

Re: Official Go support

#100

Post by pivo »

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.

Fixing this stupid issue seems like such an obvious thing to do I can't imagine why it wasn't addressed ages ago. Having property notation would immediately get rid of 30% of the code in the codebase I currently work with, and that seems incredibly valuable.
Post reply on HN