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

The Reliability of Go

andrewwdeane.blogspot.com

Post reply on HN
Print view View original

101–110 of 144 posts

Re: The Reliability of Go

#101

Post by beatgammit »

kamaal wrote: post #96
waterside81 wrote: post #72

We moved a huge chunk of our code from Python to Go. We have one simple Go binary that just listens on a certain port and API requests from our Django app are proxied to the Go instance running. No issues, no panics, no memory leaks. It's pretty amazing to see a long running process never growing in memory (well, if you're coming from the Python world at least, I'm sure the JVM is pretty solid at keeping it's place n…

How good is Go, as a replacement for Java?

What do you mean "replacement for Java"? It's a completely different language:

* no classes (only structs and embedding)

* no VM, only a run-time (cross-compiling is trivial though)

* hardly anything is an object

* no exceptions

* concurrent by design

It's quite possibly the most distant language from Java in the procedural world, which I think is a good thing. It forces you to rethink your data and their interactions.

I think Go is a great language and works in most of the spaces where Java lives, except maybe GUIs, but Java was never any good at that anyway. It's more suited for the server, but it can work well for computationally-intensive tasks as well.

Go is better thought of as a replacement for whatever server stack you have than a replacement for a given language.

Re: The Reliability of Go

#102

Post by swah »

beatgammit wrote: post #101
kamaal wrote: post #96

Earlier quoted context omitted.

How good is Go, as a replacement for Java?

What do you mean "replacement for Java"? It's a completely different language: * no classes (only structs and embedding) * no VM, only a run-time (cross-compiling is trivial though) * hardly anything is an object * no exceptions * concurrent by design It's quite possibly the most distant language from Java in the procedural world, which I think is a good thing. It forces you to rethink your data and their interaction…

But the runtime performance is probably closer to Java than Python...

Re: The Reliability of Go

#103

Post by jmhain »

why-el wrote: post #32
shocks wrote: post #26

Earlier quoted context omitted.

Use the keyword 'golang' instead. :)

This could have been a better name in my opinion. One should stay away from frequently used English words.

Maybe they wanted the name to symbolize the syntactical terseness of the language, and every other two letter name had already been taken by unix utilities.

Re: The Reliability of Go

#104

Post by zobzu »

rbehrends wrote: post #74
16s wrote: post #39

I'm sorry, but the world does not need another company-controlled, corporate programming language. .Net (Microsoft), Java (Oracle) and now Go (google). All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards). It bothers me to no end to see corporations taking control of the fundamental building blocks (programming languages) of technology and then to see te…

> With C and C++ and Python and Ruby and Perl we have freedom. With Go, .Net and Java, etc. we do not. Unfortunately, there is an important language design space that is not covered by C, C++, Python, Ruby, and Perl, which is that of statically typed, imperative languages with automatic memory management. C/C++ give you static typing, but not automatic memory management; Python, Ruby, and Perl give you automatic memo…

sounds like rust

Re: The Reliability of Go

#105

Post by beatgammit »

kenkam wrote: post #11
elithrar wrote: post #8

Earlier quoted context omitted.

> He implemented it in Go, but he could have implemented it in any other language I assume he used Go's concurrency features, although he could have articulated on that. > Where did he find the programmers I don't think you explicitly need to hire new programmers. If you have capable, existing programmers, the learning curve is pretty minimal for something like Go.

I agree with not needing to hire new devs, but convincing management and the business to move to a new, untried system with current devs is no trivial feat. It would be nice if he could expand on how that came about.

I got my boss to let me try out Go after proving that I could solve problems that we were currently struggling with.

I also agree that you don't need to hire new devs. I've taken two programmers who've never used Go (mostly university languages) and taught them to be productive in a matter of days. Both consider Go to be one of their favorite languages.

Re: The Reliability of Go

#106

Post by 0xdeadbeefbabe »

kamaal wrote: post #96
waterside81 wrote: post #72

