Earlier quoted context omitted.
I agree it's silly, but sometimes ideas or POCs are silly but worth shipping. Don't you agree?
Worth shipping, but not worth investing massive amounts of time in. On the other hand, suppose you actually hoped to grow and make enough money on something to pay the salary of a few dozen people. Let's say you start with golang and sqlite3, ready to handle 1000s of people an hour, everything is going great, and then someone posts your thing to Hacker News (or it goes viral elsewhere). Suddenly you have millions of…
You don't need a database, a queue, a distributed system: Go is enough
31–37 of 37 posts
Re: You don't need a database, a queue, a distributed system: Go is enough
#32Title: You don't need a database. Half way down the article: The questions are stored in a sqlite database
Re: You don't need a database, a queue, a distributed system: Go is enough
#33Re: You don't need a database, a queue, a distributed system: Go is enough
#34If the data in your app doesn't matter at all, and you have no availability requirement, sure keep everything in memory. I don't see what Go has to do with it however, any language should be fine.
golang is very efficient memory wise. And it is easy to develop with. (Rust gods please dont see this)
Re: You don't need a database, a queue, a distributed system: Go is enough
#35> Let the scalability be a consequence of the success, not something that holds you back.
A large portion of my career was spent fighting the problems that come with "premature scalability."
Re: You don't need a database, a queue, a distributed system: Go is enough
#36I don’t disagree with the premise for very small applications, but > The quiz state machine is full in memory > The queue system for the matchmaking is in memory Means those will be nuked as soon as a new version gets uploaded. it really wouldn’t have been much extra work to put this into SQLite as well, and would lead to a much better user experience during updates
Re: You don't need a database, a queue, a distributed system: Go is enough
#37> We need to choose a database : so, let’s start with that. ...Wait, ten years ago the advice was that this should be one of your last decisions: your application should be able to work with minimal changes with any DBMS, and tying yourself to a specific vendor from the start was considered a bad idea. Did it change while I was not looking?