As a user, one thing that would be really golden down the line would be to have a whole “rust book” for the ins and outs of databases, using surreal as the tool. I know the basics of databases and the ideas behind local vs cloud and scaling and so on but I’m enough of a noob that I have no idea which option to use when kind of. There are so many little concepts that probably are so obvious for database developers who have a few years of work life experience that are quite enigmatic for juniors. Especially for people without a CS background. Anyway, great talk and very cool project!
Wow I looked at this year's ago and was super impressed, at the time I was even think this would have been better in rust. Now I find you again just as I need an embedded dB in my rust app. Woohoo I'm excited
Dont want to sound too negative, but this seemed to me more like a sales pitch. I'd be much more interested in the technical details. When he did mention some, I got a bit concerned though. When he described the parsing of SurrealQL, I was wondering about performance, and if the resulting grammar can be parsed efficiently at all. Also, comparing async to threading seemed super weird, since these concepts are orthagonal.
1. It was definitely a high level overview with mostly highlights rather than details. More of a story of moving to rust and so on. But a bit of code showcase and name dropping of some relevant crates. 2. About the syntax, it would be interesting to see benchmarks. I’m not familiar with the crate used to do the parsing or how it handles this syntax. Even if the parsing looked very self descriptive, that piece of code made some heavy use of rust macros (apparent from “function calls” where the names end with “!”). So that code might be doing something slightly fancier under the hood. Was there anything in particular about the grammar of SurrealQL that pops out as being slow to parse, compared to equivalent join statements in other query languages? I think relations of the form A->B->C work by defining a separate table called B with entries “in=a” and “out=b” and then the select-queries using the same notation are essentially running joins. There may be more magic to it, I’ve only played with surreal for an evening or two. What are your thoughts? 3. Async/threading. I think he just mentioned general features of rust and that there are good options for using different kind of concurrency models. And if it makes sense you can leverage several of them in the same application. Or you can just pick the one that suits your needs. I don’t think he was being more specific than that, but I could be wrong.
@@HyperFocusMarshmallow Nothing I saw poped out per se, but he mentioned that the query language did not have any keywords. As he described it, it seemed to me like the parser was brute-forceing the (possibly ambigous) grammar. I'm not claiming that's the case, but that section of the talk raised a lot of questions for me. But you may be right, Tobie might have wanted to just give a coarse overview of their platform.
@@nyxcode2818 That’s an interesting point. My interpretation wasn’t that the grammar was ambiguous though. Rather that it has a better kind of grammar. For example, in regular English you don’t exactly have reserved keywords. The order where you put words matter for the meaning and the context matters. In some programming languages keywords are reserved and you can never use those as variable names etc. I think that’s all there is to it. There are some nice models used in modern parsers. Like abstract syntax trees for example. Rust’s macro system for example is really cool in that it isn’t a simple text substitution but it’s actually very aware of rusts language syntax and can operate on that abstract structure directly in the compiler stage. That’s just tangentially related to the topic here of course but I just thought I’d bring it up. I’m not completely sure how all of that effects parsing speed though. It really depends on how much fancy stuff is done behind the scene but I think the algorithms for tokenizing and parsing and whatever the steps are called are quite efficient. Even if a language have reserved keywords I think you still have to go through most of the same steps usually. It’s not obvious to me that that aspect of the language would significantly impact the speed in either direction. Though I’m far from an expert. (Though I have completed some parser katas in rust on a site with programming exercises so take it for what it is.) The thing that strikes me as potentially risky is that this language seems to make it very easy to write queries that I expect to be quite expensive to execute. If you really want to execute such queries, you sure can write them with deep multi level joins but that a bit daunting. Sometimes a part of good language design is to make “slow stupid” things hard to express. But maybe there are better ways to guard for that. Like, let it be easy to express and have a linter that warns you if your query is likely to take several times the age of the universe etc. But I digress ^_^. Thanks for the interaction!
@@Tim_Small That's true, though the BSL that it's licensed under is really permissive. In addition to the normal rights the BSL affords (availability of source) it also allows users to use the application in any non-commercial or commercial venture *except* a DBaaS product. Additionally, in 2027 it changes into an Apache Public License which *is* OSI approved. Of all the reasons to criticize this talk, I'm not sure the licensed used by the application is a useful one :)
Oh man, it's so advanced. But what I want to know: Is it blazing fast?
Рік тому+12
SurrealDB is great and promising. Great work. The presenter seems to be reading this talk. This makes the presentation really tedious. It would have been a lot better if the actually talked to the crowd.
Great db but the talk, while clear, sounded like an investor pitch for the db and rust rather than a story about what occurred in that year of rewriting the db.
Stopped watching at 12 minutes, couldn't stand the sales pitch with no content. I'm sure it gets better later, but damn this is a tech talk not a sales meeting.
I am a golang engineer and was really impressed by your insights. Also about your learning path around at 36:00
As a user, one thing that would be really golden down the line would be to have a whole “rust book” for the ins and outs of databases, using surreal as the tool.
I know the basics of databases and the ideas behind local vs cloud and scaling and so on but I’m enough of a noob that I have no idea which option to use when kind of.
There are so many little concepts that probably are so obvious for database developers who have a few years of work life experience that are quite enigmatic for juniors. Especially for people without a CS background.
Anyway, great talk and very cool project!
Omg please do this! 💜🙏🏾
@@andydataguy I second, or well, third, this suggestion. Having a RustBook instruction-set on SurrealDB would be AMAZING!
Wow I looked at this year's ago and was super impressed, at the time I was even think this would have been better in rust. Now I find you again just as I need an embedded dB in my rust app. Woohoo I'm excited
Dont want to sound too negative, but this seemed to me more like a sales pitch.
I'd be much more interested in the technical details. When he did mention some, I got a bit concerned though. When he described the parsing of SurrealQL, I was wondering about performance, and if the resulting grammar can be parsed efficiently at all. Also, comparing async to threading seemed super weird, since these concepts are orthagonal.
1. It was definitely a high level overview with mostly highlights rather than details. More of a story of moving to rust and so on. But a bit of code showcase and name dropping of some relevant crates.
2. About the syntax, it would be interesting to see benchmarks. I’m not familiar with the crate used to do the parsing or how it handles this syntax. Even if the parsing looked very self descriptive, that piece of code made some heavy use of rust macros (apparent from “function calls” where the names end with “!”). So that code might be doing something slightly fancier under the hood.
Was there anything in particular about the grammar of SurrealQL that pops out as being slow to parse, compared to equivalent join statements in other query languages?
I think relations of the form A->B->C work by defining a separate table called B with entries “in=a” and “out=b” and then the select-queries using the same notation are essentially running joins. There may be more magic to it, I’ve only played with surreal for an evening or two. What are your thoughts?
3. Async/threading. I think he just mentioned general features of rust and that there are good options for using different kind of concurrency models. And if it makes sense you can leverage several of them in the same application. Or you can just pick the one that suits your needs. I don’t think he was being more specific than that, but I could be wrong.
@@HyperFocusMarshmallow Nothing I saw poped out per se, but he mentioned that the query language did not have any keywords. As he described it, it seemed to me like the parser was brute-forceing the (possibly ambigous) grammar. I'm not claiming that's the case, but that section of the talk raised a lot of questions for me.
But you may be right, Tobie might have wanted to just give a coarse overview of their platform.
@@nyxcode2818 That’s an interesting point. My interpretation wasn’t that the grammar was ambiguous though. Rather that it has a better kind of grammar. For example, in regular English you don’t exactly have reserved keywords. The order where you put words matter for the meaning and the context matters. In some programming languages keywords are reserved and you can never use those as variable names etc. I think that’s all there is to it.
There are some nice models used in modern parsers. Like abstract syntax trees for example. Rust’s macro system for example is really cool in that it isn’t a simple text substitution but it’s actually very aware of rusts language syntax and can operate on that abstract structure directly in the compiler stage.
That’s just tangentially related to the topic here of course but I just thought I’d bring it up.
I’m not completely sure how all of that effects parsing speed though. It really depends on how much fancy stuff is done behind the scene but I think the algorithms for tokenizing and parsing and whatever the steps are called are quite efficient. Even if a language have reserved keywords I think you still have to go through most of the same steps usually. It’s not obvious to me that that aspect of the language would significantly impact the speed in either direction. Though I’m far from an expert. (Though I have completed some parser katas in rust on a site with programming exercises so take it for what it is.)
The thing that strikes me as potentially risky is that this language seems to make it very easy to write queries that I expect to be quite expensive to execute.
If you really want to execute such queries, you sure can write them with deep multi level joins but that a bit daunting.
Sometimes a part of good language design is to make “slow stupid” things hard to express. But maybe there are better ways to guard for that. Like, let it be easy to express and have a linter that warns you if your query is likely to take several times the age of the universe etc.
But I digress ^_^.
Thanks for the interaction!
Its not under an open source (OSI) compatible license either.
@@Tim_Small That's true, though the BSL that it's licensed under is really permissive. In addition to the normal rights the BSL affords (availability of source) it also allows users to use the application in any non-commercial or commercial venture *except* a DBaaS product. Additionally, in 2027 it changes into an Apache Public License which *is* OSI approved.
Of all the reasons to criticize this talk, I'm not sure the licensed used by the application is a useful one :)
Oh man, it's so advanced. But what I want to know: Is it blazing fast?
SurrealDB is great and promising. Great work. The presenter seems to be reading this talk. This makes the presentation really tedious. It would have been a lot better if the actually talked to the crowd.
An advanced amount of advanced features, delivered in an advanced voice featuring an advanced dry characteristic among other advanced features.
Great db but the talk, while clear, sounded like an investor pitch for the db and rust rather than a story about what occurred in that year of rewriting the db.
it's time to rewrite it in Zig 😅
Segmentation fault
@@wuxxy panick
A dubious proposition
the rust comunity is building a lot of cool projects 👍
Finally a free lunch, where is the catch bro?
Stopped watching at 12 minutes, couldn't stand the sales pitch with no content. I'm sure it gets better later, but damn this is a tech talk not a sales meeting.
noob
To each their own I suppose
It didn't change much unfortunately
So, if I understand correctly, SurrealDB is pretty much a backend-as-a-service.
i was excited to use it but after a speed comparison with postgres, postgres smoked surreal
Thanks for sharing, interesting talk.
Wow!
👍👍👍