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

71–80 of 144 posts

Re: The Reliability of Go

#71

Post by TheAnimus »

kenkam wrote: post #16
TheAnimus wrote: post #9

Earlier quoted context omitted.

>I assume he used Go's concurrency features, although he could have articulated on that. I've yet to find a good explanation of what is so special about them, why I'd choose it over F# or C# Async/Await. In the case of pinging servers, I would have prefered to use a 'cheaper' to develop language, which has a boatload of libraries that are widely used. Anyone got any links or stories about why you would want to use Go…

I think async/await is semantically similar to the promises pattern [1] but different to the Go concurrent models using channels. What the compiler does with await/async is quite interesting [2]. Essentially it takes your await/async code and turns the related code into a state machine which keeps track of how control should be switched between the callee and the await keyword (and uses Task for the async bit). [1] h…

Thanks for replying.

But I'm not trying to say that async/await are superior to the actor paradigm (which is what my understanding Go subroutine, don't call em threads things are).

Just that I would have hazarded a guess for pinging a bunch of servers, the TPL stuff is a better choice, than actor?

I feel there is a lot of buzz around Go, though I'm not seeing why. I guess my only option is to find something suitable enough for it, and give it whirl. But of course I am lazy, so trying to find someone elses suitable experiences would be great.

Re: The Reliability of Go

#72

Post by waterside81 »

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 nice & tidy).

Folks - Go ain't a fad, it's a great language if your problem domain benefits from concurrency AND if you need to deploy to multiple locations and love being able to just drop a single binary and walk away.

Re: The Reliability of Go

#73

Post by exch »

tezza wrote: post #66
4ad wrote: post #19

Earlier quoted context omitted.

Go programs don't segfault because Go is a memory safe language (unless you use unsafe). They can segfault in the runtime, but that never happened to me. Nevertheless, what happens when you segfault is a property of the system, not of the language implementation. It will happen whatever happens to C programs that segfault. Go programs can panic but that doesn't produce a core dump, only a stacktrace.

Well Java doesn't generally segfault either... until you start referencing external libraries ( freetype.dll , serial_comms.dll, swt.lib ) I presume Go ( CGO ) will have to deal with segfaults too, and I'd like to understand what it does.

As a practical example to 4ad's answer, here is the result of NULL-pointer dereference on the C code on my system (Arch Linux 3.9.2-1-ARCH). It does yield a SEGFAULT:

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

Re: The Reliability of Go

#74

Post by rbehrends »

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 memory management, but not static typing.

And unfortunately, while there are quite a few languages with these features, only few have the critical mass, long term support, and infrastructure to justify investing in them for serious development.

Re: The Reliability of Go

#75

Post by bentcorner »

laumars wrote: post #53
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…

> I'm sorry, but the world does not need another company-controlled, corporate programming language. .Net (Microsoft), Java (Oracle) and now Go (google). .NET isn't a language and Java and Go are both open (but with the main contributers being employees from the aforementioned corporations). > All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards). Layers…

> It's all well and good writing Go's compiler in Go, but then how are you going to compile it? A language needs to reach a certain threshold before it becomes possible to write a compiler in it's own language.

Is Go not at this point yet? I only have casual knowledge of the language, but it sure sounds like it is capable of building itself.

Re: The Reliability of Go

#76

Post by pjmlp »

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…

C and C++ are corporate languages as well, ask AT&T.

Re: The Reliability of Go

#77

Post by icebraining »

TheCoelacanth wrote: post #67
icebraining wrote: post #58

Earlier quoted context omitted.

Only a portion of C# is standardized. And none of Python, Perl or Ruby are.

Ruby has an ISO standard.

So it does, I wasn't aware. Though, is the version submitted still supported by any modern interpreter?

Re: The Reliability of Go

#78

Post by pjmlp »

bentcorner wrote: post #75
laumars wrote: post #53

Earlier quoted context omitted.

> I'm sorry, but the world does not need another company-controlled, corporate programming language. .Net (Microsoft), Java (Oracle) and now Go (google). .NET isn't a language and Java and Go are both open (but with the main contributers being employees from the aforementioned corporations). > All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards). Layers…

> It's all well and good writing Go's compiler in Go, but then how are you going to compile it? A language needs to reach a certain threshold before it becomes possible to write a compiler in it's own language. Is Go not at this point yet? I only have casual knowledge of the language, but it sure sounds like it is capable of building itself.

I would say it is.

Sure you will need to use Assembly for a few runtime parts, but C is no different, if you look at ISO/ANSI C without language extensions.

Re: The Reliability of Go

#79

Post by whyrusleeping »

bentcorner wrote: post #75
laumars wrote: post #53

Earlier quoted context omitted.

> I'm sorry, but the world does not need another company-controlled, corporate programming language. .Net (Microsoft), Java (Oracle) and now Go (google). .NET isn't a language and Java and Go are both open (but with the main contributers being employees from the aforementioned corporations). > All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards). Layers…

> It's all well and good writing Go's compiler in Go, but then how are you going to compile it? A language needs to reach a certain threshold before it becomes possible to write a compiler in it's own language. Is Go not at this point yet? I only have casual knowledge of the language, but it sure sounds like it is capable of building itself.

Not quite yet, it still builds a small bootstrapping tool with C

Re: The Reliability of Go

#80

Post by pjmlp »

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…

Oberon, Oberon-2, Component Pascal, Active Oberon, Modula-3, ...
Post reply on HN