If Django works for you, I'm absolutely not saying you should switch to Cot immediately! Some people like to have as many type-safety and compile-time checks as possible, so that's the crowd we're trying to satisfy.
There are several reasons I don't like the existing ORMs in Rust, many of them being overly verbose, some generating unnecessary files, and having somewhat weird DSLs being the main reasons. The main reason, I think, was that none of them supports automatically generated migrations, and I absolutely loved that feature in Django. The differences between existing ORMs sound like a neat idea for another blog post, to be honest, so I'll probably do that soon!
Diesel absolutely can be used, there is no reason it can't - database support is feature flag-gated, so disabling it as as easy as adding one line in your Cargo.toml file. This, however, will obviously also disable some other features that depend on the database, such as authentication through database.
Whether building a custom ORM will be a good idea - only time will tell.
Writing raw SQL is perhaps indeed easier for simple queries, but put some foreign keys inside or slightly more complex relationships between tables and you'll probably quickly fall into the trap of having to remember your entire database schema to write anything. Yes, the example from the documentation is slightly more complicated, but it checks at compile time the exact column names and types, so you get feedback much quicker than actually running the SQL query.
In addition to that, over the years of writing web services, I always found raw queries much less maintainable. The ORM immediately tells you that you messed up your refactoring, whether it is just renaming a column, or removing a table completely.
Pretty much every ORM (including the one in Cot) also allows you to write your own custom queries if the abstractions are not enough, so there's always this fallback option.
> Yes, the example from the documentation is slightly more complicated, but it checks at compile time the exact column names and types, so you get feedback much quicker than actually running the SQL query.
Well sqlx checks at compile time your raw query if you use their macro, at the expense of increased compile times.
I never understood the hate against ORMs. It always seems like a superiority complex or some claim that SQL is “so simple”.
Yeah SQL is extremely simple to write, that isn’t really the problem ORMs solve for me, but rather they solve composability and reuse of queries.
I think there is a similar vein of people crying about sites not using 100% vanilla js without a framework. They are missing the point or don’t have enough experience with the actual problems the abstractions solve.
This is one of my biggest pet peeves against HN. It's also obvious ORMS won, every new framework creates them. People who keep speaking about not using them are crazy.
I am confident in easy SELECT queries, even with multiple tables, but once i have to use JOIN or other advanced things my queries are a mess, returning data i never expected.
Yes, the project was fun, yet simple and fast to write! I was thinking about doing some more advanced optimizations, although I believe the opportunities for that are pretty limited for Brainfuck. Also, I think the code is pretty nice and clean and generic enough to be partially moved to another possible project, which is the gain of doing things more generic than they actually needed to be.
You said you were working on another JIT - what was that? Also, do you have any suggestions of another project/language to implement compiler for to gain some knowledge about writing optimizations, actual intepretation/compilation logic, etc?
Thanks for the additional resources about the instruction encoding - seems like this is a bit easier to understand than AMD64 documentation!
I'm not an expert in this field, also currently in learning mode.
> You said you were working on another JIT - what was that?
A JIT for a custom 32-bit RISC soft-CPU (FPGA).
> Also, do you have any suggestions of another project/language to implement compiler for to gain some knowledge about writing optimizations, actual intepretation/compilation logic, etc?
You could write another C compiler. Or a JIT for some scripting language. Lua is about as simple as it gets when it comes to JITtable scripting languages. Of course amazing http://luajit.org/ already exists.
Existing CPUs and bytecode formats are also potentially good.
In particular, other people might actually want to use a small WebAssembly (https://webassembly.org/) AOT/JIT compiler. I know I would. :)
Some source code I've personally found educating on this topic:
1) Lots of easier stuff (ARM/x86 encoding, basic optimizations, etc.) can be found in JITting emulators, like Dolphin: (https://github.com/dolphin-emu/dolphin)
