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

51–60 of 144 posts

Re: The Reliability of Go

#51

Post by MetaCosm »

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…

But for those who choose languages for pragmatic rather than cultural (religious) reasons, Golang is a fairly good egg. Liberally licensed (BSD Style + Patent Grant). Focused on the problems of modern large scale systems.

With modern message passing, great build / deploy tooling, an opinionated structure and formatting standard -- it really makes putting together LARGE system with many moving pieces much easier.

Re: The Reliability of Go

#52

Post by Titanous »

raverbashing wrote: post #10

I remember some time ago a complaint about Go having some bugs on 32-bit machines (something related to the GC) So yes, if you have control over your environment it may be a better choice But the biggest issue with 'less than mainstream' languages are libraries. Things like DB connectors, protocol libraries (SOAP for example - yes, unfortunately this is necessary for some 3rd part services), etc Heck, even for Python…

This was mostly fixed in yesterday's 1.1 release: https://code.google.com/p/go/issues/detail?id=909

Re: The Reliability of Go

#53

Post by laumars »

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 of abstraction are there for convenience otherwise we'd also shortcut C++, C and even assembly and would be writing everything in machine code.

> Google already control your search, your browser, your phone, your email and in some cases your OS (Chrome) why would you want them to control you programming language as well? The idea boggles my mind.

I actually do get the Google paranoia. It's why I cut down on my dependence on them as well. But Go doesn't up-sell Google's services like Chome (which isn't an OS by the way - you must be thinking of ChromeOS), Android, Gmail and so on. And let's be honest, other popular languages have born out from businesses: C from AT&T, Borland lead the charge with Pascal, Microsoft had their version of BASIC bundled with many of the most popular micro PC's of the 80's. Need I go on?

> There is a reason go compilers are C and C++.

Yes, but it's not the reason you're thinking of. The problem was one of the chicken and the egg. 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. C had the same problem when it was young too.

> I wish others felt as strongly about this as I do. If you want to control your future, then use C or C++ or some other ISO standardized language with lot's of free compilers available, do not use a corporate controlled programming language.

The reason people don't agree with you is because: a) C++ would be overkill for a web framework (which is one popular application) and b) half your points are based on misinformation.

Re: The Reliability of Go

#54

Post by 16s »

untog wrote: post #45
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…

The irony of your statement is that Go is open source, and C# is an ISO standard. Those were proactive choices by the companies, and they should really be considered the leading stewards of the language- but not the owners.

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 provides a variety of non-standardized classes (extended I/O, GUI, Web services, etc.). Some cases where Microsoft patents apply to standards used in the .NET framework are documented by Microsoft and the applicable patents are available on either RAND terms or through Microsoft's Open Specification Promise that releases patent rights to the public,[38] but there is some concern and debate as to whether there are additional aspects patented by Microsoft that are not covered, which may deter independent implementations of the full framework."""

source - http://en.wikipedia.org/wiki/C_Sharp_%28programming_language...

Re: The Reliability of Go

#55

Post by icebraining »

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 suddenly prevents you from making HTTP requests to any server outside the Google networks I'll be pretty pissed, but I find that pretty unlikely.

Re: The Reliability of Go

#56

Post by coldtea »

brown9-2 wrote: post #20
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…

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

Re: The Reliability of Go

#57

Post by 16s »

jackielii wrote: post #43
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 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.

Re: The Reliability of Go

#58

Post by icebraining »

16s wrote: post #54
untog wrote: post #45

Earlier quoted context omitted.

The irony of your statement is that Go is open source, and C# is an ISO standard. Those were proactive choices by the companies, and they should really be considered the leading stewards of the language- but not the owners.

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.

Re: The Reliability of Go

#59

Post by coldtea »

_pmf_ wrote: post #34
codonaut wrote: post #23

Earlier quoted context omitted.

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?

> Can anyone explain why exactly a script written in one language would stall, while the same script in another wouldn't? It stalls in Python because the author is not acquainted with non-blocking system programming (the select()-call, which has been around since at least the eighties and has been a part of core Python since a very long time). As to why a software developer who did not invest some minimal time into l…

>It stalls in Python because the author is not acquainted with non-blocking system programming

Citation needed.

How about "he is acquainted but can't be bothered to use it retrofitted to a language not tailor made for it"?

>As to why a software developer who did not invest some minimal time into learning basic system programming feels qualified to write a blog post about this topic is another question.

And why you think you're any better than him based on a short blog post (and especially one in which he does not delve into why the Python version was slower or says it would be impossible to make it faster, just mentions it's speed in passing), is beyond me.

Maybe cut down the snark?

Re: The Reliability of Go

#60

Post by 4ad »

pcwalton wrote: post #29
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.

I've heard conflicting things here. I was under the impression that Go was not memory safe while mutating maps without synchronization. For example, these articles allude to possible memory corruption: http://golang.org/doc/articles/race_detector.html "memory corruption" http://golang.org/doc/faq#atomic_maps http://talks.golang.org/2012/splash.article "Go is not purely memory safe in the presence of concurrency."

You are correct, I was presenting a simplified view.

While Go was designed with memory safety in mind, the specification does not guarantee memory safety. With that being said, it also doesn't preclude it (unlike C). For example, the gc implementation without parallelism (not to be confused with concurrency) is memory safe while the gc implementation with parallelism is not. This is the reason why GOMAXPROCS is always 1 in the playground and on the App Engine. There's nothing precluding a paralel implementation from also being memory safe.

Post reply on HN