5 ms·

Seems to me like the real challenge in those framework (excepting performance, of course) will be in the orm component. Having a library that can query a db in

by bsaul 11y ago

Seems to me like the real challenge in those framework (excepting performance, of course) will be in the orm component. Having a library that can query a db in a typesafe way is a must. Another will be in the concurrency patterns ( promises ? Coroutines ?, etc). But i get a great hope that they will succeed. Having a strong open source community will help. In fact, i'm so fed up with the sad state of uikit right now, that i see a brighter future for swift on the server side than on the client. Maybe an android sdk for swift would be a great idea...

protomyth 11y ago
I wish Apple had not ditched NeXT's EOF. It would make a fine open source project these days.
- AlphaSite 11y ago
  WebObjects was open sourced, was it not? (Although I don't know about the objective-c component).
  - protomyth 11y ago
    Not that I know of, nor the Objective-C EOF. They switched to Core Data which is not the same.
- bsaul 11y ago
  I never used this framework, but everything i know from the next era is starting to show its age (including coredata, with its messed up support for multi threading access). The more i think about it, the more i think golang approach is the right one : the only hard part today is concurrency. As long as swift ( and rust for that matter) hasn't standardized patterns that people would use on the whole stack for concurrent access to ressources,as well as asynchronicity, they won't have made the necessary step to truely advance the state of the art.
  - protomyth 11y ago
    > I never used this framework, but everything i know from the next era is starting to show its age (including coredata, with its messed up support for multi threading access). EOF is not Core Data and Core Data is not from the NeXT era.
  - seivan 11y ago
    GCD is the best I've seen in terms of language design for concurrency. It's also a bit higher level than managing threads on your own. Though I might be wrong.
    - bsaul 11y ago
      You probably should have a try at golang concurency management with channels, and you'll see what i mean. GCD isn't much more than a low level job launching and scheduling library. It doesn't provide advanced patterns for resource sharing. Concurrency goes further than parallelism, it's also a way to manage concurrent memory access (although golang does let you shoot yourself in the foot if you want to with low level mutexes as well). There's a great talk from rob pike on the subject http://blog.golang.org/concurrency-is-not-parallelism http://blog.golang.org/concurrency-is-not-parallelism
      - seivan 11y ago
        Thanks for explaining and clearing things up. I'll read up.
  - kibwen 11y ago
    Rust exists in a domain where one-size-fits-all approaches to concurrency just don't work and where asynchronicity is usually irrelevant. Meanwhile Rust's type system manages to statically prevent data races without requiring Erlang-style deep copying, which is an advance to the state of the art. :)
seivan 11y ago
I actually like GCD, so I hope concurrency doesn't make it to the language, or if it does tries to stay as close as it can to GCD api design.
JamoneK 11y ago
Have you heard of Zewo and SwiftAndroid?
supster 11y ago
https://github.com/tannernelson/fluent https://github.com/tannernelson/fluent
necolt 11y ago
Swift concurrency is interesting topic for sure, looks like language isn't actually built around concurrency unlike other popular new languages these days. Interesting document here about Swift concurrency https://github.com/apple/swift/blob/master/docs/proposals/Concurrency.rst https://github.com/apple/swift/blob/master/docs/proposals/Co...
- pjmlp 11y ago
  You mean like Erlang and Go? Everything else uses concurrency via libraries, which is the right way to do it, because there isn't a solution that fits everywhere.
  - necolt 11y ago
    Not everything else, Rust, OCalm just to name a few. Maybe it's just recent hype of such languages, but it definitely fits very well in some situations.
    - pjmlp 11y ago
      Both Rust and OCaml have library support for concurrency, it is not hardcoded in the language like Go.
kawsper 11y ago
I wonder if something like Realm.io will be adopted more widely https://realm.io/docs/swift/latest/ https://realm.io/docs/swift/latest/ They seem to have adoption in some bigger companies, but I don't know if any of them are using the Swift version yet.
- timanglade 11y ago
  Hey, Tim from Realm here. Last month, about 60% of our iOS users already used Swift, and the gap in favor of Swift is growing very quickly (it was 50/50 in November 2015). Some of our Swift users you’d probably expect: apps from Vimeo, Digg, Hipmunk or Misfit wearables. But in the past 1-2 months we’ve seen Swift + Realm apps from some real large companies like Cisco, the NFL, NBC Universal, GoDaddy and 7-Eleven. I hope this helps!
  - mathgeek 11y ago
    Very interesting stats. Thanks for sharing!
  - bsaul 11y ago
    I'd love to use realm, but for now i'm still hesitating. One reason is that you're using your own custom storage engine, and building a reliable one is hard. You should release some jespen-like testbench to prove how robust your technology is.
    - timanglade 11y ago
      I definitely agree that custom storage engines can be scary! In a way you could say the fact we’re used happily by so many applications on literally hundreds of millions of devices is a test of our reliability, although it’s far from being a formal test of course. We field the overwhelming majority of our issues in public on GitHub and StackOverflow, so you can see the kind of issues we have there. We have a bunch of internal testing on top of that of course, including our own device testing, test suites, and fuzz testing. We’re always up for recommendations on testbench for the kind of storage we do (Jepsen concerns itself only with distributed failure scenarios iirc, which doesn’t apply to us since we’re an embedded/centralized database engine by necessity). I don’t know if this helps or not, but I’m always happy to chat if there’s anything more you’d like to know about tim@realm.io
