kukkeliskuu

Yes, I contradicted myself in that sense. I am not going to argument against your point.

But let me elaborate my approach which explains this apparent contradiction. Backend is needed in any case, and for me that is almost always Django. It is extremely fast to build traditional (non-SPA) CRUD apps with Django if you have only one model / one page. I can make a new one less than an hour.

If I need more interactivity or more data on the page, I use the same approach (models, views, forms with validation) but I create partial forms and return HTML fragments, instead of full pages. AlpineJS/HTMX allows me to implement 80% with Django/python, and I can avoid implementing a REST API and JSON serialization/deserialization, all the frontend data management, and there is usually almost no need for Javascript.

You distilled the point well. SQLite is great, but Postgres still hits the sweet spot.

I have worked on a database engine core team, and I really like the simplicity of SQLite and would love to use SQLite more. I am fully aware of benefits of the simplicity it brings to operations and I also know that the scalability of SQLite is more than sufficient for most of my use cases.

But I am running two major side projects I while still working full time. One of my side projects is a site with 2M page views per month. Additionally, depending on how you count (whether apps are included in the major projects or not), I have 3-4 smaller side projects, two of which use SQLite database.

To be able to run all of this, I have an extreme cut-throat approach to technology. SQLite is almost there, but ultimately Postgres is still more mature all-around solution. As an example, I believe (have not tested this though) it is quicker to set up full-text search for Postgres using online resources. The developer experience is better, because Postgres full-text search has been around for longer and has wider adoption.

This has been my experience as well with almost all frameworks.

It goes like this: the framework helps with the initial progress, because framework works with the more typical use cases. This allows you to "prototype" the solution and show progress to potential users etc.

But then you have a specific use case that does not fit the model of the framework, and you will end up going around the limitions of the framework. You often end up spending more time that you saved with the initial implementation.

My experience with core Django is that it has so many hooks and ways to inherit functionality, that it is extremely rare to end up with such problems. But it still means you need to learn when to use what feature, and how to structure your solution. I had to learn this through painful experience. I am still making mistakes, such as the "single-file status page app", a mistake which cost me several hours of productive coding. That might not sound like much, but when working full-time and running several side projects, few productive hours is extremely costly.

Most third party Django apps, even the popular ones, suffer from the framework problem, however. For example, I have have had to rewrite django-ads and django-distill, because their structure was limiting me from implementing features I needed. I just ditched django-formset as well.

I believe the reason for the limitation is that these third party apps have not been exposed to enough use cases and users to overcome the framework problem.

There are new frameworks all the time, but only very few establish a community that allows the framework to survive on the longer term. When you choose something that has been around for a long time, the probability for this is much higher, than for something that looks promising. Another benefit of the established frameworks is the amount of experience from various corner cases that has been coded in them. New frameworks often appear to handle simple use cases more conveniently, but that is only because they ignore all the complexity that the established solution has painfully learned throughout the years. You get that "for free" when you choose such a framework.

I am not going to argue with you about specific technology or use cases. But these are complex pieces of software, and the fact that you consider them to be "boring technology" is the reason why I was talking about "extremely boring technology".

When you are building software really fast, you need to take the boringness to the next level and cut all non-essential components.

At fly.io, hosted Redis costs over $100/month, when one server + Postgres is less than $10/month. This tells you about the complexity.

Many people use Redis with Django, because that is "obvious choice" for Celery. But either Django built-in tasking (or backport with django-tasks) allows you to handle most of the use cases (long-running tasks, timed events) when combined with a cron such as Superchronic.

Many people consider ElasticSearch as an "obvious choice" to handle full-text search, but Postgres can handle it in most cases.

Mostly, if you have problems that require "webscale solutions", then you will have a team building a dedicated solution anyway.

In recent years, I have learned how to build sufficiently robust systems fast.

Here are some things I have learned:

* Learn one tool well. It is often better to use a tool that you know really well than something that on the surface seems to be more appropriate for the problem. For extremely large number of real-life problems, Django hits the sweet spot.

Several times I have started a project thinking that maybe Django is too heavy, but soon the project outgrew the initial idea. For example, I just created a status page app. It started as a single file Django app, but luckily realized soon that it makes no sense to go around Djangos limitations.

* In most applications that fit the Django model, data model is at the center of everything. Even if making a rought prototype, never postpone data model refactoring. It just becomes more and more expensive and difficult to change over time.

* Most applications don't need to be single-page apps nor require heavy frontend frameworks. Even for those that can benefit from it, traditional Django views is just fine for 80% of the pages. For the rest, consider AlpineHJS/HTMX

* Most of the time, it is easier to build the stuff yourself. Need to store and edit customers? With Django, you can develop simple a CRM app inside your app in just few hours. Integrating commercial CRM takes much more time. This applies to everything: status page, CRM, support system, sales processes, etc. as well as most Django apps/libraries.

* Always choose extremely boring technology. Just use python/Django/Postgres for everything. Forget Kubernetes, Redis, RabbitMQ, Celery, etc. Alpine/HTMX is an exception, because you can avoid much of the Javascript stack.

Thank you.

