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

Cold Showers: For when people get too hyped up about things

github.com

Post reply on HN
Print view View original

201–210 of 243 posts

Re: Cold Showers: For when people get too hyped up about things

#201

Post by therealdrag0 »

smoe wrote: post #175
Multicomp wrote: post #16

I love that sqlite article. It seems like "everyone" is certain that sqlite can only be used for up to a single query per second, anything more and you need to spin up a triple sharded postgres or Hadoop cluster because it 'needs to scale'. I love being able to show that study, if you properly architect your sqlite system and am willing to purchase hardware, you can go a long long way, much further than almost all co…

I'd certainly believe sqlite can be taken very far. Never done it so far. But what does "properly architect your sqlite system" mean and how does this compare to just spinning up a postgres service (nothing sharded or fancy otherwise)?

In this case it seems to mean building an extra server layer on-top of it.

- https://blog.expensify.com/2018/01/08/scaling-sqlite-to-4m-q... - https://bedrockdb.com/

Re: Cold Showers: For when people get too hyped up about things

#202

Post by albntomat0 »

JAlexoid wrote: post #197
albntomat0 wrote: post #131

Earlier quoted context omitted.

They are not the same, at least according to the definitions I'm familiar with. Static/dynamic is whether type checking is done at compile time or run type. Strong/weak is how flexible the language is with type conversion. Another explanation: https://en.hexlet.io/courses/intro_to_programming/lessons/ty...

Static vs dynamic is not for type checking, it's about conversion. As in: Static typing - 1 == "1" is false (Python style, integer isn't converted to string for comparison) Dynamic typing - 1 == "1" is true (PHP style, integer or string may be converted)

Where are you getting your definitions from? What you posted is what I understand to be weak vs strong.

Re: Cold Showers: For when people get too hyped up about things

#203

Post by JAlexoid »

albntomat0 wrote: post #202
JAlexoid wrote: post #197

Earlier quoted context omitted.

Static vs dynamic is not for type checking, it's about conversion. As in: Static typing - 1 == "1" is false (Python style, integer isn't converted to string for comparison) Dynamic typing - 1 == "1" is true (PHP style, integer or string may be converted)

Where are you getting your definitions from? What you posted is what I understand to be weak vs strong.

Barbara Liskov defines strong typing as a compiler feature that prevents wrong type usage.

Liskov, B; Zilles, S (1974). "Programming with abstract data types".

http://web.cs.iastate.edu/~hridesh/teaching/362/07/01/papers...

Re: Cold Showers: For when people get too hyped up about things

#204

Post by xearl »

JAlexoid wrote: post #193
Spivak wrote: post #33

Earlier quoted context omitted.

This really isn't a fair take on the situation. (a) They implemented a very boring transaction/caching/replication layer that is like any other DB except they borrowed the idea that "longest chain" should be used for conflict resolution. (b) They worked with upstream to get a few patches that were unique to their use-case. Once you're in deep with any DB this really isn't that uncommon. (c) They used a dedicated (lol…

I don't know where they have it, but cohosting isn't exactly free. 1U of cohost with 100mbps in a cheap Eastern European DC will cost a few hundred euro per month... and my info is a few years old. It's more expensive now. It is very specific case, that we should not extrapolate to mean it's general use case. AWS/GCP/Azure are still a better places to start for most people.

14U colocation in Germany with 1 Gbps is EUR 100/m + power: https://www.hetzner.com/colocation

Re: Cold Showers: For when people get too hyped up about things

#205

Post by efreak »

Multicomp wrote: post #16

I love that sqlite article. It seems like "everyone" is certain that sqlite can only be used for up to a single query per second, anything more and you need to spin up a triple sharded postgres or Hadoop cluster because it 'needs to scale'. I love being able to show that study, if you properly architect your sqlite system and am willing to purchase hardware, you can go a long long way, much further than almost all co…

As a casual user of random software that I test and then immediately forget: I really wish more applications supported sqlite databases. I've set up everything from IRC bots to server animation software to log analysis to forums and WordPress, to test it out, and the first thing that makes me drop something is a dependency on MySQL, pgsql, etc. If your software can work out of a single directory otherwise but can't work with a local database in the same directory, then I'm not going to use it.

Re: Cold Showers: For when people get too hyped up about things

#206

Post by GlennS »

wtetzner wrote: post #120
GlennS wrote: post #48

Earlier quoted context omitted.

I would like to be able to explain the cost part better. It may just be personal bias of course. 1. There's no guarantee the correct theoretical model of your program fits the type system of your programming language. 2. Sometimes there are multiple correct models for different purposes in the same program, similar to how sometimes you need multiple views onto the same database tables. 3. Sometimes you just need the…

