12 ms·

Funny how he forgot to mention Golang somehow while that seems to be one of the bigger inspirations for the language.

kryptiskt 12y ago
That's a strange accusation, because Go is avowedly minimalist while Swift has cribbed most every thing from modern statically typed languages like ADTs, pattern matching, and generics.
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.
- 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.
pjmlp 12y ago
The language has nothing from Go. Almost all Go features exist in languages since the early 80's, outside the C family.
- PopsiclePete 12y ago
  Yeah? Interesting. Because all popular languages that I've used, up until Go, fail at concurrency at such a basic level, that it's almost as if their authors don't understand what concurrency is. Except Erlang. But then again, I said popular. 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.
  - axman6 12y ago
    Surprising, but nonetheless true.
  - pjmlp 12y ago
    Go's gouroutines trace back to the Modula-2 co-routines and Ada tasks, just to cite two possible examples. Go's channels make use of CSP theory which had as first implementation Occam.
    - PopsiclePete 12y ago
      Ah, Modula-2. Yes. Very popular in the corporate world; huge hit on Github/Bitbucket as well. Lots of libraries, web frameworks....up-and-comer, for sure. I hear we'll soon be writing iOS apps in it? 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.

That's a strange accusation, because Go is avowedly minimalist while Swift has cribbed most every thing from modern statically typed languages like ADTs, pattern matching, and generics.

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

pjmlp 12y ago

The language has nothing from Go. Almost all Go features exist in languages since the early 80's, outside the C family.

PopsiclePete 12y ago
Yeah? Interesting. Because all popular languages that I've used, up until Go, fail at concurrency at such a basic level, that it's almost as if their authors don't understand what concurrency is. Except Erlang. But then again, I said popular. 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.
- axman6 12y ago
  Surprising, but nonetheless true.
- pjmlp 12y ago
  Go's gouroutines trace back to the Modula-2 co-routines and Ada tasks, just to cite two possible examples. Go's channels make use of CSP theory which had as first implementation Occam.
  - PopsiclePete 12y ago
    Ah, Modula-2. Yes. Very popular in the corporate world; huge hit on Github/Bitbucket as well. Lots of libraries, web frameworks....up-and-comer, for sure. I hear we'll soon be writing iOS apps in it? 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.