hasenj

This is cool. I've been thinking about this for a while. The best way to write high quality web applications is to use compiled languages and minimize the complexity of the infrastructure by using e.g. SQLite instead of PostgreSQL.

I hope this trend starts to pick up more steam and become the sane default that everyone just assumes. Instead of the current mess where everyone assumes that it's "normal" to live in this messy world of countless abstractions and frameworks and micro servers, etc.

> your normal dB driving some web-based CRUD app

That can totally be handled with SQLite.

That's the definition of not being conservative about adding dependencies.

I find the opposite to be true. If you casually add dependencies without understanding the dependency tree, you have a lot of problems waiting to happen.

I prefer to be conservative about adding dependencies, and to always manually include them into the project.

What's wrong with vendoring? You put the package you want inside the vendors/ directory. I think it's much better than a package manager that tries to download some version that satisfies some version specification in a file that declares dependencies.

for what?

I don't think this is a new idea, but anyway it's not a proper "open source" license.

I don't understand. Why does the exchange price vary across countries? The whole thing is online.

no, grunt is even worse.

You know, just a plain old script with all the build steps laid out sequentially:

feed this file to this command, pass these arguments, wait for command to finish, take output files and copy them over here .. etc.

Not really. The AGPL is what is supposed to counter that.

Initial setup is confusing. Users and rules are confusing. Taking backups and restoring them is confusing.

I'm not sure what is IPFS or Minio, but as far as I know, the go compiler always produces statically linked binaries that have no external dependencies. This is the default out of the box behaviour.

How so? I think it's quite the opposite. The GPL allows you to run your code on a server that clients connect to without you having to give them the code to your server.

This is the only way to profit off of GPL licensed libraries.

I remember playing with it many years ago when I was still naive and at the time had bought into PG's promotion of lisp.

The more you depend on things to be right in the target environment, the more chances you have of breaking things.

Having a statically linked binary will not always magically solve this, but it's a great step in that direction.

The other step is not relying on any external servers or services, e.g. postgresql, redis, etc.

The rest just boils down to programmer discipline. Never introduce something that can potentially cause a headache to the end user.

If you're building on an interpreted language, you can't really do that. You will always at least require the user to have a specific version of python/node/whatever.

This can get complicated if the user has a different version, so now you have to introduce a virtualization layer that can manage several different versions of the environment. These tools are always annoying to use.

Not to mention that some packages could have native dependencies (e.g. a python library having a dependency on a c library) and this is almost always a source of headaches.

The only problematic licenses here are the GNU family of licenses. This is very unfortunate but there's no way around it.

Luckily there are many many useful libraries available with very liberal licenses.

Which I think is a big mistake, because even if it ends up being used in a low traffic site, it ends up complicating the installation process. Where as a compiled language not only would run fast but also have a very simple setup: just copy over the exe and run it. Nothing to configure. No dependencies to install.

Why would I want to use redis?

My whole point is that I want to simplify my setup, so that I don't need tons of third party servers.

Do you understand what it does? Do you understand the common ways it can fail? When it does eventually fail, can you figure out how to fix it?

I think the problem is one of economics.

The SV culture made it valuable for startups to amass a large amount of users.

Where as before this bubble started, it was more profitable for development shops to build (and sell) software that anyone can use to host their own site/forum/whatever.

This might not be the entire solution, but I think it would be a step in the right direction:

We need more products that are developed for people to deploy on their own private servers. They have to have some very compelling points that I think are still lacking in many existing solution:

- They have to be really really fast. Nothing in "python" or "nodejs" or whatever.

- They have to be really really easy to deploy. No requiring a separate database server such as mysql. Just use SQLite. Also, no copying over of tons of files. Just a single executable. All other data should live in the database (sqlite file). Maybe have two database files: one for user generated content, and one for bundling application resources (images, etc). I'm not exactly sure what's the best setup, but something along those lines.

- They have to be profitable for people who develop them.

This is more of a cultural issue.

I love open source, but requiring all software to be "free" means that it's much more profitable to create a product for yourself only and try to lure as many users as possible, just like facebook.

To this end, I think something like the physical source initiative makes a lot of sense: if you buy the software, you have the right to make changes to it. But you don't have the right to also copy it and distribute it.

Redis is yet another dependency that you can certainly do without.

> I'd say that it's dynamic typing that has higher cognitive tax

Yes, that's exactly what I said.

It sounds like a chance for logical errors to go undetected before they cause issues somewhere totally unrelated.

I find this hard to buy.

Let's start with just one downside (which imo is the killer misfeature): startup time.

According to the OP article you have to read the entire xml before you can do anything with it.

Surely even if you weren't designing SQLite, it should be possible to design a binary format such that you can read relevant information quickly without loading and parsing the entire binary file.

> this is a program interchange format, not a format meant to be read by a person

So why is it xml? I mean this defeats the whole point. Not to mention how it adds a lot of useless noise.

If it's a program interchange format, it could at least be in binary.

Except that SQLite is a library that can be embedded into any program.

Yes, there's also a binary command line interface to interface with a db file, but that's not what SQLite mainly is.

Yes but if you use SQLite because you value minimalism you would also choose a language that compiles the server to a statically linked binary, e.g. Go, in which case this is a trivial "optimization" to do (if you would even call it that).

Last time I used MySQL was more than 10 years ago, but my impression from back then is that it's more beginner friendly and easy to setup and use than Postgres.

Which translates to: I basically don't want to use it. At least not for development. Not as a means to abstract away the setup of something like Postgres; Docker has its own complications when it comes to setting things up, which I must learn _in addition_ to learning everything related to setting up Postgres.

Docker is its own nightmare :/

I just find it weird and confusing.

Also, how do you setup a database in docker? Docker does not support persisting data as far as I know. So if you need to restart the thing, all the data will be wiped. At least that's how it seems to be.