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

81–90 of 144 posts

Re: The Reliability of Go

#81

Post by whyrusleeping »

_ak wrote: post #62
exch wrote: post #42

Earlier quoted context omitted.

Go is completely open source. The primary devs just happen to work at Google. That is all. If anything, the Google name attachment may only serve to help convince management that Go is a safe, long-term bet. If you don't like the Google attachment, you are entirely free to fork the language and make it your own.

Plus there exists not one, but two implementations that fully conform to the spec. So you're not even bound to one specific compiler implementation.

Soon to be three, llgo is getting closer!

Re: The Reliability of Go

#82

Post by laumars »

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 have thought so (but I'm far from an expert on such matters). However you'd still have the issue of users wanting to download Go's build tools from source (as not everyone likes to install pre-compiled binaries on their systems) and not being able to compile the compiler.

Granted gcc could now be used. But then you're back to using a compiler built in C++ to build Go code.

Re: The Reliability of Go

#83

Post by whyrusleeping »

icebraining wrote: post #65
16s wrote: post #61

Earlier quoted context omitted.

Only part of C# is standardized. The majority of it is not. http://en.wikipedia.org/wiki/C_Sharp_%28programming_language... There are several free Python and Ruby interpreters and they are not corporate controlled. Ruby does have an ISO standard (ISO/IEC 30170:2012).

There aren't "several" free Python interpreters. PyPy is still in an early stage and Jython still doesn't have a stable version supporting Python 2.7. Golang has two different implementations (6/8g and gccgo), one of which part of the GNU project, so it's not particularly behind.

dont forget llgo!

Re: The Reliability of Go

#84

Post by azakai »

icebraining wrote: post #65
16s wrote: post #61

Earlier quoted context omitted.

Only part of C# is standardized. The majority of it is not. http://en.wikipedia.org/wiki/C_Sharp_%28programming_language... There are several free Python and Ruby interpreters and they are not corporate controlled. Ruby does have an ISO standard (ISO/IEC 30170:2012).

There aren't "several" free Python interpreters. PyPy is still in an early stage and Jython still doesn't have a stable version supporting Python 2.7. Golang has two different implementations (6/8g and gccgo), one of which part of the GNU project, so it's not particularly behind.

> PyPy is still in an early stage

That's unfair.

Re: The Reliability of Go

#85

Post by scott_s »

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…

All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards).

Both of which originated in AT&T Bell Labs.

Re: The Reliability of Go

#86

Post by tezza »

exch wrote: post #73
tezza wrote: post #66

Earlier quoted context omitted.

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

Thanks exch, that's really decent of you to construct an example.

I wonder that if there are multiple threads / goroutines are their callchains also printed ?

Re: The Reliability of Go

#87

Post by awj »

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.

Considering people are writing web servers and all sorts of other things in it, I'm sure it's suitable for writing a compiler. Technically all you really need is logic, some data structures, and low level file I/O. If you're going to spit out asm and let someone else deal with that, then all you need is normal file I/O.

It seems like Go is trying to capitalize on the momentum they have. Improvements to the language are still coming quickly. I'd be surprised if a self-hosting compiler isn't among their goals, but writing a new compiler without slowing down language progress in the current reference compiler is not easy.

Re: The Reliability of Go

#88

Post by gingerlime »

exch wrote: post #42
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…

Go is completely open source. The primary devs just happen to work at Google. That is all. If anything, the Google name attachment may only serve to help convince management that Go is a safe, long-term bet. If you don't like the Google attachment, you are entirely free to fork the language and make it your own.

> If anything, the Google name attachment may only serve to help convince management that Go is a safe, long-term bet.

I'm generalizing, but given "management" lack of technical understanding, and the (general) knowledge that Google shuts down services left right and center, then I'm not sure this is necessarily perceived as such a safe, long-term bet...

But I wouldn't have thought that the choice of language is necessarily something that management typically cares about.

Re: The Reliability of Go

#89

Post by jlarocco »

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.

It is possible to write a Go compiler in Go.

But the current compiler works, has a lot of testing and production use and isn't broken in any serious way. For a compiler, I'm not sure Go offers enough benefits over C/C++ to make it worth throwing away the existing code base and rewriting.

Re: The Reliability of Go

#90

Post by brown9-2 »

codonaut wrote: post #23
kenkam wrote: post #2

I would like to hear more about the technical implementations from the author on how he managed to improve performance. He mentions: "Due to the complex nature of the system this script could take up to three minutes to scan nodes and process the results" but how does Go solve this complex system that Python couldn't? 3 minutes to 1 second is a superb improvement. The second paragraph reads like: replacing a relation…

Can anyone explain why exactly a script written in one language would stall, while the same script in another wouldn't? Is there that much inherent instability in Python? Can it be assumed that the scripts in this case aren't comparable?

A completely different implementation would seem likely to have been made.
Post reply on HN