EdgeDB is looking like a dream db (with batteries included) to me, congrats on the launch!
I wonder if you might wanna join efforts on building your cloud offer with guys at https://neon.tech/ (i'm not affiliated, but I'm waiting for your cloud offering)
We'll be closely looking an Neon and we know the team. There are some related things that we have to figure out before investing time into the integration.
The primary driver here is moving from a hosting company to a workflow/developer productivity company. If you're using ZEIT for staging/test deployment previews or hosting SSG or hybrid SSR/SSG Next.js it all pencils out nicely. It definitely doesn't work for the original container-first model.
any chances you and your team are working on a GraphQL access layer for the Firestore?
It feels like nested queries(using refs for relations), basic mutations and (especially) graphql subscriptions would be a great match with Firestore and a big improvement in dev experience, imho.
I have created a GraphQL layer over the top of Firebase and while it was pretty easy to do so using Cloud Functions, I agree that it would be great if Firebase offered this out of the box without needing to do all of the work you currently have to, to use it.
I was(am? will be again?) a fan of Elm. Constraints can be helpful and even liberating(in some sense). But that's something that should be balanced carefully with other things, like rules\laws that are clear, universal and follow the common sense.
Unfortunately, during my Elm journey, I've found that's not the case for Elm.
> Freedom is the rope with which I can hang myself.
If you'd like to, why not? It's up to you. You're not forced to do, though.
On the other side, being a hostage of some secret plans in "people in power" minds, you might be forced to do any kind of staff. New constraints are here and they're enforced on anyone. That's a catch with constraints, you can be OK with existing, but you'll never know what comes tomorrow.
> If you'd like to, why not? It's up to you. You're not forced to do, though.
Well, yeah. If I'd like to hang myself, I'd pick a technology with fewer correctness guarantees. As it turns out, that's not what I want. This is self-evident.
It's also not a valid criticism for you to say that you've found Elm doesn't "follow the common sense". This is too vague to be any kind of constructive criticism.
> Well, yeah. If I'd like to hang myself, I'd pick a technology with fewer correctness guarantees. As it turns out, that's not what I want. This is self-evident.
That's exactly what I'm talking about. I'd also like to pick up some "silver bullet", like Elm(if I got you right), for any new project.
Unfortunately, real world is usually a little bit more complicated than "I'm free to pick up any technology that I want. All browsers are the same, their behavior is consistent, mobile web is pure joy and all of our users know their plugins might cause an issue to our app, therefore they're disabling them when they launch our app".
Anybody who does webdev knows that. Different projects, different requirements(sometimes very, very strange), brand new requirements right before the release, deadlines, etc. There're lots of things you have to deal with to end up with a good website\app. Picking a language with nice "correctness guarantees", is not going to help you much.
There were times, long time before 0.19, when there were at least discussions on effect managers, extending the type system, native modules were a nice escape hatch to fix your problem at hand with nasty browser bug or even Elm runtime issue. Those were times when I was so excited to use Elm, did some tiny (sub)projects in it, did a workshop at the office.
Since then, many things have changed to the worse, imho. Some features were removed, not even deprecated. No public discussions, no roadmap, no bugfix releases, no escape hatches for special cases. But who cares what some random guy on the internets thinks :)
Don't get me wrong, I think Elm is a great experiment in the land of static languages, lots of great stuff is getting into mainstream languages(like Elm architecture, error msgs). I still hope we'll see the 1.0 version and things might get better in terms of feature stability, feedback and building things a little bit more complex than counter apps without hitting even more pain points than we have with modern JS\TS.
My 2014 15" MBP is mostly fine, however it needs some cleaning and anti-reflective coating issue has become really annoying lately.
2015 vs 2016 was hard since there's so little feedback from actual users(power\professional ones) and this post is really helpful. I haven't heard anything more annoying(to my ears) than this new keyboard.
Still buying smth 1.5 years old(instead of 2.5 y.o.) not to satisfy your expectations, just to meet your needs(old ones, but with no stain issues)... Is it the world that "pro"+"mobile" Apple users should live from now on? :\
I can. Many friends have left during last year or so.
Not sure if this is the only reason, mostly it's just a wish to find a better place to live and raise kids.
I wonder if you might wanna join efforts on building your cloud offer with guys at https://neon.tech/ (i'm not affiliated, but I'm waiting for your cloud offering)