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

71–80 of 117 posts

Re: Official Go support

#71

Post by bad_user »

higherpurpose wrote: post #37
loudmax wrote: post #21

Earlier quoted context omitted.

Go was originally pitched as a better C, but it seems to be finding a niche as a better Python or possibly a better Java. Go binaries have built-in GC, and Go will probably never reach C levels of performance. There is a lot to like about Go and it is working out very well for a lot of people, but it isn't appropriate for every situation. If you want a better C, better to look into Rust: http://www.rust-lang.org/

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 really hope Google deprecates Java on Android, because Android is even having problems with the standard library in Java SE 6, let alone Java 7 or 8. I rooted for them in the Oracle lawsuit, but they are holding back progress on the Java platform, as now library authors have to worry about the "Android problem" - every other JVM vendor is able to keep up the pace of updates, but not Google, because hey, ART / Dalvik is not a JVM, haven't you heard? So they should either get their shit together and keep up with the latest standard library, class format and bytecode in their toolchain or drop it.

Re: Official Go support

#72

Post by bad_user »

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…

For me, touting a language as being "Python, but with X" is a big turnoff.

I worked for about 2 years in Python and hated most things about it - from the whitespace sensitive indentation that led people to write really long lines and the limited expressive capabilities forcing people to do meta voodoo in their libraries leading to incomprehensible DSLs, to the legacy that sticks like "old-style vs new-style classes", to the performance problems and the sad state of libraries in the ecosystem, let alone the complete cluster-fuck that is dependency and deployment management on top of Python.

So you know, I want to hear about languages that are not like Python.

Re: Official Go support

#73

Post by bad_user »

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…

> 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++.

Re: Official Go support

#74

Post by general_failure »

shadowmint wrote: post #64
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…

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.

Re: Official Go support

#75

Post by jesstaa »

ominous_prime wrote: post #45
methodology wrote: post #40

Earlier quoted context omitted.

> There are no buffer overflow vulnerabilities in Go applications Actually there are in certain cases [1], but there's a good reason for that. 1. http://stackoverflow.com/questions/25628920/slicing-operatio...

But that's not a buffer overflow. You can't access uninitialized memory (well, without unsafe anyway).

Without unsafe or a race condition. http://research.swtch.com/gorace

Re: Official Go support

#76

Post by jesstaa »

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++.

Most concurrent C programs of a reasonable size eventually have some kind of big global lock. The linux kernel had one for a long time and it took a lot of effort to add more fine grained locking. Similarly most large C programs have a garbage collector of some kind.

Re: Official Go support

#77

Post by BinaryHole »

loudmax wrote: post #21
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 was originally pitched as a better C, but it seems to be finding a niche as a better Python or possibly a better Java. Go binaries have built-in GC, and Go will probably never reach C levels of performance. There is a lot to like about Go and it is working out very well for a lot of people, but it isn't appropriate for every situation. If you want a better C, better to look into Rust: http://www.rust-lang.org/

Rust???The language which is more complicated than C++??? I have learned Rust almostly, but it is too enormous to replaced the C/C++. If rust can't simplify its concepts and syntax, this language will turn to failure again like D...

Re: Official Go support

#78

Post by dbaupp »

BinaryHole wrote: post #77
loudmax wrote: post #21

Earlier quoted context omitted.

Go was originally pitched as a better C, but it seems to be finding a niche as a better Python or possibly a better Java. Go binaries have built-in GC, and Go will probably never reach C levels of performance. There is a lot to like about Go and it is working out very well for a lot of people, but it isn't appropriate for every situation. If you want a better C, better to look into Rust: http://www.rust-lang.org/

Rust???The language which is more complicated than C++??? I have learned Rust almostly, but it is too enormous to replaced the C/C++. If rust can't simplify its concepts and syntax, this language will turn to failure again like D...

Rust is not more complicated than C++; you actually have to be thinking about the concepts (ownership and lifetimes) in C++ too, there's just no compiler help, so it seems like you don't.

(Well, you get some help: the compiler inserts (arbitrarily expensive) copies of your data for you.)

Re: Official Go support

#79

Post by p0nce »

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 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 problems with system programming but created new ones.

Go was explicitely created for the average programmer like is said in videos talks. It is a dumbed down language to address the maintenance problem through tools instead of through better craftmanship. Go isn't very successful at Google but in startups who could do technically anything and still have the same outcome.

As always with the HN hype: Do. Not. Listen.

[1]: http://benchmarksgame.alioth.debian.org/u64q/go.php

Re: Official Go support

#80

Post by pjc50 »

jesstaa wrote: post #76
bad_user wrote: post #73

Earlier quoted context omitted.

> 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++.

Most concurrent C programs of a reasonable size eventually have some kind of big global lock. The linux kernel had one for a long time and it took a lot of effort to add more fine grained locking. Similarly most large C programs have a garbage collector of some kind.

most large C programs have a garbage collector of some kind

[citation needed] - the vast majority of Linux software is C or C++ and I can't immediately think of any with GC. It's not normally assumed, everyone does explicit deallocation, possibly ending up writing their own slab or pool allocators.

Post reply on HN