I am not too familiar with Catholicism.

But all major religions have multiple strands, and like others, Catholicism also has one or more mystic strands as well. Mystic strands of different religions are thinking man's version of the religion and actually closer to each other that you would guess from the surface level understanding of the religion.

Probably you can find people who believe what you are saying. People believe in strange things.

But if you want to have an intellectually honest discussion about this, you should first try to understand clearly the best possible arguments of the thing you are critisizing.

That is why I asked whether you are interested in understanding the religious point of view. What you are presenting is kind of a straw man version of Catholicism, and I imagine on site like this you will have hard time finding anybody willing to argue about that.

Note also that I have not anywhere said anything about what I believe. I have explained to you a kind of short version what is my understanding of the synthesis of Christian mystical traditions.

Yes, I can understand it feels to you like I am side stepping the argument.

The "evil" in the paradox above (I am not responding to Epicureus but to the quote, which is presented out of original context) refers implicitly to a very limited, modern definition of the term, as your examples show.

All the religions that I have some understanding of, have much more elaborate understanding of the question of good/evil. But each religion has a unique view point of this question, so we cannot generalize these terms. I just gave one example.

The paradox is a false dilemma. In my understanding, such dilemmas are often set up within religions as tools to help you to think things through for yourself, they are not refutations of the religion.

I am not trying to refute an argument or convince you of anything. That would be pointless.

I don't consider earthquakes to be "evil" by any sensible definition. But the question "if God exists, why did he create a world with earthquakes" is an interesting question. I don't have any idea how any religion would approach this question.

If you are really interested in what religions can offer you, you can take a look at the feeling that arose in you when reading my reply.

You said you felt that I was side stepping the argument. To me it seems that it was partly because you thought that I was trying to refute an argument. You also missed the part where I said "Much of which we think of as ..."

This being HN, you can think of religions as methods to hack your own thinking. You can use such feelings (and the fact that you miss some key points when you discuss the issue) as a signal for yourself that there is a subconscious emotional issue related to the question. You can learn about yourself and grow through studying these issues.

There are multiple potential answers to this basic riddle in various religions. Are you interested in understanding them?

For example, we can say that while God is omnipotent, he has chosen to create a world with humans who have the possibility of choosing to be good -- your word -- or not -- and grow through this choice. A world cannot exist where the "evil" is prevented, unless you also take away the the agency from humans and this potential for growth.

Much of which we think of as "evil" is actually consequence of things we do. One simple example in modern terms is that we tend to repeat the same unconscious patterns over and over again.

We often do it because we have a trauma maybe from childhood -- that we are not conscious of. If I get a physical trauma, muscles around the traums tend to form a tension to protect the site where we get hurt. These often become chronic even after the wound has healed. We have many such chronic tensions in our body.

Similarly, when we get a physical trauma that is too unbearable for us to process, we create tensions around it that protect us from experiencing it.

These patterns we repeat cause much of our suffering. By becoming more aware of our wounds, they can start healing, and we can start becoming free of such suffering.

Our "work" is to learn about ourselves, to overcome these traumas, and heal our wounds. In such a case the "evil" we see is actually a reflection which is necessary for us to become aware of these things in ourselves.

"Battle" was (if I remember correctly) the term used by Stonebraker in his 2001 SIGMOD keynote to describe what happened at that specific SIGMOD in the 1980s. It is not "only in my head". Like I said, I don't care what other people store data in.

I don't think MongoDB is going anywhere on the medium term, and there is always going to be some customers. Just like the network databases in the 70s, or XML databases in the 90s.

Bad ideas never die, they just resurface in another form, which people label as "new".

https://db.cs.cmu.edu/papers/2024/whatgoesaround-sigmodrec20...

Around 20 years ago I was working for a database company. During that time, I attended SIGMOD, which is the top conference for databases.

The keynote speaker for the conference Stonebraker, who started Postgres, among other things. He talked about the history of relational databases.

At that time, XML databases were all the rage -- now nobody remembers them. Stonebraker explained that there is nothing new in the hierarchical databases. There was a significant battle in SIGMOD, I think somewhere in the 1980s (I forget the exact time frame) between network databases and relational databases.

The relational databases won that battle, as they have won against each competing hierarchical database technology since.

The reason is that relational databases are based on relational algebra. This has very practical consequences, for example you can query the data more flexibly.

When you use JSON storage such as MongoDB, when you decide your root entities you are stuck with that decision. I see very often in practice that there will always come new requirements that you did not foresee that you then need to work around.

I don't care what other people use, however.

I don't have any experience in Rails, but similar experience with Django. I am running several apps on my own, while still working elsewhere full-time.

The largest one has around 250 views, of maybe 80 are just basic admin views. It is basically comparable to an ERP of a medium-side company with various levels of permissions etc. I was able to get most of the functionality into production in just one month -- I was not working full-time at that time. I have estimated it with some friends, and such an ERP in the corporate world would normally take a team two years to do -- one to spec and another to implement.

It has 1-2M monthly page views depending on the season, and the highest hitting pages are read-only and heavily cached, so the server load is minimal. I am further increasing the performance by making those pages static HTML using django-distill and using Cloudflare to cache/serve them.

