3 ms·
I'm actually pretty happy swift moves the server side story forward, because i'm convinced the "next big language" will have to run on mobile and server. Actual
by bsaul 9y ago
I'm actually pretty happy swift moves the server side story forward, because i'm convinced the "next big language" will have to run on mobile and server. Actually, i think they don't go fast enough, especially regarding concurrency ( which on the server goes beyond just providing async await, as lattner said they were aiming at something closer to the actor model).
I don't think the "maybe objc is still relevant for new project" trend we've been seeing the last few months on HN is going anywhere. I'm currently in the process of converting a large codebase from objc to swift, and there is absolutely no doubt that the language is WAY better, and brings a lot of safety enhancements as well.
The only big remaining pain point now is clearly in the tooling, but now that they're stabilized the language a bit more, it's probably going to get better fast.
- andybak 9y ago> because i'm convinced the "next big language" will have to run on mobile and server Wouldn't it also need to be cross-platform in that case? It's sad that Kotlin and Swift are so similar but not similar enough. (Although I'd prefer a dynamic language to be the "next big language" - it seems the pendulum is currently swinging back towards static typing...)
- jnbiche 9y ago> Wouldn't it also need to be cross-platform in that case? Swift is absolutely cross-platform. I've used it a lot on Linux. I think I even prefer it to Rust for things like server applications. I think Swift may even be available on Windows now. But it's definitely available and rapidly maturing on Linux. And having struggled with large code bases in dynamic languages for years, I'm very happy that statically-typed languages are resurgent now.
- valuearb 9y agoI would like to see Swift for WebAssembly
- ngrilly 9y ago> which on the server goes beyond just providing async await, as lattner said they were aiming at something closer to the actor model I'd be interested in further information about this, if you can share some link here.
- Someone 9y agohttp://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf http://researcher.watson.ibm.com/researcher/files/us-lmandel..., page 52: "Async/await are effectively proven at this point and would fit well with the Swift type system and structure, we should probably just do it. Erlang/Akka have proven actor models. Swift providing syntax yields a declarative model which enables programmers to reason about what mutable state goes with each task. Each actor is effectively a DispatchQueue + state it manages + operations that act on it. Actor approach also generalizes well to future. It could be a great way for handling heterogenous compute (e.g. GPU tasks), distributed compute, etc since each async “call” to an actor really is a message send (thus could be DMA or IPC)." I don't think a video of that talk is available online. https://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=6940 https://researcher.watson.ibm.com/researcher/view_group_subp... doesn't mention it.
- tootie 9y agoI'm not a fan of Apple but I think I'd rather work with isomorphic Swift than JavaScript.
- tootie 9y agoI'm not a fan of Apple but I think I'd rather work with isomorphic Swift than JavaScript.