Hacker News Reader

Comment by necubi | Hacker News Reader

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.

View on HN

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.

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.

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.

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

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.

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

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.

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"

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.

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.

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.

I've been seeing much the same from programmers invested in the Apple ecosystem who will likely be spending all day writing nothing but Swift within a year.

Lots of people are having a hard time understanding the difference between dynamic typing and static typing with type inference.

Definitely. I suppose it's understandable if this is your first exposure to type inference. Superficially it looks exactly like the "assign anything to anything" languages like Python or JavaScript.

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.

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.

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.

Genuine question: what does Go provide in terms of concurrency that Swift + GCD doesn't?

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.

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.

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

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 think it's quite a stretch to say that people who have written articles about generics

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.

People don't write articles discussing how their whole complex project works because it would take too long. those articles are written to highlight what and how these features have improved their ability to make software efficiently/reduce errors etc.

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.

Well, I have written big projects in other languages, and I wouldn't go back to a language without generics.

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.

Apple already has GCD/libdispatch, and is presumably content to continue handling this with libraries, at least for now. Concurrency's certainly important, but I don't think it's entirely clear yet that _language level support_ for it is.

Reply on news.ycombinator.com