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

61–70 of 144 posts

Re: The Reliability of Go

#61

Post by 16s »

icebraining wrote: post #55
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 think your point is a little incoherent, since C# is an ISO standard, while Python, Perl and Ruby aren't, nor do they have "lots of free compilers available". Personally, I don't use Gmail, Android, Chrome or ChromeOS, for real reasons pertaining to data ownership, privacy and maintenance of services, but I see no reason not to use their fully BSD licensed tools that I can run on my own hardware. If Golang 2.0 sudd…

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

Re: The Reliability of Go

#62

Post by _ak »

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.

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.

Re: The Reliability of Go

#63

Post by _pmf_ »

tptacek wrote: post #41
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 too am upset at the prospect of annoying little text ads popping up in my source code. DOWN WITH GOLANG.

> I too am upset at the prospect of annoying little text ads popping up in my source code.

You are not using the correct term. In Web 2.0, these are not called "annoying", but "unobtrusive".

Re: The Reliability of Go

#64

Post by Jtsummers »

16s wrote: post #57
jackielii wrote: post #43

Earlier quoted context omitted.

Go is open source: http://golang.org/LICENSE

I never mentioned closed source or open source in my comment. I mentioned "corporate" languages. Go is Google's just as much as .Net is Microsoft's.

A major difference (re dependency on the producer) is that go is a language while .net is a platform. It would be (relatively) easy for users of golang to step away from Google if they became a problem while retaining their codebases. Moving from MS's platform is harder (mono is out there, but is it sufficiently complete at this point?).

Re: The Reliability of Go

#65

Post by icebraining »

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

Earlier quoted context omitted.

I think your point is a little incoherent, since C# is an ISO standard, while Python, Perl and Ruby aren't, nor do they have "lots of free compilers available". Personally, I don't use Gmail, Android, Chrome or ChromeOS, for real reasons pertaining to data ownership, privacy and maintenance of services, but I see no reason not to use their fully BSD licensed tools that I can run on my own hardware. If Golang 2.0 sudd…

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.

Re: The Reliability of Go

#66

Post by tezza »

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

If I had been at that conference, I would have asked the same question. Thanks for the data point (Yes, fine for production AFAYCT). What does Go do when it segfaults ? Simply saying it has not-yet-segfaulted is but one factor of production-readiness. Does Go leave just a coredump ? One thing I like about java in a production sense is that if the JVM exits unexpectedly it writes an hs_err_pid file that has a dump of…

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.

Re: The Reliability of Go

#67

Post by TheCoelacanth »

icebraining wrote: post #58
16s wrote: post #54

Earlier quoted context omitted.

1. I never mentioned closed source or open source in my comment. 2. Only a portion of C# is standardized. """The C# language definition and the CLI are standardized under ISO and Ecma standards that provide reasonable and non-discriminatory licensing protection from patent claims. However, Microsoft uses C# and the CLI in its Base Class Library (BCL) that is the foundation of its proprietary .NET framework, and which…

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

Ruby has an ISO standard.

Re: The Reliability of Go

#68

Post by tezza »

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…

If they're as nasty as you say... please don't look at the major contributors to your OSS toolchain.

You'll find the $EVIL_COMPANY quite well represented there too.

Re: The Reliability of Go

#69

Post by Roboprog »

coldtea wrote: post #56
brown9-2 wrote: post #20

Earlier quoted context omitted.

On the Python script, it sounds like the performance problems were more likely than not caused by inadequate use of any concurrency features rather than an inherent problem with Python The Language. As exciting as Go is it sounds like replacing the old script with a sufficiently concurrent and well-written application in any language should have worked well. More details would be really helpful. Also the author seems…

> On the Python script, it sounds like the performance problems were more likely than not caused by inadequate use of any concurrency features rather than an inherent problem with Python The Language. "Inadequate concurrency features" IS an inherent problem with Python The Language. (Notice I didn't say "inadequate use of concurrency features", I said "inadequate concurrency features").

It's been a while, but I remember that Python threads run into a global interpreter lock quite often, yes?

Re: The Reliability of Go

#70

Post by 4ad »

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 I said, this is a property of the system.

The system can be configured to do anything, don't core dump, core dump but overwrite any previous core dump, core dump in some special directory taking care not to overwrite anything, etc[1]. Of course, a process can ask for special treatment, but Go binaries are no different than default C binaries.

[1] http://man7.org/linux/man-pages/man5/core.5.html

Post reply on HN