jowiar 11y ago
The challenge with any type safe language is interacting with the outside world -- internal consistency is easy, but figuring out how to mediate the non-typesafe outer world is always a bit of a fight. Slick is one swing at the typesafe ORM, but I'm not sure it gets it quite right. For concurrency, I'd be very intrigued if streams were the first-class concurrency approach -- It's been interesting working with Akka Streams in Scala. They make 90% of concurrency-related things easy and 10% of things seem to be fighting leaky abstractions, but I'd be curious if they were built into the language early on as primitives whether the leaks would go away.

by bsaul 11y ago

protomyth 11y ago

I wish Apple had not ditched NeXT's EOF. It would make a fine open source project these days.

AlphaSite 11y ago
WebObjects was open sourced, was it not? (Although I don't know about the objective-c component).
- protomyth 11y ago
  Not that I know of, nor the Objective-C EOF. They switched to Core Data which is not the same.
bsaul 11y ago
I never used this framework, but everything i know from the next era is starting to show its age (including coredata, with its messed up support for multi threading access). The more i think about it, the more i think golang approach is the right one : the only hard part today is concurrency. As long as swift ( and rust for that matter) hasn't standardized patterns that people would use on the whole stack for concurrent access to ressources,as well as asynchronicity, they won't have made the necessary step to truely advance the state of the art.
- protomyth 11y ago
  > I never used this framework, but everything i know from the next era is starting to show its age (including coredata, with its messed up support for multi threading access). EOF is not Core Data and Core Data is not from the NeXT era.
- seivan 11y ago
  GCD is the best I've seen in terms of language design for concurrency. It's also a bit higher level than managing threads on your own. Though I might be wrong.
  - bsaul 11y ago
    You probably should have a try at golang concurency management with channels, and you'll see what i mean. GCD isn't much more than a low level job launching and scheduling library. It doesn't provide advanced patterns for resource sharing. Concurrency goes further than parallelism, it's also a way to manage concurrent memory access (although golang does let you shoot yourself in the foot if you want to with low level mutexes as well). There's a great talk from rob pike on the subject http://blog.golang.org/concurrency-is-not-parallelism http://blog.golang.org/concurrency-is-not-parallelism
    - seivan 11y ago
      Thanks for explaining and clearing things up. I'll read up.
- kibwen 11y ago
  Rust exists in a domain where one-size-fits-all approaches to concurrency just don't work and where asynchronicity is usually irrelevant. Meanwhile Rust's type system manages to statically prevent data races without requiring Erlang-style deep copying, which is an advance to the state of the art. :)

seivan 11y ago

I actually like GCD, so I hope concurrency doesn't make it to the language, or if it does tries to stay as close as it can to GCD api design.

JamoneK 11y ago

Have you heard of Zewo and SwiftAndroid?

supster 11y ago

https://github.com/tannernelson/fluent https://github.com/tannernelson/fluent

necolt 11y ago

Swift concurrency is interesting topic for sure, looks like language isn't actually built around concurrency unlike other popular new languages these days. Interesting document here about Swift concurrency https://github.com/apple/swift/blob/master/docs/proposals/Concurrency.rst https://github.com/apple/swift/blob/master/docs/proposals/Co...

pjmlp 11y ago
You mean like Erlang and Go? Everything else uses concurrency via libraries, which is the right way to do it, because there isn't a solution that fits everywhere.
- necolt 11y ago
  Not everything else, Rust, OCalm just to name a few. Maybe it's just recent hype of such languages, but it definitely fits very well in some situations.
  - pjmlp 11y ago
    Both Rust and OCaml have library support for concurrency, it is not hardcoded in the language like Go.

kawsper 11y ago

I wonder if something like Realm.io will be adopted more widely https://realm.io/docs/swift/latest/ https://realm.io/docs/swift/latest/ They seem to have adoption in some bigger companies, but I don't know if any of them are using the Swift version yet.

timanglade 11y ago
Hey, Tim from Realm here. Last month, about 60% of our iOS users already used Swift, and the gap in favor of Swift is growing very quickly (it was 50/50 in November 2015). Some of our Swift users you’d probably expect: apps from Vimeo, Digg, Hipmunk or Misfit wearables. But in the past 1-2 months we’ve seen Swift + Realm apps from some real large companies like Cisco, the NFL, NBC Universal, GoDaddy and 7-Eleven. I hope this helps!
- mathgeek 11y ago
  Very interesting stats. Thanks for sharing!
- bsaul 11y ago
  I'd love to use realm, but for now i'm still hesitating. One reason is that you're using your own custom storage engine, and building a reliable one is hard. You should release some jespen-like testbench to prove how robust your technology is.
  - timanglade 11y ago
    I definitely agree that custom storage engines can be scary! In a way you could say the fact we’re used happily by so many applications on literally hundreds of millions of devices is a test of our reliability, although it’s far from being a formal test of course. We field the overwhelming majority of our issues in public on GitHub and StackOverflow, so you can see the kind of issues we have there. We have a bunch of internal testing on top of that of course, including our own device testing, test suites, and fuzz testing. We’re always up for recommendations on testbench for the kind of storage we do (Jepsen concerns itself only with distributed failure scenarios iirc, which doesn’t apply to us since we’re an embedded/centralized database engine by necessity). I don’t know if this helps or not, but I’m always happy to chat if there’s anything more you’d like to know about tim@realm.io

jowiar 11y ago

The challenge with any type safe language is interacting with the outside world -- internal consistency is easy, but figuring out how to mediate the non-typesafe outer world is always a bit of a fight. Slick is one swing at the typesafe ORM, but I'm not sure it gets it quite right. For concurrency, I'd be very intrigued if streams were the first-class concurrency approach -- It's been interesting working with Akka Streams in Scala. They make 90% of concurrency-related things easy and 10% of things seem to be fighting leaky abstractions, but I'd be curious if they were built into the language early on as primitives whether the leaks would go away.