Hacker News Reader

Comment by bsaul | Hacker News Reader

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...

View on HN

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.

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/Co...

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.

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.

Both Rust and OCaml have library support for concurrency, it is not hardcoded in the language like Go.

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.

I wonder if something like Realm.io will be adopted more widely 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.

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!

Very interesting stats. Thanks for sharing!

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.

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

One talk that really made me confident in using a new DB technology was this one :

https://www.youtube.com/watch?v=4fFDFbi3toc&feature=youtu.be...

Maybe you could make videos and talks about your testing procedures. That would probably help build trust.

nb : you're not distributed, but you're enabling multi-threaded access, in an environment where your app can be killed anytime by the OS. That's quite hostile as well :)

Have you heard of Zewo and SwiftAndroid?

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

WebObjects was open sourced, was it not? (Although I don't know about the objective-c component).

Not that I know of, nor the Objective-C EOF. They switched to Core Data which is not the same.

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.

> 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.

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.

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

Thanks for explaining and clearing things up. I'll read up.

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. :)

Reply on news.ycombinator.com