We moved a huge chunk of our code from Python to Go. We have one simple Go binary that just listens on a certain port and API requests from our Django app are proxied to the Go instance running. No issues, no panics, no memory leaks. It's pretty amazing to see a long running process never growing in memory (well, if you're coming from the Python world at least, I'm sure the JVM is pretty solid at keeping it's place n…

How good is Go, as a replacement for Java?

The real downside of go is that it didn't exist when Java arrived. It would have made a much better intro to CS language than Java. Then Android wouldn't have decided to use Java because so many new programmers used it in school.

Re: The Reliability of Go

#107

Post by beatgammit »

swah wrote: post #102
beatgammit wrote: post #101

Earlier quoted context omitted.

What do you mean "replacement for Java"? It's a completely different language: * no classes (only structs and embedding) * no VM, only a run-time (cross-compiling is trivial though) * hardly anything is an object * no exceptions * concurrent by design It's quite possibly the most distant language from Java in the procedural world, which I think is a good thing. It forces you to rethink your data and their interaction…

But the runtime performance is probably closer to Java than Python...

Well, yeah, because Go is compiled, not interpreted. It's GC isn't as optimized as Java's, but for straight computational speed, it's pretty comparable to other compiled languages.

It just isn't a drop-in replacement for Java because it doesn't live in the same space. It does, however, have a similar feel as Python, especially with slices (except Go's don't copy data) and first-order functions. It's a completely different feel though than Python.

Re: The Reliability of Go

#108

Post by jebblue »

beatgammit wrote: post #101
kamaal wrote: post #96

Earlier quoted context omitted.

How good is Go, as a replacement for Java?

What do you mean "replacement for Java"? It's a completely different language: * no classes (only structs and embedding) * no VM, only a run-time (cross-compiling is trivial though) * hardly anything is an object * no exceptions * concurrent by design It's quite possibly the most distant language from Java in the procedural world, which I think is a good thing. It forces you to rethink your data and their interaction…

>> I think Go is a great language and works in most of the spaces where Java lives, except maybe GUIs, but Java was never any good at that anyway.

Eclipse is the world's most popular IDE it's written in Java, Minecraft one of the most popular Indie games ever made was written in Java. What gives you the impression that Java isn't good for GUI's? It's great for GUIs and it's cross platform from the start.

Re: The Reliability of Go

#109

Post by pkulak »

0xdeadbeefbabe wrote: post #106
kamaal wrote: post #96

Earlier quoted context omitted.

How good is Go, as a replacement for Java?

The real downside of go is that it didn't exist when Java arrived. It would have made a much better intro to CS language than Java. Then Android wouldn't have decided to use Java because so many new programmers used it in school.

I don't think Go could have existed in 1996. It feels like a reaction to Java, in some sense. And even if it was built, exactly as it is now, in 1996, it probably would have gone no where.

"It doesn't even have object inheritance! And what do we need all these concurrency things for? Windows has only had preemptive multitasking for a year, and multi-core is still a decade away."

Re: The Reliability of Go

#110

Post by lttlrck »

Stephen_C wrote: post #17
kenkam wrote: post #11

Earlier quoted context omitted.

I agree with not needing to hire new devs, but convincing management and the business to move to a new, untried system with current devs is no trivial feat. It would be nice if he could expand on how that came about.

Andy convinced management by spending a lot of personal development time creating and testing the Go components before demonstrating in a peer review process that they were an appropriate solution. There's no special method - the introduction of Go was incremental. If I remember correctly the monitoring collection component (mentioned in the blog post) was the first. It was small, easy to swap in and easy to demonstr…

This sounds reasonable and certainly worthwhile if it really does result in adoption in "larger more critical/risky projects."

If the result was just one component out of many written in Go then the reality is it was a side-experiment and/or a poor management decision. I do hope that is not the case.

"Andy is very much missed by his former colleagues" hopefully for good reasons, not because they left him with another language and toolchain to maintain :)

Post reply on HN