ORM is not needful in Rust, sir

Rust is fucking shit! But ORMs are also shit.
You want to use shit on top of your shit.

SQL is standardized, meanwhile whatever interface an ORM offers is not.
You always end up having to learn he ORM additionally to SQL. Instead of knowing one, you now have to know two things.

I can think of plenty of reasons to shit on Rust but it doesn't seem fair to expect them to come up with a good ORM when literally no one else has.

>>108564828
>Rust is fucking shit!
non sequitur

>>108564784
https://diesel.rs/

And fuck off.

>>108564828
>>108564843
working without an ORM is a pain in the ass and always was
hating on ORMs is just a retarded contrarian position
>>108564855
but its a piece of shit come on its a fucking mess.
it makes you create two structs for every table. it doesnt let you go code-first when it comes to migrations. it refuses to provide any kind of automatic mapping (enum->int or datetime->string for example)
whats the fucking point?

>use ORM
>have to constantly look up documentations of the ORM to know how things are done
>sometimes write raw SQL queries to then look up how to do those in the ORM
>as it grows, it gets slow
>benchmark queries, the ORM does some really silly decisions
>dig even deeper into the ORM and its source, to find out how to force it to write queries in a certain way
>eventually give up on this and use the ORMs interface for raw queries
>decide to rewrite everything into raw queries
>long-term goal to drop the ORM
i spent hundreds of hours dealing with an ORM for nothing

>>108564880
i know right
piecing together queries like a stupid cuck is soooo much easier than just assigning values to an object and calling the commit function
contrarian retard take

>>108564880
>i spent hundreds of hours dealing with an ORM for nothing
which ORM?

>>108564896
Hello sir

>>108564864
The more you write in plain SQL, the faster your application gets. At the most optimal level, you have all data processing in stored procedures.

Same goes for basic key-value-stores as well. If you use redis, and you want it to be fast, you use its built-in lua scripting to cover all cases where you fetch -> calculate -> store.

And more people exist who know SQL, than people who know how to use your specific ORM. There is a larger pool of knowledge, you get better support, etc.

>>108564913
hello cuck

>>108564903
sequelizejs

>>108564916
>My ORM doesn't use stored procedures under the hood
it sounds like you've only used shit ORMs anon

>>108564916
>The more you write in plain SQL, the faster your application gets.
i dont care
i dont need speed
>At the most optimal level, you have all data processing in stored procedures.
please kill yourself if you do this
im tired of having to maintain garbage software written by people like you

>>108564922
oh, no wonder you hate ORMs

>>108564784
> why yes, I want weird bugs, bad performance and less control
ORMs are fucking shit.

>>108564926
> im tired of having to maintain garbage software written by people like you
And I’m tired of having to learn another ORM black box because you’re a retard that gets filtered by SQL (which granted, sucks ass, but is at least reusable knowledge). Fuck off.

>>108564953
My ORM is part of a full MVC stack.
I don't have to touch any code, I just lay out the data model with a model editor. Once that's done, I can click a button to generate the DDL. Click the little execute button and it creates my full database for me. Then I click run application and I have a full admin app already built out for my new database schema.

>>108564916
>makes you write two structs
actually many more than that. rust isn't javascript where nobody cares about memory.
if you need to load a user from database to get their info, you probably don't want to load their password hash, or profile picture from the db. only load what is strictly necessary

>automatic enum<->int mapping
you're supposed to implement them yourself. The reason they're not OOB is that if you change your enum you HAVE to migrate your database.

>>108564926
>i dont need speed
>uses Rust

>>108565115
>if you need to load a user from database to get their info, you probably don't want to load their password hash, or profile picture from the db. only load what is strictly necessary
I find using an ORM makes me lay out tables in 3NF which avoids this problem naturally

>>108565136
are there any performance/size benefits from using that layout?

it seems more maintainable and easier to migrate to have limited rows per table

>>108564972
You're a dumb fuck looking for an ORM in a language that's not even object-oriented. Kill yourself, I mean that sincerely.

>>108564784
Rust is a fake language

>use EFCore
>queries are full retard from "normal" looking use
ya, never again. ORMs are gay.

what I don't get is, if all you're storing are basically structs, why do you even need sql?

>>108565208
This. You don’t, but it’s everyone’s go to. A NoSQL document/JSON database makes way more sense, but people tried to use them as RDBMS and when that didn’t work they proclaimed NoSQL sucks.

>>108565238
You can store documents and json in SQL databases as well. You can even put constrains and indexes on json fields in PostgreSQL.
You can't use NoSQL databases as RDBMS though. That's what makes them strictly inferior.

