[devsquid]

Its not about performance, its about keeping the language simple. As someone who writes in Go, I really find this an attractive feature. I learned it in a few days, which is pretty fantastic IMO. Although I'm not sold on the Go shouldn't have generics argument, it does seem like Go has more pressing issues than implementing generics tho. Like bring the compile time back down to near instant instead of 300ms. lol

Also Swift's compiled code does not get near the same performance as Go's compiled code. Even when you unsafely compile Swift's code, it doesn't get near. When you start embedding C function calls into Swift and turning off Swift's safety features then it has been shown to get near Go.

[mpartel]

I agree that systems and libraries you don't deal with every day should strive for simplicity and learnability, but I think simplicity is a much lesser virtue in programming languages.

A programming language is something you use every day, so you'll inevitably invest time in learning it properly. A language you can learn completely in a few days is unlikely to give you as much power, convenience and maintainability as a more complex language. Choosing Go might get you and your team started faster, but wastes a lot of potential over time.

(Of course complexity on its own is not a good thing, some complex features may be prone to abuse, orthogonality is still important etc., but Go is way too conservative to be competitive long-term I think.)

[echaozh]

To be simple is wrong, what is needed is to be minimal and to the point. Most of the time, the minimal tool is simple enough, but sometimes complexity is a necessary evil.

Driving a car is more complicated than running. Why do we invent cars in the first place?

[pcwalton]

> Also Swift's compiled code does not get near the same performance as Go's compiled code. Even when you unsafely compile Swift's code, it doesn't get near.

Do you have a source for this?

Swift had the long term in mind anyway. The effort to create SIL, along with the industrial-strength LLVM pipeline, has led to a rock-solid foundation. It's hard to compete with a backend that has 4 separate IRs, each with its own suite of optimization passes, including hundreds of algebraic simplifications, a highly tuned register allocator, an instruction scheduling pipeline, and an autovectorizer, just to scratch the surface. The stage is set for an excellent compiler architecture, even if they're not there today.

[devsquid]

Heres from a quick Google

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

You can see like most Swift benchmarks, its compiling with the -Ounchecked flag and using C.

-edit- I have no doubts of LLVM's capabilities. It just seems like Swift is probably already taking advantage of its optimizations.

[alblue]

One surprising performance issue with Swift was identified (and fixed) by IBM recently:

https://github.com/apple/swift/commit/259d57bbe7784955108caa...

The problem was that the print operations was being done character-by-character and it resulted in the printing being a significant overhead in the execution of the tests themselves. With this change they saw a speed up of many times simply because it was using buffered output.

[pcwalton]

> It just seems like Swift is probably already taking advantage of its optimizations.

The Go compiler performs nowhere near the level of optimization that LLVM does; LLVM is years and years ahead. However, LLVM is fundamentally a C compiler and so there can be impedance mismatch between Swift and LLVM. Hence SIL. This is what you're seeing, and once the gap is closed then Swift will reap the benefits of the hundreds of optimizations in LLVM.

[igouy]

You did say "Even when you unsafely compile Swift's code, it doesn't get near." ;-)

fannkuch-redux looks near, mandelbrot looks near, n-body…

Swift is new to Linux; there's a new compiler snapshot about every 10 days. Swift has only been available on the benchmarks game 3 months for people to contribute programs. Early days :-)

[TheHydroImpulse]

Generics do not have to be complex and they allow abstractions that simplify your code.

Please explain how .map, .filter, .reduce, .pmap are complex?

Swift is also built with LLVM, a backend that is far superior to Go's handmade one. I doubt the performance issues will persist long-term.

[iofj]

There is a large cohort of programmers that don't understand map/filter/reduce. They love Go (and C) for not allowing it and forcing everyone to think purely imperatively.

Go makes it an enormous effort to make something complex. You can do it, but you'll be typing a LOT. I think this is a disadvantage from both a writing and reading code perspective, but the Go mailinglists keep on repeating how it's a huge advantage. I may see a small advantage if you're trying to prevent simple programs from turning complex, but if you're trying to do complex things Go simply makes you suffer.

Writing out map/filter/reduce code invariably leads to 10-15 lines and 2-3 functions per map call, and more for reduce. You'll constantly be reading a lot of text and reducing it back to the map/filter logic in your head. Meanwhile there are a lot of things you need to remember.

I don't like it either. Things that are a 2-3 line map/list comprehensions in python and haskell are 2-3 files with 100 lines each in Go. And God help whoever needs to have map/filter working on things that come in over channels, then the complexity truly goes through the roof.

(for C: yes macros can "fix" this. If you don't mind horrible code)