Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift Programming Language Evolution

github.com

Post reply on HN
Print view View original

141–150 of 181 posts

Re: Swift Programming Language Evolution

#141

Post by Matthias247 »

twoodfin wrote: post #79

To me, the most interesting empirical result of the Swift language evolution so far is the lack of urgency on language-level concurrency. If they think they can be competitive for years (at the very least vs. Objective-C) with only platform-level concurrency support, it makes me wonder whether concurrency is generally better provided by the platform instead of the language for most needs. Conventional wisdom would ha…

I think whether to deeply integrate concurrency into a framework or not is quite an interesting tradeoff. Without a preferred concurrency solution (like Swift, C++, Java, ...) users of the language are can leverage from a lot of different concurrency solutions, from real threads to eventloops/Rx and everything in between. However I think in the meantime that this hurts the ecosystem around the language. When some libraries built around primitive 1 (which might require an eventloop or async/await) and others around primitive 2 (M:N scheduled fibers) these libraries might not be easily combinable in your application. Languages with a preset solution (like Go or Erlang) avoid this problem.

Re: Swift Programming Language Evolution

#142

Post by b123400 »

While the language is nice, I find it hard to work with existing frameworks, given they are designed for a language as dynamic as objective-c. For example, NSError, NSNotification's userInfo is a `[AnyObject:AnyObject]`, but its member types are specified in documentation. It would be nice if we can have specific error will typed userInfo. Working with storyboard is the same story, there is no type check for VC and segue because identifier is a string, instead of something like `R.id.view` on android. Working with this kind of API requires lots of casting, I wonder will Apple design Swift-centric API later.

Re: Swift Programming Language Evolution

#143

Post by [deleted] »

Razengan wrote: post #130
jaegerpicker wrote: post #98

Earlier quoted context omitted.

Sorry was generalizing. I meant generics and protocols in combination. The ability to define a protocol based on a generic would be fantastic. It's something that is solved in Haskell fairly well.

Isn't that somewhat possible with extensions and constraints? At least that was the impression given by last year's WWDC talk [1], unless you're thinking of something else? [1]: https://developer.apple.com/videos/play/wwdc2015/408/

[deleted]

Re: Swift Programming Language Evolution

#144

Post by dang »

sickbeard wrote: post #43

Don't compare objective-c to c/c++. Objective-c is a different level of retard.

You've been posting quite a few unsubstantive comments to HN. Please don't do that. We're looking for civil, thoughtful discussion here.

https://news.ycombinator.com/newsguidelines.html

https://news.ycombinator.com/newswelcome.html

We detached this subthread from https://news.ycombinator.com/item?id=11660700 and marked it off-topic.

Re: Swift Programming Language Evolution

#145

Post by rsmoz »

b123400 wrote: post #142

While the language is nice, I find it hard to work with existing frameworks, given they are designed for a language as dynamic as objective-c. For example, NSError, NSNotification's userInfo is a `[AnyObject:AnyObject]`, but its member types are specified in documentation. It would be nice if we can have specific error will typed userInfo. Working with storyboard is the same story, there is no type check for VC and s…

Apple has already done a lot to make this sort of thing nicer. They added lightweight generics to Objective-C, so arrays are typed now. NSError bridges to ErrorType. They've also announced further plans to Swift-ify existing Objective-C APIs.

Re: Swift Programming Language Evolution

#146

Post by mahyarm »

kris-s wrote: post #8
Someone1234 wrote: post #2

So Swift has been out awhile, what do people think of it? What other language would you compare it to (e.g. C#, C, C++, etc)? What about the libraries are they well laid out?

My favorite thing about Swift is that is seems to get out of the way - and when it gets in the way it's usually with a nifty language feature (like the { $0 + $1 } closure syntax). I'm very excited for the future - between Go and Swift we now have two compiled fast languages that are almost as expressive as their slower dynamic/interpreted cousins. As an aside, I like that Apple is betting the farm on ARC. I wish I c…

Go is about as fast as java is with a lower memory requirement although.

Re: Swift Programming Language Evolution

#147

Post by lobster_johnson »

twoodfin wrote: post #79

To me, the most interesting empirical result of the Swift language evolution so far is the lack of urgency on language-level concurrency. If they think they can be competitive for years (at the very least vs. Objective-C) with only platform-level concurrency support, it makes me wonder whether concurrency is generally better provided by the platform instead of the language for most needs. Conventional wisdom would ha…

Go (which I think you're alluding to) has language-level concurrency because its syntax is extremely rigid. Swift's syntax is flexible enough that this isn't needed.

Specifically:

* Support for annotations; the compiler/runtime can be informed about safety and marshaling concerns. * Anonymous function bodies. You can implement Go's "go func() { ... }()" pattern yourself, and a concurrency runtime can implement it. Rust uses the exact same pattern. * Generic iterators/streams. No need for channels as language primitive since you can write a generic channel implementation.

Go is nice, but its language-level concurrency is very much a side-effect of its intentionally impoverished type system. For example, the built-in "chan" type exists because otherwise a generic channel implementation would have to use interface{}, which is not type-safe and would be hell to work with.

Here's what's lining up to become Swift 4.0's concurrency support (all the concurrency models!): https://github.com/apple/swift/blob/master/docs/proposals/Co....

Re: Swift Programming Language Evolution

#149

Post by chrisamanse »

RotsiserMho wrote: post #35
supster wrote: post #6

Earlier quoted context omitted.

I'm a big fan. I love the statically inferred type system, generics, & optionals. Also really like a lot of the functional programming concepts + value types but still enjoy being able to fall back on OOP. It feels like the best of both worlds. I can't wait till we have language native concurrency techniques, so I can start writing swift in backend code.

I was disappointed to see that concurrency support won't be in Swift 3.0.

Concurrency is done with libdispatch library, which is also open source. Right now, it's only compatible with OS X, but int their post, they said that "For Linux, Swift 3 will also be the first release to contain the Swift Core Libraries."

https://swift.org/blog/swift-3-0-release-process/

Re: Swift Programming Language Evolution

#150

Post by bluecalm »

riyadparvez wrote: post #114
DonFromWyoming wrote: post #26

The removal of prefix and postfix ++ and -- operators and the removal of C-style for loops are mistakes, IMO.

> prefix and postfix ++ and -- operators IMHO, these operators are the worst features of C. Particularly I never understand the necessity of both i++ and ++i operators in language at the same time.

It's to make code more concise. There are many idiomatic one liners to compare arrays for example or to find the first element which satisfies the condition etc.

I don't mind removing them but their usecase is obvious: make the code more concise and more readable (and yes, if you program in C on daily basis you don't require a double take or thinking about what ++ does).

Post reply on HN