"It's interesting to compare Swift and Go. One has caught up to the 1990s in language design, with the other firmly in the 60s."
Swift includes many of the language features that have been touted by the academic functional programming community for years but which have not made a large impact in industry, like algebraic data types, pattern matching, and Optionals. The designers of Go apparently looked at the past few decades of language research and decided that none of it interested them. The only really innovative parts of Go are its concurrency support, which Swift seems to be completely lacking.
They see things like func, and think Go was the first language to come up with it, when many others already had it.
First thing I thought of when I saw all the func calls, curly braces and beaks (->) was "this looks like in between Lua and Go"
After starting to dig into the book, it's pretty apparent that isn't the case
It seems like half the comments about Swift have been comparing it to languages which it superficially resembles at the syntax level. And the other half of the comments are along the lines of, "I can't stand Objective-C's brackets, this looks much better."
It's like that scene from The Matrix: "I don't even see the code. All I see is blonde, brunette, red-head." I'd have expected experienced programmers to have reached that point long ago.
0. Semantics
1. Syntax
2. Lexical syntax
3. Lexical syntax of comments"The first thing you're exposed to is its sounds and symbols.
They look & sound strange and your brain instinctively tries to make sense of them by comparing it to something you are already familiar with.
Then when you dig into it you begin learning vocabulary and grammar. You focus on that for a long time until the sounds sound less like gibberish and resemble something like what you've been practicing putting on paper.
Once you get comfortable with the constructs and stop focusing on them you can start conversing - putting more effort into what you're trying to say then how you would go about saying it.
After that then you can start picking up all the idioms, colloquialisms, cliches, double entendres, etc
Finally you can start inventing your own.
Worth noting that one of the greatest problems in software development is concurrency support and its ease of use/robustness.
It is a critical and growing issue.
In contrast, having or not having generics, optionals (in C# these are nullable types), algebraic data types (which in Go is interface, albiet minus the type set checking) make a marginal, vanishingly small difference in programmer productivity or application performance/stability.
99% of the articles about the profound importance of generics are people building nothing of interest for anyone, and it is exactly that vaguery of design that makes generics seem so important.
Concurrency, however, is everyone's problem. It is the modern programming problem. Nothing is more important.
And FWIW, all languages draw from each other, and of course they should learn from each other. It is very likely that Go influenced Swift in subtle ways, but it is obvious why that wouldn't be referenced.
But I'm actually curious as well. Given that Objective-C (and now Swift) have GCD, what language features are needed to bring concurrency up to par with Go?
I'm sort of reminded of what Microsoft did after Task Parallel Library came out with C#. People didn't pay attention too much to what MS was building until async/await came out (along with tooling support). But async/await built upon TPL. So it's probably a matter of time for Apple to do something similar on top of GCD, if they're going to do something. But I doubt it's going to look something like Go.
I think it's quite a stretch to say that people who have written articles about generics are almost never building anything of importance. The browser you used to post this comment makes extensive use of generics via C++ templates, which were well documented by their authors in order to fill a very important role (smart pointers for reference counted objects, for one).
I said 99%. The vast majority of language observations online are language tourists, and the observations are seldom practical or rational, but instead are of the "in kicking the tires and making nothing in practical, here are my thoughts".
Those sorts of posts dominate.
Generics have a place, but their importance is...overstated. Though I would quite broadly disagree with the notion that auto_ptr -- a shim on C++ -- justifies the notion of generics.
I do not agree that the importance of generics is overrated and it's one of the primary reasons I won't be using Go. I need to know what type of object I'm working with to feel comfortable when programming, and I like the reassurance from the compiler that it agrees with me that that is actually what I'm working with. I would really like Go if it had generics, but it's just too unsafe for me to use in its current form.
Don't know where you got the arbitrary "99%" statistic from.
It's not like generics are some novel, marginal concept. It's 2014 already.
What really surprises me is that Apple didn't put any concurrency features into Swift. Having a language with better block/closure support will certainly help, but imagine what they could have done with some additional work. Would have loved to have seen some support for channels and tasks a la Rust/Go/etc.
Edit: personZ's comment above says what I wanted to say, much more clearly.
dispatch_apply(arr.length, queue) {index in
arr[index] = expensive_func(arr[index])
}
Obviously nice wrappers can be written around code like this to give you safe parallel programming. You could also quite easily make futures/async stuff.Almost all Go features exist in languages since the early 80's, outside the C family.
C/C++/Ruby/Javasscript/Python/Java/C# - all fail miserably, utterly and completely at concurrency. What Go accomplishes with channels, goroutines and the "select" statement has been an eye-opener for me.
Watching people struggle with threads/mutexes/shared memory in the 21st century, or with some half-baked library, is truly sad.
I'm really surprised that all Go features have been present since the 80's - It's strange I have utterly missed a feature as basic as concurrency in those! Very interesting.
Go's channels make use of CSP theory which had as first implementation Occam.
Occam? No comment. At least Ada is being actively used in something, but Modula-2 and Occam? Seriously?
You can find any idea currently in use that was probably first academically tested out and "proven" in "Obscure-language-nobody-ever-uses-anymore-on-any-real-projects".
The fact that Go, this supposedly boring, unoriginal language is actually taking off in popularity, is for some reason a huge pain point for certain people who refuse to acknowledge that the "plebs" who don't bow before Haskell or similar are allowed to program in something they enjoy and that brings something new to the table, for them. New for them. New for corporate America, new for real projects, new for actual people getting actual work done, on actual projects, in actual companies, getting paid actual money for it.
How did Go haters ever survive the rise of Ruby, for example? A language which brought absolutely nothing interesting to the table, yet after people experienced RoR became more popular, in one month, than Occam, CSP, Modula-2, Oberon, combined, times 1000? You guys must have been foaming at the mouth for years.
Occam? Modula-2? Jesus Christ.
You think Go's success is undeserved? I can't wait to see your reactions when Swift surpasses "My-favorite-obscure-language-X" in number of people/libraries/projects using it before the next WWDC.
Are you just trolling or simply act defensively?
Nobody said anything about it being found in languages that are in popular use today. What the parent said was that those features already existed in several languages.
That those languages also had to be "popular" is just a random restriction you added. In fact it has nothing to do with the origins of the features.
Oh, and Modula-2 and Occam are hardly some obscure, unknown languages (especially back in the day). In fact, they are some of the most well known and copied languages in PL history. Even Java copied a lot from Modula-2 itself, by its designers own admission. And Occam has inspired several modern lanaguages.
>How did Go haters ever survive the rise of Ruby, for example? A language which brought absolutely nothing interesting to the table, yet after people experienced RoR became more popular, in one month, than Occam, CSP, Modula-2, Oberon, combined, times 1000? You guys must have been foaming at the mouth for years.
Juvenile stuff. Moving along.
(Btw, CSP is not a language. It's a decades old mechanism for concurrency, the one Go itself uses -- and available in other modern languages too, including Clojure. Shows how much you know about those things).
You added "popular" now, to deflect from what he said: that those features already existed outside of Go. If a feature exists for 20+ years, having it in your language is not a sign that you "copied it" from a 5 year old language.
Not to mention that he also said "almost all" features, and was replying in the context that Swift copied Go. In that context Go's concurrency is irrelevant, since Swift doesn't have the same mechanisms.