What's a good way to develop a mental model about what's happening under the hood in EdgeDB?
With SQL, I have a mental model of how things work under the hood. For instance, I think of each table as being stored separately on disk, containing "rows". And the rows are really just equally-sized data blocks that are laid out back to back. B+ trees, with leaf nodes that point to (or just are) the rows, are used for indexes.
When I'm designing SQL schemas, I use this mental model to make guesses about performance. And when my queries are slow, I look at the execution plan.
My question is, how can I develop a similar intuition about EdgeDB? Under the hood, how are types and links stored in Postgres? And if I'm having performance issues, can I see an execution plan?
As for the former, I guess it is the same as however Postgres (pg) chooses to represent the edge-db tables. EdgeDB (graph on pg) sounds like Timescale (timeseries on pg [2]).
I'm wondering about the physical level—or at least how the EdgeDB conceptual level is translated to the Postgres conceptual level. The docs, and the comment you linked to, have helped me get pretty clear about the EdgeDB conceptual level.
I think what I'm trying to understand is this: if I use EdgeDB in production, how often will I end up dropping down to the SQL level to debug things? If I'm trying to debug a slow query, can I do it at the EdgeDB level? Or will I have to open a PostgreSQL terminal, see how things are laid out there, run EXPLAINs, check the slow query log, and so on?
When I use ORMs, the answer to this is "pretty often". The ORM makes my application code cleaner, but I still need to have a complete understanding of the underlying SQL representation in order to ensure good performance and debug errors. I'm curious how that compares to using EdgeDB.
The goal is to never drop down to SQL. If there's something you can express in SQL but can't express in EdgeQL, it's a bug.
We're working on proper query profiling now, but in the meantime the "slow query" problem you see with ORMs happens quite rarely with EdgeQL. For starters a lot of ORM performance issues are causes by the fact that they secretly do a bunch of roundtrips under the hood. EdgeQL queries compile to a single SQL query always. Also, since we target Postgres exclusively, we can produce queries that take full advantage of its (rather preposterous) power and performance. We extensively test the performance of things like extremely deep/wide fetching, lots of nested & complex filter expressions, computed properties, subqueries, polymorphics, etc. Obviously nothing is 100% but we're pretty confident in saying that EdgeQL performance is good.
In the sense that "object-relational mapping" is happening, then sure. The problem with the "ORM" term is that it comes loaded with a bunch of preconceptions that don't apply to EdgeDB. EdgeQL is a full query language with a standard library, grammar, and feature parity with SQL (almost). We've got a binary protocol. You use EdgeDB without ever needing to think about the layer beneath it—totally non-leaky. It's also not a library, which most people assume when you say "ORM".
Btw, if you folks have time, then EdgeDB should consider penning posts like the ones timescale has been doing for 3 years or so, in its march to industry leadership.
That's right, it's essentially sandboxing the scripts. But I think the real innovation is an automated system they've created for writing the sandboxing code based on tracing the execution of the malicious/ad scripts in the browser.
Otherwise, what you're saying would be true, and this could be easy to break/bypass.
Correct. I am a Canadian who recently traveled to Canada. I filled AriveCAN out at home, printed it out, and brought the printed receipt to the border.
With a traditional interview and job offer process, a new employee can ramp up without worrying their job is on the line. And I think this is important, because it can take awhile to ramp up to full productivity, which can be stressful if the new employee feels like they're being evaluated already.
Where I've worked, my new manager told me "Hey, welcome to the company. Please feel relaxed and take your time ramping up, you've already passed the interview and we're happy to have you here."
With your process, how do you deal with people getting stressed out during ramp up or feeling imposter syndrome?
Wouldn't people go from stages similar to culture shock?
1) Wow, very interesting company. I didn't know so many things can be done in different ways than I'm used to. Very smart ideas out there.
2) OMG, this company is full with idiots. Everything is done the wrong way but somehow it has not collapsed yet.
3) Yeah okay, some stuff is the way it is because it would't be feasible any other way due to the quirks of the business. Other things are the way it is because of historical reasons and it doesn't make sense to re-do it at the moment.
4) You know what, I think I understand what this company is all about. It's not perfect but people are actually doing great things here.
5) OMG, this business is crime against humanity. It shouldn't exist, I don't know how I'm supposed to do this anymore. Money can't buy me.
6) Well, the world is not perfect and I understand the imperfections and I can function. It's not like they are doing it any better anywhere else. I grew to appreciate upper management, now I understand our business and I'm happy to do my part.
3 months should be enough for a nice honeymoon stage. Both sides can know that longterm relationship is achievable if they have a nice honeymoon stage.
If you are a semi-experienced software engineer and haven't been deliberately lying during your interview, you shouldn't really worry about getting fired.
In a few weeks I'll have finished my second internship at Microsoft (working on Kinect for Xbox One).
I have experience (both full-time and contracting) doing web development, computer vision, and indie game development, and will be looking for contract work this fall for these areas:
I fully support this trend of people thinking critically about college and making their own decisions about it.
However be careful when dropping out if you'll ever want to work outside the country. Most countries require a 4 year degree for work visas, and this can sometimes be onerous to get around. This is especially important for those who don't have US citizenship.
There's another github link (https://github.com/oreilly-japan/deep-learning-from-scratch-...) with the code for all 60 steps, but not the explanatory text.