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 technologists and developers go on and on about how wonderful and better these corporate languages are.
With C and C++ and Python and Ruby and Perl we have freedom. With Go, .Net and Java, etc. we do not.
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 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.
There is a reason go compilers are C and C++.
.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.
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.
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.
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.
The world begs to differ.
For one, Java and the JVM have a huge ecosystem, and nobody's complaining. And .NET is huge on Windows, and nobody's complaining their either. Actually, they rather like it that MS is in charge. [For the conversational english challenged, "nobody" means "a few outliers don't count"].
Oh, and Go is open source with a large community.
>All of these compilers or JIT interpreters are implemented in C or C++ (which are open languages with ISO standards).
Which is beside the point. Almost all compilers and JITs are written in C/C++. So what?
>With C and C++ and Python and Ruby and Perl we have freedom. With Go, .Net and Java, etc. we do not.
With those you have SOME freedoms. With .NET and Java you have OTHER freedoms. E.g I have the freedom to take advantage of a huge collection of libraries, with top-notch commercial support for a lot of them, and use them in around 4-5 top notch languages like Clojure, Scala, JRuby etc, with the most performant JIT in town. All the other options you mention don't give me THAT freedom.
>There is a reason go compilers are C and C++.
Portability, familiarity and low-levelness?
Also, you DO know that C (and IIRC C++) were once created and controlled by a corporation (AT & T) too, right?
You are not using the correct term. In Web 2.0, these are not called "annoying", but "unobtrusive".
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.
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).
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...
Both of which originated in AT&T Bell Labs.
You'll find the $EVIL_COMPANY quite well represented there too.
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.
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.
Technically, if I'm not mistaken, Go is (currently!) implemented in Plan 9 C, which is not the same thing as ISO C.
Also, Go is very different from .NET and Java. For starters, it was published in source pretty soon after it had been announced. You have your freedom right there.
Microsoft has an undue amount of influence over both C and C++ thanks to the Windows platform and their questionable lack of full support for the relevant language standards.
Ultimately, what controls a language is who controls the market and who employs most of the people implementing the most popular compilers/interpreters for it.
The only reason C++ lives on is because platform holders have been willing to support it; and those platform holders are large corporations.
The second paragraph reads like: replacing a relational DB with a (in memory?) key value store resulted in more throughput. He implemented it in Go, but he could have implemented it in any other language.
What I want to know is how he convinced management to use Go? Where did he find the programmers? I work in a similar environment and I don't see my firm adopting Go any time soon, although I wished they had as I'm a big fan of Go and believe it has a place especially server side processes (e.g. algo trading, market data feeds) where concurrent connections are prevalent.
I assume he used Go's concurrency features, although he could have articulated on that.
> Where did he find the programmers
I don't think you explicitly need to hire new programmers. If you have capable, existing programmers, the learning curve is pretty minimal for something like Go.
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 for something like that? I don't find this blog story remotely useful in the whole 'why Go' thing.
More details would be really helpful. Also the author seems to be responding to a question of reliability by talking about performance which is not the same thing.
"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").
With sufficient development time Andy could have introduced more concurrency and optimisation into the Python monitoring component (I'm thinking Gevent might have been a nice fit)...but without introducing additional frameworks or libraries Go had these features as a core component.
The offhand performance comment aside, Andy was noting that a component written in Go is depended on to handle VERY high volumes of message throughput in a financial services firm.
While no proof of reliability it is merely anecdotal support that Go is being used in production environments.
The only reason I'd assume the Go version was concurrent and the Python one wasn't is that concurrent processing in Python can be very prickly. That is by design. Guido has talked about how adding too much support for concurrency at the language level would complicate things and probably end up with a language that was very non-Pythonic.
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 learning basic system programming feels qualified to write a blog post about this topic is another question.
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 2 (not to mention P3) this is an issue sometimes
I have to agree about libraries. You don't realize how great it is to have finely-tuned JDBC drivers for every database on Earth until you can't use them.
Go had an easy to run into and not obvious to fix bug on 32bit. That's a bigger problem than most gcc/ICC/whatever bugs, which tend to be happen in obscure corner cases (because the most obvious bugs are long gone).
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.
* no classes (only structs and embedding)
* no VM, only a run-time (cross-compiling is trivial though)
* hardly anything is an object
* no exceptions
* concurrent by design
It's quite possibly the most distant language from Java in the procedural world, which I think is a good thing. It forces you to rethink your data and their interactions.
I think Go is a great language and works in most of the spaces where Java lives, except maybe GUIs, but Java was never any good at that anyway. It's more suited for the server, but it can work well for computationally-intensive tasks as well.
Go is better thought of as a replacement for whatever server stack you have than a replacement for a given language.
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 what the threads are doing at the point of failure.
Go programs can panic but that doesn't produce a core dump, only a stacktrace.
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."
I presume Go ( CGO ) will have to deal with segfaults too, and I'd like to understand what it does.
What does he mean? I've searched the Go websites but it seems all Google gives you is the Go compiler and a tour.
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.
1. Cancel their future contributions.
2. Create a closed source fork (is this feasible with the license if they don't control what others have contributed?)
In the worst case, if there aren't enough go enthusiasts it goes the way of other niche languages. Since the supporters seem to be active enough, I doubt that'll happen.
