Go has the advantage of being developed by Rob Pike and Ken Thompson. It also potentially has the marketing muscle of Google behind it, although the most I've seen so far is free stuffed Gophers at OSCON.
Type safety, easy concurrency, static checking, C-like syntax, fast compilation time, concise syntax, etc. Java is ripe for replacing as the default language for (new) large systems. The replacement could be another language on the JVM, but I think Go has a good shot.
Depends what you mean by type safety. If by type safety you mean free from segfaults, Go is very much type-unsafe (send a map over a channel, access it concurrently, and it will segfault).
> send a map over a channel, access it concurrently, and it will segfault
Not exactly. Go's maps may safely be read from multiple threads simultaneously, but writing at the same time as reading or writing will yield undefined behavior.
Go programs don't segfault like C programs. They typically panic, providing a descriptive stack trace of where the problem arose.
As I mentioned in my other thread, what you're describing are "thread safe data structures," which Go doesn't provide by default. We provide the fast and non-thread-safe data structures and let the programmer build the concurrency mechanisms around them (easily done with a lock or using goroutines/channels).
What do you mean ? I you don't use synchronization protection when you access your structures from different threads, you'll have the same inconsistency in your data. Using the explicit Mutex of Go doesn't seem so different than creating an object on which synchronizing your blocks as you do in Java.
Or do I miss something in your comment ?
EDIT : In my opinion, a program that doesn't crash and goes on running with inconsistent data structures is mainly hiding a failure which will appear in a worse way later (for example when those data will be used). To fail fast is often more secure. But my opinion may be based on the fact that I see too many java programs which seem to work but that nobody can touch because they're just in the lucky state where bugs don't surface too much.
Mutating a hash map in Java while another thread reads it won't cause bad things like:
(a) memory you don't have access to to be read;
(b) other threads to crash;
(c) the VM state to be corrupted;
(d) the GC to crash;
and so on. The Java world is still in a consistent state. In a security-oriented world, this is important.
To the reply: It's a bit pedantic for me to say this, I know, but that's still "a consistent state". Basically, a Java program can't do anything it wouldn't otherwise be able to do by modifying a hashmap concurrently. Java programs can go into infinite loops. They can't access uninitialized memory.
There's no one definition of type safety. It ultimately depends on what your type system is trying to enforce. I strongly suspect, however, that most programmers expect "type-safe" languages to enforce memory safety, and that Go's lack of memory safety is surprising in this context.
That is a very unusual definition of "type safety." What you're describing is more commonly known as "thread safety," in my experience.
By your definition, is Java type safe? You still need to guard against concurrent mutation of shared data in Java and in most other languages that support shared mutable state.
We typically describe Go as "memory safe," in that you can't address uninitialized memory (unless you import package "unsafe", which clearly demonstrates your intent).
Java is type safe, because the language defines clear semantics for what happens when you mutate two memory locations simultaneously (you get one result or the other). Under no circumstances does the program have truly undefined behavior. Java HashMaps aren't thread-safe, but they will just do the wrong thing when you try to access them concurrently. Under no circumstances will the program be able to read or write undefined memory.
By contrast, your Go program's behavior becomes undefined when you mutate and read a hashmap concurrently among multiple threads. Anything can happen.
Edit (addressing the reply below): That's fascinating, thanks. It really speaks to the wisdom of writing hash maps in the library, on top of the language, rather than unsafely in the runtime as Go does. (This would unfortunately require generics, so it's not an option for Go.)
It's very difficult to predict all that can go wrong with unsynchronized access to data structures that aren't designed to be thread safe. The beauty of Java here is that the core primitives can never lead to accessing undefined memory, and therefore hash tables, however badly they mess up, will never lead to that core principle being violated. This is critical for security, for example.
I agree with everything you've said in this thread, except this: "type safety" should mean that the system has some belief about the type of values that cannot be compromised.
(sometimes type safety can be proven absolutely by static checking, but you have otherwise only run-time type checking, e.g. dynamic JVM languages, introspection).
Unlimited memory corruption does seem to imply that run-time type guarantees are gone, but it's still better to use the most appropriate terms.
Unfortunately Go still lacks generics, something that will hinder it from being widely accepted from the Java/C# crowd, for good reason. There are some good arguments to be made for why Go's error handling is subpar as well that I think could disqualify it for a lot of people.
5 minutes isn't fair. I took a look at http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... first. OK so Go is about on par with Mono's C# performance and uses up to a 1/3 of the memory with code that is more concise. That's cool because it means I'm not sacrificing anything over the platform I specialize in (C#; although the last time I looked at the Alioth C# code I thought I saw some obvious improvements). I see there is a Go STOMP client for Apache Apollo, which means I can supplement the existing code in my current project without having to rewrite everything.
Way more than 5 minutes. Where are generics or do I have to learn some new construct? Wait a minute, is this thing object oriented or what? If not, why not? Do I have to learn some new philosophy? Already feeling a sense of dread having been through this game 10s of times before with other languages.
I decided to research a bit to see if anybody else with a C# background had looked into Go. I found this, which confirmed my feelings that Go is for people who probably haven't given C# or Java a fair chance: http://www.jondavis.net/techblog/?tag=/c%23+vs+go . That's when I also discovered searching for 'Go' on Google is impossible because of the poor choice of name and decided I wasn't going to spend any more time on it, already being aware that aside from what looks like a total philosophy change (without it being clear whether it'll be worth it), I'm going to lose out on my awesome set of development tools (Visual Studio), years of C# experience and the HUGE .NET ecosystem, in exchange for what? Relatively unimportant performance advantages?
At the end of the day, if performance/memory are issues I can just add more EC2 nodes to my architecture. At some point I'll hopefully make enough money to pay other people to worry about the technology. That being said I realize that as a developer who wants to be a manager/owner I'm probably in the minority of readers here.
It seems you deleted your comment asking why you were downvoted. Here's why you were downvoted:
> Way more than 5 minutes. Where are generics or do I have to learn some new construct? Wait a minute, is this thing object oriented or what? If not, why not? Do I have to learn some new philosophy? Already feeling a sense of dread having been through this game 10s of times before with other languages.
If you didn't get past the fact that Go isn't object oriented, then you clearly didn't get very far into the language. And your resistance to "some new philosophy" shows you aren't interested in a new language with real ideas, but at most a different way to express what you already know and do while programming.
It was no longer relevant and seemed to attract more downvotes. I have spent years with x86 + MIPS assembly language, C, C++, C#, Visual Basic and Q[uick]BASIC; months with Java, Scheme, Python, PHP; days/weeks with AS3, HaXE, Erlang, Scala, E, Objective-C, Ruby, Delphi, Pascal, Concurrent Clean, Prolog, ADA. I've probably missed a few.
My point is (a) I'm not a lazy developer that doesn't enjoy learning new things or experimenting with new languages and (b) I have found a great ecosystem in .NET and C# and I've been around the block; at first sight I simply cannot see a compelling reason to invest more of my increasingly limited time into learning Go.
If Go has great new vision or compelling difference from other languages then why isn't it there on the homepage at golang.org jumping out at me? All I see are technical details and a huge guide. While I applaud clear, detailed documentation, I'm not going to read through that documentation unless I have some idea of the payoff. I just spent half of my weekend researching and investigating a ton of message brokers for my current project because there's value in the outcome. Researching a new programming language needs to have a huge payoff, or I need to have lots of free time (which unfortunately I don't).
There is absolutely nothing to sell me on the language on the homepage, or in the OP's blog post, and nothing to distinguish it from the 10s of other new languages out there. The FAQ touches on the fact that e.g. it's not object-oriented but not WHY. It just mentions "interfaces" and says "we believe". So I'll have to go and play with it and build something substantial to find out what they might be talking about. The goals mentioned in the FAQ are really not interesting (have you read it?) - perhaps the ideas around concurrency are convenient but they are limited in scope and don't directly address the more complex concurrency issues better than my current platform that I'm facing while I build a web crawler.
To be clear once again: It may be that Go is absolutely amazing and awesome... but if I had to spent days looking into every new language that pops up on the Internet I would never get anything done, and this is the point I was trying to convey in response to the parent's post. It's still on my list to look into but I just don't have a week to commit to what looks like quite a lot to manually digest.
Given all the languages you already programmed with, and given that the Go specification is relatively short (approximately the same as Scheme), maybe you overestimate the efforts it would require to learn it. But you don't need to, that's all fine.
Heh I think you inadvertently proved my point. I spent 6 months with Scheme, working through half of the SICP for personal growth. Just because the specification is simple it doesn't mean the patterns and lessons are straightforward, and I'm a pretty slow learner. If you read the Go FAQ you will note that about 1/3 of it is along the lines of "Why doesn't Go...". When I see that sort of language it's clear that between the lines there's a lot to learn, and the only way for me to learn a language is to write code.
But after all of this I think I'm going to have to write one of my site-specific crawlers in Go for fun; since Go has a STOMP binding it should be easy to integrate into my existing architecture. Where things will get interesting is finding a compatible serialization library (and so we start getting into the real world problems of using a new language to solve interesting problems... hopefully one of the .NET protocol buffer implementations will work correctly with the one I imagine exists for Go).
you have nailed wisdom to these younger 16 years old crowd. But nowadays younger crowd needs fashion,pizzaz,Prestige etc.
in my experience learning about Message Brokers is very important than learning new language.
Why do you feel that? From the Go FAQ, which now I feel obliged to at least read in its entirety because of how much heat this post has stirred:
"Why does Go not have generic types?
Generics may well be added at some point. We don't feel an urgency for them, although we understand some programmers do.
We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. Meanwhile, Go's built-in [functionality] mean in many cases it is possible to write code that does what generics would enable, if less smoothly.
This remains an open issue."
Clearly the designers of Go consider generics a topic worthy of debate.
But apparently you consider "no generics" a deal-breaker without seeing why generics haven't been added yet, and why it isn't an issue for the many developers writing real-world production Go code.
I'm confused. I never called it a deal-breaker, just a surprise. The language designers, in their FAQ, acknowledge it as an opinionated gap where their own opinion hasn't been fixed, so I'm not imagining it as a gap either.
Your comment about "real-world" code is even more puzzling, as if all "real-world" code is somehow equivalent in abstraction needs. There are guys who've written serious code running in billions of cellphones where generics would be unimportant. Same thing for scientific or massive data crunching applications, e.g. Google's infrastructure.
In the space I work in - enterprise applications integrating large, disparate systems where you have zero control over interfaces and data formats but somehow need to get everything talking together nicely, generics are invaluable in structuring your code and making it reusable.
To be fair, I happen to be building a little search engine of my own and Go may turn out to be great for building the crawler components (the processing is site-specific), and I may end up using it for that purpose if I have the time to explore it or see value in it (if I find memory pressure to be an issue then saving 1/3 RAM on my EC2 instances over C# is a definite win, but since most of the work is I/O constrained I may never run into an issue at all).
> In the space I work in - enterprise applications integrating large, disparate systems where you have zero control over interfaces and data formats but somehow need to get everything talking together nicely, generics are invaluable in structuring your code and making it reusable.
Luckily for you, Go already solves these problems incredibly naturally! Unfortunately, you haven't looked into how Go solves those problems, primarily through its interfaces and type embedding, plus its slices and so on are already generic.
It's true they aren't sure if they need it or not, but you clearly haven't looked into many feel they are unnecessary and that the present language is more than sufficient for solving many needs. In fact, Go is almost explicitly designed to handle the production cases you tackle. But it seems you've said in other threads that learning new approaches isn't really worth it for you, in which case, it's unsurprising that new languages aren't offering you much.
I'm not sure interfaces are really the "incredibly natural" solution. Why, for example, should a container care about what interface its contained element implements? A list is really agnostic of such things and forcing an interface on the item is silly, just to contain it.
>Already feeling a sense of dread having been through this game 10s of times before with other languages.
What? I'm a student still learning new languages and it took me no time to look up and quickly grok duck typing. If that prevents you from learning a language...
Seriously... it's an hour to skim and read through. Hour or two to put together a decent non-trivial server demonstrating channels. I really don't know what your big long rant is about. It's not hard to find reasons Go was designed the way it was, find what it's goal is and read enough intro docs to get up and coding with it easily.
Your points #2 and #3 are in conflict. Not all languages are equally equipped for the same tasks, which is what really matters. I wouldn't write a web application in bash any more than I'd write a batch file renamer in assembly and pretending that the programmer not being "decent" enough to make those things true is disingenuous
The question is how do they overcome the opinion, hearsay and preferences that are louder than the truth?
Too few devs:
- truly give something 5 minutes before jumping to their foregone conclusion.
- admit that most languages with a decent capable and decent programmer are all, pretty equally equipped.
- every language + framework has it's pros and cons.