Interesting to hear your view on Storyboards. I know what many developers agree with you althought I have never really understood why :) Good that it works for you. And thanks for sharing your thoughts on the article!

Thanks for your reply! I don't agree that concurrency is a mess with Core Data, it has good support for this. Of course you need to be careful to get things right, but this goes for whichever technology you are using. As for upgrading the app, if you are doing anything else than a lightweight migration you need to know what you are doing, but that problem doesn't at all go away if you roll your own database layer. I believe Core Data is actually of great help in solving those pretty complex problems.

The whole managed object context paradigm is clunky. It's meant to be a system of nestable sandboxes for performing discardable operations on the database, but when you start to mix concurrency inside, it becomes intractable.

Reading the documentation on concurrency and managedobject context would make any people's eyes go blank (https://developer.apple.com/reference/coredata/nsmanagedobje...).

IMHO, i don't think that 80% of the people using core data understand the concept of managed object context properly. For example, i'm pretty sure everyone wonders what's going on when they try to reuse an object from a context in another and get weird behaviors.

My main point isn't that one should recode a database manually, but that it's extremely rare to need that kind of system in a mobile app in the first place.

Also i think that performing a set of sql query in an sqlite database is much much simpler than creating a correct process for a core data model migration.

Appreciate your thoughts on this! Core Data is far from trivial but can also be incredibly powerful. I actually think a lot of apps can benefit from the persistence and advanced notification system it offers.

Seems very handy! Thank you

Haha, okay. Yes, I just really like the name since it originates from an email sent from one of the project managers at our office: "Don't worry. We can handle both XML and Jason".

Thanks for your feedback. I created the library simply because it just fits my use cases better. I have used encoding/json quite a lot, and for instance, I think golang's strict types makes it inconvenient to dig through arbitrary maps in a quick way.

That's what the Get-method in Jason is trying to solve. Similar to how bitly/go-simplejson does it, but with some fine tuning.

Speaking of the .Get method, wouldn't returning an error alongside the value instead of just the default object be more idiomatic?

I think it would be nice to return a bool, rather than an error. It really is just a binary condition and this pattern fits nicely with accessing values in maps. That said, I haven't really found a need for a .Get method in my own code, and will probably just stick with encoding/json for the time being.

It looks like .Get uses the null pattern (ie, returns a Jason struct with data = `nil` if nothing is found). Your way is more idiomatic, but it looks like his point with this library is to access the data conveniently in exchange for type-safety. `exists()` can verify something was found if needed.