7 ms·

I don't understand why people keep comparing Swift and Go, as they have diametrically opposed philosophies. As stated succinctly by Bryan O'Sullivan (one of the

by necubi 12y ago

I don't understand why people keep comparing Swift and Go, as they have diametrically opposed philosophies. As stated succinctly by Bryan O'Sullivan (one of the most prominent people in the Haskell community) on Twitter: "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.

pjmlp 12y ago
Lack of CS knowledge I guess, specially in programming language history. They see things like func, and think Go was the first language to come up with it, when many others already had it.
craigyk 12y ago
well in Swift I think concurrency is expected to rely on system libraries whereas in Go they are built-in and even have special syntax. If Swift ever gets a good macro system, though, I'm guessing one could create nice syntax to use system concurrency libraries.
melito 12y ago
I think it's because Swift is so new only a small percentage of people have actually looked at the language spec. 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
- mikeash 12y ago
  It's bizarre how focused programmers are on syntax. 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.
  - nostrademons 12y ago
    Wadler's Law: "In any language design, the total time spent discussing a feature in this list is proportional to two raised to the power of its position: 0. Semantics 1. Syntax 2. Lexical syntax 3. Lexical syntax of comments"
    - axman6 12y ago
      Speaking of which, I was quite pleased to see the inclusion of nested comments. Makes getting rid of currently incorrect code during development much easier.
  - deleted 12y ago
    [deleted]
  - melito 12y ago
    No different from learning a human language I think. 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.
  - jfb 12y ago
    Most of the commenting on a new language, particularly here (as opposed to on e.g. Lambda The Ultimate) is from people who aren't going to write a single line in it in anger; it's not surprising that idle commentary would focus on syntax. It's of a piece with all internet commentary, which rarely gets below the outermost layer of thinking about anything.
    - mikeash 12y ago
personZ 12y ago
The only really innovative parts of Go are its concurrency support, which Swift seems to be completely lacking. 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.
- coob 12y ago
  Genuine question: what does Go provide in terms of concurrency that Swift + GCD doesn't?
  - Glide 12y ago
    I would argue that Go has it more "baked in." 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.
  - andybalholm 12y ago
    Go provides straight-ahead, blocking-is-OK concurrency. GCD provides callback-based concurrency, like node.js, but with several worker threads instead of just one.
- 12y ago
Shebanator 12y ago
As kryptiskt mentions in a separate comment below, its not that go's designers ignored language research. Rather, its that they took a decidedly minimalistic approach to language features. 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.
- Jtsummers 12y ago
  Apple has Grand Central Dispatch. It seems that Swift plays well with it, and I won't be surprised if more concurrency-model-as-library stuffs pop up in the future. It's a sound approach and avoids tying the language itself to any singular model.
  - axman6 12y ago
    If you see my comment above [1] I've got an example of just how nicely GCD/libdispatch works with Swift. It's quite exciting really. [1] https://news.ycombinator.com/item?id=7844219 https://news.ycombinator.com/item?id=7844219
    - Shebanator 12y ago
      Thanks for the link. When I mentioned "better block/closure support will certainly help" this is what I was referring to, but its nice to see an example. But some in-language support could have made things a lot nicer still, and I find it odd that as a "modern" language that they omitted it.
axman6 12y ago
The concurrency problem was partially and briefly covered in the Platforms state of the Union keynote. Since closures in Swift are compatible with Apple's C blocks extension, all of the libdispatch API works with it out of the box. and the last-argument-is-a-closure syntax from Ruby makes it really nice: 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.

by necubi 12y ago

pjmlp 12y ago

Lack of CS knowledge I guess, specially in programming language history. They see things like func, and think Go was the first language to come up with it, when many others already had it.

craigyk 12y ago

well in Swift I think concurrency is expected to rely on system libraries whereas in Go they are built-in and even have special syntax. If Swift ever gets a good macro system, though, I'm guessing one could create nice syntax to use system concurrency libraries.

melito 12y ago

I think it's because Swift is so new only a small percentage of people have actually looked at the language spec. 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

mikeash 12y ago
It's bizarre how focused programmers are on syntax. 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.
- nostrademons 12y ago
  Wadler's Law: "In any language design, the total time spent discussing a feature in this list is proportional to two raised to the power of its position: 0. Semantics 1. Syntax 2. Lexical syntax 3. Lexical syntax of comments"
  - axman6 12y ago
    Speaking of which, I was quite pleased to see the inclusion of nested comments. Makes getting rid of currently incorrect code during development much easier.
- deleted 12y ago
  [deleted]
- melito 12y ago
  No different from learning a human language I think. 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.
- jfb 12y ago
  Most of the commenting on a new language, particularly here (as opposed to on e.g. Lambda The Ultimate) is from people who aren't going to write a single line in it in anger; it's not surprising that idle commentary would focus on syntax. It's of a piece with all internet commentary, which rarely gets below the outermost layer of thinking about anything.
  - mikeash 12y ago

personZ 12y ago

The only really innovative parts of Go are its concurrency support, which Swift seems to be completely lacking. 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.

coob 12y ago
Genuine question: what does Go provide in terms of concurrency that Swift + GCD doesn't?
- Glide 12y ago
  I would argue that Go has it more "baked in." 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.
- andybalholm 12y ago
  Go provides straight-ahead, blocking-is-OK concurrency. GCD provides callback-based concurrency, like node.js, but with several worker threads instead of just one.
12y ago

Shebanator 12y ago

As kryptiskt mentions in a separate comment below, its not that go's designers ignored language research. Rather, its that they took a decidedly minimalistic approach to language features. 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.

Jtsummers 12y ago
Apple has Grand Central Dispatch. It seems that Swift plays well with it, and I won't be surprised if more concurrency-model-as-library stuffs pop up in the future. It's a sound approach and avoids tying the language itself to any singular model.
- axman6 12y ago
  If you see my comment above [1] I've got an example of just how nicely GCD/libdispatch works with Swift. It's quite exciting really. [1] https://news.ycombinator.com/item?id=7844219 https://news.ycombinator.com/item?id=7844219
  - Shebanator 12y ago
    Thanks for the link. When I mentioned "better block/closure support will certainly help" this is what I was referring to, but its nice to see an example. But some in-language support could have made things a lot nicer still, and I find it odd that as a "modern" language that they omitted it.

axman6 12y ago

The concurrency problem was partially and briefly covered in the Platforms state of the Union keynote. Since closures in Swift are compatible with Apple's C blocks extension, all of the libdispatch API works with it out of the box. and the last-argument-is-a-closure syntax from Ruby makes it really nice: 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.