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

141–144 of 144 posts

Re: The Reliability of Go

#141

Post by swah »

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?

IOW, How reusable do you feel the stuff you write in Go is?

Re: The Reliability of Go

#142

Post by azth »

koraytaylan wrote: post #137

first I saw go I thought meh but with so many people saying good things about it makes go inevitably more interesting day after day. however I just feel like it's going to be like mongo. when it first got popular, people all moved to mongo as it miraculously solving all the problems. same thing happening with go now and after sudden disappear of all the mongo evangelists, this makes me doubtful about go obviously.

IMO, people like hype, and a lot of the time, they are not aware of what better alternatives exist. If Go did not have Google or Ken or Pike as names behind it, do you think it would have gone anywhere? It doesn't really offer anything special compared to more expressive and safer languages like Scala and Rust for instance.

You can see it right here in the comments: someone said that Go is a memory safe language. It is not any more safer than Java is in that regard. We need languages that are safer than Java and Go.

Re: The Reliability of Go

#143

Post by bjeanes »

pjmlp wrote: post #136
bjeanes wrote: post #133

Earlier quoted context omitted.

"concurrent by design" != "can be concurrent / has threads"

Not all Java implementations map language threads to OS threads. The implementations that use green threads are no different than go-routines, which were seen for the first time in Modula-2 just as information.

What I was implying is that "built for concurrency" isn't just about threads (or goroutines). It's about communication between concurrent routines and shared state. Go is designed to have less coordination in concurrency by encouraging communication via channels instead of shared state.

Re: The Reliability of Go

#144

Post by randomsearch »

tptacek wrote: post #38
randomsearch wrote: post #35

Earlier quoted context omitted.

As an Ada 95 developer, I like that Go seems to have an Adalite concurrency-related syntax.

Both systems have a CSP design, right? Golang is pretty up front about having lifted its design from Hoare.

Yes, you're right - the design comes from CSP. The syntax looks nicely Adalike.
Post reply on HN