>>108565208
>what I don't get is, if all you're storing are basically structs
?????
as opposed to what?

>>108565181
rust is object oriented you massive mouthbreather

>>108565290
relational or graph-oriented data? idk nigga?
if you don't have any foreign keys or all your FK usage is for weird constrained SQL-brain reasons, what >>108565238 said tracks. even then, most meme RDBMSs have some "JSON" column type so your rows are just id, jasons.

>>108565324
>relational or graph-oriented data?
what do you think a hierarchy of structs is exactly?

>>108564784
Databases are boring.

Kill yourself is the most weak thing to say, it reveals your impotent rage and butthurt, and it reveals you have the character and personality of an 11 year old fortnite player.

>>108565293
Rust has no inheritance so 99% of OOP doesn't apply to it.
Rust is just an imperative systems language with FP elements.

>>108565438
object oriented is not a synonym of java clone

>>108564784
I never understood the point of ORMs, like you already have a declarative high level DSL to do database queries (SQL), and if you want it to be more dynamic you can just use sql builders (which i admit i dont know how good they are in rust)

>>108564926
>im tired of having to maintain garbage software written by people like you
What is there to maintain?
The SQL of your RDBM doesn't randomly break syntax on updates. A query that worked 20 years ago, still works now. And everybody who learned SQL in the past 20 years can maintain it, if needed. And every application, doesn't matter in which language it is written, can call it.

Meanwhile your ORM exists for a year, then got a major version update and everything changed again and you need to adjust shit, and it only works for that specific language in that specific setup.

If you know how to use your ORM now, this knowledge is only useful for a few months or years at best. If you know how to write SQL, this knowledge is useful forever... at the current trajectory, because SQL always won in the end, every attempt to replace it failed, every alternative is worse.

>>108564972
This is horrid!
It is terrifying.

>>108565504
> and if you want it to be more dynamic you can just use sql builders
This is the answer. You get best of both worlds: flexibility of lower level when you need it when constructing queries and abstraction of higher level by exposing functions that take parameters and return queries, and reuse in between: the result query can also be used as part of another query.

>>108565454
OOP design patterns heavily depend on inheritance. In Rust, you are more likely to find monads, lenses, higher order functions than abstract factories, decorators, dependency injection, etc.

>>108565263
Databases themselves are a compromise.
Separation of data and code is completely artificial and counterproductive.
That's why you get all those copes with normalization, views, procedures etc. in SQL DBMS world.

For your program to be optimal it has to use data structures that fit the problem. And no, permanence doesn't change things - it just means you have to use data structures fit for use with hard drives, implement caching and so on.
And if your database has to be accessed by multiple clients at the time - again - you're likely better off with providing your own interfaces and handling synchronization yourself.

Obviously the above is much harder and time consuming and that's why it's so rare... but not non-existent.
It's the reason why "NoSQL" databases exist - SQL databases just didn't scale to problems those social media platforms that started at the time met and they needed to implement their own bespoke data storage solutions.

And later - of course - sales/marketing/consulting people at those companies looked at those custom solutions, told code monkeys to integrate them into self-contained shitty frameworks, coined the term "NoSQL" and started shilling them as a magical fit-all solution to all the world data problems.

>>108565527
>What is there to maintain?
your unreadable stored procedure mess
thats what
there's a reason why the world moved on from this garbage and gravitated towards ORMs
>>108565849
you're just arguing semantics
thats java/c++ style oop
rust is still object oriented, structs are objects

>>108566082
>Databases themselves are a compromise.
>Separation of data and code is completely artificial and counterproductive.
There is tons of separations everywhere You separate code from the dockerfile, config files, reverse proxy, game assets, readme, etc. There is nothing natural or productive in putting everything inside program's code.

>That's why you get all those copes with normalization, views, procedures etc.
You do all of them when you are writing code as well. You do not want to have vague, unspecified source of truth in your program.

>For your program to be optimal it has to use data structures that fit the problem.
True

>And if your database has to be accessed by multiple clients at the time - again - you're likely better off with providing your own interfaces and handling synchronization yourself.
Wrong. This takes significantly longer to develop, is much more likely to be bug prone, will be more difficult to scale and will be harder to keep up with sophisticated, battletested executors of established database engines.

>It's the reason why "NoSQL" databases exist - SQL databases just didn't scale to problems those social media platforms that started at the time met and they needed to implement their own bespoke data storage solutions.
Facebook and Twitter use MySQL
Instagram and Reddit use PostgreSQL