The key thing is to keep things as simple as possible. I avoid REST/heavy frontend frameworks whenever possible. For most views for most apps, normal HTML form request-response user interface based on Bootstrap is perfectly fine.

I started by sprinkling Javascript when it was really needed, for example client side sorting so I can avoid server load. Now I use AlpineJS/HTMX for the interactivity. It has been great, although much slower to implement.

Interesting, did not know that you have HN meetups in Finland. I am quite busy but maybe I could drop by sometime!

No, it is not public at the moment, although I am/we are looking for pilot customers especially interested in getting ISO27K compliance.

It is very interesting. I am very surprised how well it worked out.

One idea I have had for years is that it would be great if file system would support structured data.

This would combine well with your idea.

So let's say that I change python source code, the "file system" would understand the syntax of python source. Your tool could then use this to derive the sematics of my change, i.e. "added a function foo() with the following signature and body"

(1) Business process modeling tool where processes are data and not graphs. I am doing it according to the USM method. USM is kind of "open source" service management method, although it works on different level than other frameworks and standards, and is compatible with all of them.

This makes it possible to create a kind of requirement "programming language" where the requirements can be evaluated. With this language it becomes possible to create cross-references from various compliance standards/frameworks, like ISO27K, to USM, and automatically evaluate the compliance.

(2) Dance event calendar in Finland, running in production for over a year. 1-2M page views/month. Django app, but I am now implementing a copy of the unauthenticated user views to S3 bucket and delivering it through Cloudflare.

(3) Django app to handle all the data related to custody trial. Emails, SMS, notes, official records, voice memos, etc. can be attached to a timeline, and tagge and searchable. It has command line interface for adding data, in addition to UI, so I can quickly add notes and attach files.

It is more probable that people who have used it more have a more realistic and balanced view of their capabilities, based on the experience. Unless their livelihood depends on not having a relalistic view of the capabilities.

The raw data was whatever came from the individual source systems. Mostly these were external systems. As we are talking large organizations, there are always various kinds of problems with the source data. So the aim was to bring it all together under a single, shared data model. It was very helpful to use internal DSL for defining clean models, we called it the canonical data model.

I re-built a dance event web site one year ago with Django. The site was implemented by somebody else 15 years ago. It has 1M-2M page views per month.

Now I am building into it some features so other people can help me to run it, such as ticketing system (with AI), and statically generated copy of the site to improve availability.

I am also working on a service management tool, based on USM method. USM method is kind of "open source" version of ITIL, although it works on a different level than ITIL.

I have done similar for a few customers. I have found that useful pattern is to have both raw queues (incoming data) and clean queue (outgoing data). Outgoing data in single queue only (so all changes are ordered, so we avoid eventual consistency) that has well-defined data model (custom DSL for defining it) and tables/REST api that corresponds 1-to-1 to the data model. Then we need mappings from raw queues to the clean queue.

Doesn't the same difficulty of finding the first case also apply to the wet market theory?

"is are" => "are no"

Border patrol and passport checks exist in many places in the EU, including in my country, but in the public debate, the expression "open borders" refers to the fact that the countries cannot for example choose whether to turn away non-national asylum seekers, even if they are arriving from other safe EU countries, are clearly originally from safe countries but have "lost" their passport, lie that they are 10 when they appear as 18 etc. Other countries turn such people away, but our politicians claim it is not possible. Of course it could also be that our politicians follow the regulations more carefully than politicians in other countries. However, as Italy has not been able to control their border either, and italian politicians are not famous for following the regulations meticulously, it is more likely that there comes some heavy pressure from the EU.

EU is much more than a trading union, to these people EU represents giving up on the sovereignity of your nation. I have not read that anybody would be opposed to trading. They were and are opposed to giving up on sovereignity, and against the laws passed as a consequence of that, but not against trading with other EU countries.

There are other trading unions and agreements that are possible besides EU, and it seems like EU has prevented UK from re-establishing the trading unions and agreements it had prior to joining the EU.

We can only speculate why, but it seems plausible and rational that EU is doing this as kind of a punishment and warning to other nations considering leaving the EU. UK benefits more from these agreements, while EU benefits less from these agreements.

On the other hand, EU is under an existential threat, and will disintegrate if other nations follow Brexit. So it is kind of rational (albeit only for the short term) for the EU leaders to think that EU benefits from preventing these agreements from happening if it prevents or hinders the disintegration.

We cannot know what really happened, but we can look at the end result. Britain wanted to leave EU, not quit trade. Britain has worse trade agreements than before joining the EU.

I have not reviewed all the arguments.

One is simple. EU does not have a single language. There is are shared values, shared vision, shared culture, or shared identity among regular people.

The cards are stacked against EU being succesful.

Why do you ask? One often encounters an argument that if I cannot make up a rationale that you consider as reasonable, then it means I am wrong. The problem is that the polarization means that neither side can rationally understand the argument of the opposing side. The fact that you don't consider the argument of these people as reasonable does not prove anything.

GP claims that he has not met anybody who is against EU but presented statistics that only 60% support EU.