

I am jealous of Swift - mpweiher
http://blog.metaobject.com/2015/05/i-am-jealous-of-swift.html

======
bontoJR
Disclaimer: I have a relative good experience in Scala.

Let's see how I can formulate my thoughts about Swift without say something
that can be considered trivial.

I think Swift can be basically resumed with this quote:

> Crucially, the vast majority of this is incidental complexity, not essential
> complexity.

I love Swift, I think is a good language, but is far away from perfection.
Sometimes I feel that is half-baked compared to languages like Scala. I can
understand the complexity and the obstacles that are part of a development of
a new programming language, but some things are really messy.

I truly hate these 3 factors:

> enum cases act like functions, but are not functions.

> Properties act like functions, but are not functions.

> Initializers act like functions, but are not functions.

Plus the fact the language is not homoiconic freaks me out, sometimes.

I like Swift because constantly challenges my skills as engineer, I have to
find workarounds to apply all the concepts I know about functional
programming, but... this is the current feeling, I don't know if in a long run
this would persist, I can't image to fight against the language like I have to
do sometimes, would make me still happy in 2-3 years, maybe some day I would
get tired.

I like Swift, there's a lot to do to jump from a good language, to an awesome
language, but now we are still far away from that.

------
coldtea
> _Swift is a crescendo of special cases stopping just short of the general._

Yeah, a.k.a pragmatic. It's no Scheme and no Smalltalk.

Golang, which others like, is also a huge pool of "because I say so" and
special-cases (make, ranges etc), but its restrictive and simplistic to boot.

At least Swift is firing in all pistons...

~~~
lerno
I would say that it is volatile mix of very non-pragmatic constructs and lots
of real constraints that creates the problem. If you want to see how to build
a pragmatic language - look at JAI.

------
roop

        > ... we learn that debug builds are often 100 times slower
        > than optimized builds (which themselves don't really
        > rival C).
    
        > Sorry, that's not the sign of a language that's 
        > "designed to be fast".
    

Doesn't this just mean the the language was "designed to be fast", but to be
fast only in release mode, and not in debug mode as well?

~~~
lerno
To have fast compiles be within x2 (or thereabouts) of optimized build is very
important for plain productivity reasons. Therefore it's a very valid concern.

~~~
roop
For the kind of applications that Swift is intended for now (i.e. iOS / Mac
apps), debug-mode runtime doesn't affect productivity very much as long as
runtimes are fast enough to respond to UI events. It might affect automated
testing times, but not productivity directly.

So, for that particular use-case, debug-mode being within 2x of release-mode
build is not a valid concern.

What would affect productivity for this kind of use-case is build times.
(Swift isn't great here either.)

------
aclissold
If they're designing a language for the next 20 years, should they have
designed in Objective-C compatibility more tightly? Isn't "afterthought"
exactly how it should feel if they plan to remove it someday?

------
_random_
They were desperate to release something ASAP. The enemy is at the gates.