>>108566082
Your post was alright until you started talking about scaling.

RDBMS scale well. Your custom database implementation won't scale at all. The database is the source of truth, so good luck doing this yourself and make it scale vertically. You will have to implement transactions, read replicas, locking, etc.

Those social media corpos you talk about, take an existing RDBMS and modify it to their liking.
Which is why PostgreSQL is shilled so hard, it has a permissive license, so they can change it without having to make those changes OpenSource.
Meanwhile MySQL and Mariadb scale better, but are GPL (or you pay Oracle extortion money).
So the corpos choose the one that scales worse, but which they can modify and implement their own datatypes and stuff.
Your facebook user data isn't in a NoSQL database. Storing the data of a billion users in an in-memory storage would be crazy. All the cloud companies will sell NoSQL to you, but that doesn't mean that Big Tech relies on them themselves. All the large and important stuff sits in an RDBMS.

I think you are talking more about actual applications.
Like a game isn't going to use SQL. Minecraft doesn't need an SQL server usually. But they max out at 100 concurrent players per server or so.

>>108566211
Why do you think a query language that exists for 20 years and that has many many people understand it, is "unreadable", but your ORM code, that only works with one specific version of one specific library in one specific language that you specifically have to learn, is "readable"?

You are simply dumb.

>>108566211
>you're just arguing semantics
>thats java/c++ style oop
When you buy any book, course, class on OOP you are going to learn about design patterns. Most of these design patterns can't be used in Rust or make absolutely no sense to do. Therefore Rust is not an OOP language.

>rust is still object oriented, structs are objects
Your definition of OOP is arbitrary and pointless. Nearly all languages have structs, but not all languages allow you to do things that are common in OOP.

>>108566253
because SQL is awful
the syntax is all upside down, you have to read any SQL file a thousand times before being able of piecing together mentally what its doing
ORM syntax is straightforward. you can read a procedure using an ORM from top to bottom and understand every step immediately.

>>108564784
>there are literally no good ORMs for this language, wtf???
you have strings, the fuck else do you need? are you a retard?
>you're telling me that these motherfuckers rewrote every piece of software ever written but didnt bother writing an ORM that just works????
because it's worthless, do it yourself if you need it

>>108566246
>Which is why PostgreSQL is shilled so hard, it has a permissive license, so they can change it without having to make those changes OpenSource.
You can take GPL software, modify it and use it for a proprietary social media. They all run on Linux anyway.
Permissiveness has nothing to do with this. PostgreSQL is just very good and easy to extend, that's why it is popular.

>Meanwhile MySQL and Mariadb scale better, but are GPL (or you pay Oracle extortion money).
MySQL and Mariadb has significantly inferior developer experience and that's why people gravitate to pgsql

>>108566259
do i need a ProxyBuilderFactoryNigger in order to use an ORM?
you're the one who's not making sense
a table maps to an object/struct. thats literally what ORM means. if it has a struct it can have an ORM that maps tables to that struct.
rust doesnt lack any capability needed to have an ergonomic ORM written in it.

>>108566266
I have never seen any ORM syntax that was as powerful as SQL while being more readable. Nearly all ORM syntaxes only give you a thin slice of SQL capabilities and often come with weird syntax that has a lot of performance gotchas.

>>108566284
I haven't said anything about ORM. I was just talking about OOP.

>>108566246
>All the large and important stuff sits in an RDBMS
No, it doesn't.
They are unable to have a one single source of truth due to having to serve the whole world - they need local caches that synchronize data between each other - that's why you can get even a reliable and updated in real-time YT view counter.
All custom in-house solutions (that may or may not use RDBMS in their implementation in some places).

>>108566304
can't

>>108566304
>No, it doesn't
Facebook and Twitter use MySQL
Instagram and Reddit use PostgreSQL

>>108566266
>SQL is awful
Yes, it is, nobody denies that.
But it works, is known, and you can actually write SQL queries that are finished and that will never need to be adjusted ever again.
Meanwhile you have to rewrite your ORM using code after every update again and read their changelog and nobody else is able to easily maintain it, unless he is skilled in exactly that ORM.
>you have to read any SQL file a thousand times before being able of piecing together mentally what its doing
That is literally a skill issue.
You simply don't want to learn it, and instead you enter a hellhole of constant maintenance, because some ORM allows you to write SELECT more beautifully, but becomes a mess as soon as you need to join some tables.
You will waste lots of time.

>>108566280
MySQL and Mariadb do scale better and they don't need to VACCUUM.
That is a very big advantage.