> 2. Sometimes there are multiple correct models for different purposes in the same program, similar to how sometimes you need multiple views onto the same database tables. Just wanted to point out that even though you can have multiple views or your database tables, they all still adhere to the same type system.

I guess it's a problem that can be overcome with type inference then? (I don't have to declare types on queries, updates, or views, just on the base tables.)

Re: Cold Showers: For when people get too hyped up about things

#207

Post by ajbonkoski »

This gets at the heart of one of my big gripes about how we talk about engineering and technology.

Often a fancy new thing is introduced with a very long list of pros: "fast, scalable, flexible, safe". Rarely, is a list of cons included: "brittle, tough learning curve, complicated, new failure modes".

This practice always strikes me as odd because the first law of engineering is "everything is a trade-off". So, if I am going to do my job as an engineer I really need to understand both the "pros" and "cons". I need to understand what trade-off I'm making to get the "pros". And only then can I reason about wether the cost is justified.

Re: Cold Showers: For when people get too hyped up about things

#208

Post by dahauns »

Spivak wrote: post #33
threeseed wrote: post #25

Earlier quoted context omitted.

My favourite part is how they: (a) built their own transaction/caching/replication layer using Blockchain no less. (b) paid SQLite team to add a number of custom modifications. (c) used expensive, custom, non-ephemeral hardware. Now you could do all of this or just use an off the shelf database that you aren't having to write custom code to use and if you choose a distributed one e.g. Cassandra will be able to run on…

This really isn't a fair take on the situation. (a) They implemented a very boring transaction/caching/replication layer that is like any other DB except they borrowed the idea that "longest chain" should be used for conflict resolution. (b) They worked with upstream to get a few patches that were unique to their use-case. Once you're in deep with any DB this really isn't that uncommon. (c) They used a dedicated (lol…

>They implemented a very boring transaction/caching/replication layer that is like any other DB except they borrowed the idea that "longest chain" should be used for conflict resolution.

Handwaving this layer away as "very boring" isn't exactly fair, either. What does boring even mean here? I mean, this layer solves problems that are both essential to performance scaling of RDBMS and have been proven time and again to be hard to reliably solve in a general case. And it has furthermore been built from the ground up tailored towards the specific needs/use cases of the company.

By the aforementioned handwaving the presented successes are implicitly attributed to SQLite to a degree that isn't justified IMO.

Re: Cold Showers: For when people get too hyped up about things

#209

Post by dahauns »

simiones wrote: post #49
pantaloony wrote: post #30

Earlier quoted context omitted.

I don’t get the cost claims. The time it takes to note which type I intend something to be is mostly either so low that I recover it via improved hints and such very quickly, or larger but only because I’m documenting something complex enough that I should have documented it anyway, whether or not I was using static types, because it’ll be hell for other people or future-me to figure out otherwise. It seems like a la…

I think the general feeling is that there are some code patterns that are safe and easy to do with dynamic typing, but impossible with simple type systems or more complex with more advanced type system. An example would be Common Lisp's `map` function [0] (it takes a number of sequences and a function that has as many parameters as there are sequences). It would be hard to come up with a type for this in Java, and it…

IMO, Go is never a good example in static vs dynamic type system discussions (I mean, for this case: parametric polymorphism has been around since the 70s...).

The language developers themselves have repeatedly stated that its type system being very limited is intentional.

See e.g. here: https://github.com/golang/go/issues/29649#issuecomment-45482...

TBH, sometimes I wonder why they bothered with static typing at all...

Re: Cold Showers: For when people get too hyped up about things

#210

Post by dahauns »

anonymoushn wrote: post #185
pantaloony wrote: post #30

Earlier quoted context omitted.

I don’t get the cost claims. The time it takes to note which type I intend something to be is mostly either so low that I recover it via improved hints and such very quickly, or larger but only because I’m documenting something complex enough that I should have documented it anyway, whether or not I was using static types, because it’ll be hell for other people or future-me to figure out otherwise. It seems like a la…

How many hundreds of LOC would you like to write to support serializing and deserializing JSON for an endpoint that has a schema with around 20 fields, some of which are nested? If you are using Spring and Jackson, you will get to write around 300 LOC across 8 files before you get your hands on a single deserialized object. In any sane language you would use a library that enforces an arbitrary JSON schema to get the…

Why would you write any of this yourself?

This is the classic use case for code generation. (And IMO one of the few justified ones.)

Post reply on HN