Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing SurrealDB 1.0

surrealdb.com

Post reply on HN
Print view View original

51–56 of 56 posts

Re: Announcing SurrealDB 1.0

#51

Post by PedroBatista »

dgudkov wrote: post #50

While I applaud any attempts to innovate in this area, I'd be more interested in seeing the opposite approach - integrating persistent storage in a programming language. If we already have default implementations of dictionaries, linked lists, and other in-memory data structures in programming languages, why not have default implementations of permanent data structures such as object collections and KV-stores?

Check this out: https://microstream.one/products/microstream-for-java/

Io also has persistence baked into it: https://iolanguage.org/reference/

But I'm sure for most of the HN crowd one has Java in the URL and the other is a esoteric cool language from the early 00's so.. not practical. :)

Re: Announcing SurrealDB 1.0

#52

Post by thunderbong »

dgudkov wrote: post #50

While I applaud any attempts to innovate in this area, I'd be more interested in seeing the opposite approach - integrating persistent storage in a programming language. If we already have default implementations of dictionaries, linked lists, and other in-memory data structures in programming languages, why not have default implementations of permanent data structures such as object collections and KV-stores?

There have been many attempts over the years. There's Prevayler [0], in Java, and Madeleine [1], in Ruby. Neither of them became wildly popular.

I worked with Madeleine for a few years and while the performance was amazing, RDBM systems are ahead because of the many years of standardisation, tooling and capabilities (e.g. migrations)

The other very important thing is - DB latency is an issue only in the hands of a novice. In the real world, network latency is a couple of magnitudes higher.

[0]: https://github.com/prevayler/prevayler

[1]: https://github.com/ghostganz/madeleine

Re: Announcing SurrealDB 1.0

#53

Post by happymellon »

foobiekr wrote: post #44
threeseed wrote: post #31

Earlier quoted context omitted.

During the Java era the standard quickly became ORM instead of stored procedures. Largely thanks to NeXT showing the way with EOF (the original ORM).

ORMs basically exist because people doing coding refuse to learn the relational model and want to program with OO instead. Most of the time they are, at best, irrelevant but eventually become expensive, slow, complex and painful. Everyone in coding knows, once they get a lot of experience, that translation/mapping layers are a waste of cycles, memory, and are complex and where assumptions mismatch results in tons of…

I've just spent the past week refactoring code that was too slow because joins were being performed by a loop in the code rather than just doing a join in the first place.

Replacing 3 classes, and numerous methods with two 6 line queries that does the same task in a thousandth of the time is quite satisfying.

Re: Announcing SurrealDB 1.0

#54

Post by anonzzzies »

happymellon wrote: post #53
foobiekr wrote: post #44

Earlier quoted context omitted.

ORMs basically exist because people doing coding refuse to learn the relational model and want to program with OO instead. Most of the time they are, at best, irrelevant but eventually become expensive, slow, complex and painful. Everyone in coding knows, once they get a lot of experience, that translation/mapping layers are a waste of cycles, memory, and are complex and where assumptions mismatch results in tons of…

I've just spent the past week refactoring code that was too slow because joins were being performed by a loop in the code rather than just doing a join in the first place. Replacing 3 classes, and numerous methods with two 6 line queries that does the same task in a thousandth of the time is quite satisfying.

That seems due to the leaky abstractions that ORMs invite; they appear to be just 'normal code'; just working with structures, objects and variables like you would normally do in code. In reality you have to really know the insides, performance characteristics etc of the db you are using. We encounter a massive amount of codebases from the last ~10 years that are built like there is no database to account for, so there are usually not even indices, there are indeed loops doing inserts etc.

Stored procs might be considered evil; they did make the developer acutely aware of the innards of the database instead of just not even knowing how a db works and which things are expensive. To know that you need to look past the leaky abstraction of ORMs and that's distracting from making features.

I have heard tech leads in this situation claim that because everything runs fine in the cloud without knowing anything about postgres/mysql/dynamo etc, and those extra costs are cheaper than people, it's fine. But our team wasn't hired because it was fine; we were hired because hosting costs were eclipsing the developer costs. It's not that hard to do when stuff is just incredibly badly built...

Re: Announcing SurrealDB 1.0

#55

Post by happymellon »

anonzzzies wrote: post #54
happymellon wrote: post #53

Earlier quoted context omitted.

I've just spent the past week refactoring code that was too slow because joins were being performed by a loop in the code rather than just doing a join in the first place. Replacing 3 classes, and numerous methods with two 6 line queries that does the same task in a thousandth of the time is quite satisfying.

That seems due to the leaky abstractions that ORMs invite; they appear to be just 'normal code'; just working with structures, objects and variables like you would normally do in code. In reality you have to really know the insides, performance characteristics etc of the db you are using. We encounter a massive amount of codebases from the last ~10 years that are built like there is no database to account for, so the…

They don't even need to be stored procedures, just having proper queries in the code to perform the database actions would be preferable to ORM.

Another big issue I have with ORMs is that a lot of them are hostile to you writing queries in the first place. Network IO is the worst, please stop trying to force us to use your terrible overlay.

Re: Announcing SurrealDB 1.0

#56

Post by foobiekr »

happymellon wrote: post #55
anonzzzies wrote: post #54

Earlier quoted context omitted.

That seems due to the leaky abstractions that ORMs invite; they appear to be just 'normal code'; just working with structures, objects and variables like you would normally do in code. In reality you have to really know the insides, performance characteristics etc of the db you are using. We encounter a massive amount of codebases from the last ~10 years that are built like there is no database to account for, so the…

They don't even need to be stored procedures, just having proper queries in the code to perform the database actions would be preferable to ORM. Another big issue I have with ORMs is that a lot of them are hostile to you writing queries in the first place. Network IO is the worst, please stop trying to force us to use your terrible overlay.

I’m going to start having a seizure if I keep reading this thread because I agree so strongly.

It is painful looking at modern software development. They don’t know the basics and the whole Agile/TDD thing I think was the start of the end because table schema (and every other kind of planning) is not really compatible with agile.

Post reply on HN