Simple-twitter: A bare-bones Twitter clone implemented in a single file
github.com
github.com
Why can’t the world move in that direction, instead of the insane Kubernetes hype that’s prevalent these days?
---
My problem with Kubernetes is people adopt it without understanding it. They adopt it because everyone else is without ever asking, "Why?"
I've installed and managed a simple K8s cluster before now and it was a nightmare (this was only a year ago.) It wasn't until we moved the management of the cluster to a managed service that it became worth it. It was at THAT point it was worth containerising the application(s) (another complexity to overcome) and letting K8s handle the deployment and scaling.
I'm worried that as an engineering culture we're not pushing back enough and saying, "Yeah K8s is cool but look: do you really need it? It's very likely you don't". For me to automatically recommend K8s to my clients I'd need to see a (near) zero friction deployment options that's fully feature compliant and truely fully managed. It's at that point I would be happy to say, "Sure! Let's go with K8s and just write YAML files to deploy our containers!"
(And then there's the whole debate as to whether or not you even need a container around your monolith... probably not. Then the next debate about people starting out with microservices when we all know that's not a good idea.)
I definitely think there is a misunderstanding about what Kubernetes solves. I think Kubernetes is very good at helping structure very large applications where a split of micro-services makes sense.
Most start-ups don't need it - it's likely overkill, and unless you go with a vendor you're likely to set it up incorrectly. But it is an advantage in much larger, spread out teams if the culture surrounding all the teams makes sense.
If sub-teams can handle their applications really well, which many companies have achieved, then it does provide significant benefits over monoliths.
I think the problem you're noticing is that everyone wants to jump onto Kubernetes without realizing why it's even there - the same with micro-services. I shudder when I hear that from my friends with no more than 10 people on their development team, but I think it makes a lot more sense when I see teams of >200 complaining that their huge monolith is what causes the most friction.
It's an excellent piece of kit, but like most tools it has to be not only used correctly but also in the right context.
That, and the fact that it seems like you need to adopt about 100 completely heterogeneous tools to successfully manage a Kubernetes cluster.
And honestly, I’m digging it. It’s really cool stuff and once you get developers writing production services and applications that would otherwise have been virtualized on dedicated systems on it, they love it to for their speed of delivery and development. But we’re also managing hundreds of projects with multiple applications/services with high availability, so OCP/Kube makes sense for us.
---
My problem with Kubernetes is people adopt it without understanding it. They adopt it because everyone else is without ever asking, "Why?"
I've installed and managed a simple K8s cluster before now and it was a nightmare (this was only a year ago.) It wasn't until we moved the management of the cluster to a managed service that it became worth it. It was at THAT point it was worth containerising the application(s) (another complexity to overcome) and letting K8s handle the deployment and scaling.
I'm worried that as an engineering culture we're not pushing back enough and saying, "Yeah K8s is cool but look: do you really need it? It's very likely you don't". For me to automatically recommend K8s to my clients I'd need to see a (near) zero friction deployment options that's fully feature compliant and truely fully managed. It's at that point I would be happy to say, "Sure! Let's go with K8s and just write YAML files to deploy our containers!"
(And then there's the whole debate as to whether or not you even need a container around your monolith... probably not. Then the next debate about people starting out with microservices when we all know that's not a good idea.)
If any of them could drive the Nix project from within their own walls we would be going that route.
NixOps is a great tool..when it works. When it doesn't, it's not inherent. It's just that it is clearly not heavily invested in by any entity with a bunch of money.
And for 500,000,000 people.
1. Run anything anywhere (no platform lockin)
2. The ability to talk about your arch using a shared dialect
3. Tooling that integrated with the API server for everything storage and DB (things like Rook), networking and security (CNIs), observability (Service Mesh), and many more abstractions.
Kube is the low level dialect. The tooling around it makes it work like you want.
You're still tied in to the platform, or you're likely not doing too much.
I've installed and managed a simple K8s cluster before now and it was a nightmare (this was only a year ago.) It wasn't until we moved the management of the cluster to a managed service that it became worth it. It was at THAT point it was worth containerising the application(s) (another complexity to overcome) and letting K8s handle the deployment and scaling.
I'm worried that as an engineering culture we're not pushing back enough and saying, "Yeah K8s is cool but look: do you really need it? It's very likely you don't".
For me to automatically recommend K8s to my clients I'd need to see a (near) zero friction deployment options that's fully feature compliant and truely fully managed. It's at that point I would be happy to say, "Sure! Let's go with K8s and just write YAML files to deploy our containers!"
(And then there's the whole debate as to whether or not you even need a container around your monolith... probably not. Then the next debate about people starting out with microservices when we all know that's not a good idea.)
Isn't that what the managed kube offering you switched to gave you?
Managing your own kube deployment is very easy if you are only worried about that component.
> I'm worried that as an engineering culture we're not pushing back enough and saying, "Yeah K8s is cool but look: do you really need it? It's very likely you don't"
The benift in kube isn't the cluster management. It's the abstractions. Let's say "I don't need kube." Now we need to have this series of conversations...
- "The client said we need to make sure the site doesn't go down during deployments."
- "Can we deploy something that needs to be rolled out, restarted, upgraded, and use persistent disk" (like MySQL)
- "We need to monitor some metrics from the machines"
- "We need to scale the number of machines based on system utilization."
- "We need to hire an engineer to manage our infrastructure, so we need to bring them up to speed with our tooling"
- "We need to switch from cloud A to cloud B to save x/year"
- "We need to run on two clouds to fulfil some legal requirements"
There are all documented, standardized, and hireable (engineers already know it) tooling to do. Also it's all declarative so it's just YAML and no magic needed or manual management.
That's the magic of kube. That, the tooling, the shared vocabulary (no ramp up time for engineers), the platform Independence, the automatic scaling, the network security features, and the ability to define your own internal constructs (CRDs).
There are a limited number of people who actually have a use case where they want to manage their own kube cluster. Most people would be happy if they tried a managed kube cluster like GKE [0] and DO [1] for example.
If you are managing your own cluster from scratch you're likely:
- At a company with huge sets of bare metal machines
- A massive organization that can afford to hire infrastructure experts to optimize every penny out of their cluster ops by vertically integrating their cluster management (rather than outsourcing to something like DO).
- Hobbyist who wants to learn how kube fits together.
If you're not one of those three then all you need is to setup Rook, setup some autoscaling component, pick out a few DB operators, setup monitoring, and setup a logging infrastructure. Compared to older solutions for similar things the "kube way" is a pre-planned roadmaps with minor choices along the way that are mostly personal preferences that weigh: "how much to I care about security", "does this need to be more or less debuggable", and more.
If you need a cluster, want a "managed-like" experience, then just go with Kops. If you just need a cluster to run your applications on just go with GKE, AKS, DO, or another offering.
0 - https://cloud.google.com/kubernetes-engine/docs/concepts/clu...
1 - https://www.digitalocean.com/docs/kubernetes/how-to/autoscal...
Sure you can emulate a declarative view on top of a mutable thing (Think React and virtualdom), but having a declarative core makes declarative deployments easier to manage and more elegant.
E.g. in Kubernetes automatically deleting a resource is still hard; It's hard to figure out when something is not "used" anymore.
In nix, you simply run `nix garbage-collect` and all the things that are not referenced by your declaration are automatically deleted.
Also it looks "beautiful" to your eye, from a programming perspecting it looks really un-readable if you don't use FP.
https://github.com/Gabriel439/simple-twitter/blob/master/Mai...
I don't mean this as a slight, and I myself am slacking in the same regard, but it's depressing to me that this attitude is so prevalent among professionals.
There might be some good engineering reasons that tools like Docker and Kubernetes have much more traction than Nix, but "it's unfamiliar if you don't use FP" is a terrible one. It doesn't require that much investment to become familiar, and there seems to be many fantastic advantages to functional approaches.
Why does our industry tolerate this laziness?
I get the sense that there is a large contingent of programmers who feel disdain for mathematics and FP gets caught in the crossfire. It’s unfair toward both mathematics and functional programming.
I would love it if North American culture could adopt a better attitude toward mathematics in general. I think far too many people decide they’re bad at mathematics at some point in high school and never look back. This attitude is far less prevalent in many Asian cultures, where the emphasis is put on hard work instead of talent.
I can't parse this - would you care to expand on it?
> 3blue1brown is preaching to the choir AFAIK. I get lost trying to watch his videos as they also expect you already know the material.
If you care, you can always track back to earlier material and build your knowledge. Most people I know in a similar situation to yours don't actually care, and won't actually put in any effort.
And that's a reasonable choice. There are places where math is hard, needs work, and most people have come to a point where they feel that the effort won't be worth it, that the ROI isn't there. But if that's your decision, then own it.
If that's not your decision, and you actually want to know more, there are things you can do about it.
FWIW, I know a lot of really good math teachers, but I agree that there are also some really poor teachers. If yours were bad then I feel bad about that, although there's nothing I can do about your experience in the education sector. What you do about it now, if anything, is up to you.
This is the realisation I had (20 years late). Especially beyond high school, maths is hard. You have to put the effort in, and you have to do the example problems.
I think its expressiveness and conciseness makes it more dispiriting to study: one page of a maths textbook can contain so much information, and it feels like you're just stupid when it takes an hour to understand that page fully.
This is very important. Apparently some people get frustrated by this because they are used to studying lower-information-density textbooks. Maybe there would be value in teaching these meta-skills, like how to approach learning each subject. People may apply techniques, like rote learning or brute-force cramming, reading the same page for hours on end, expecting to magically grok it, where these are ineffective of even counterproductive. Not sure how well this is teachable though.
- illustration — whether drawings, gestures, animations, using objects, whatever works, but have a visual equivalent to 'translate' notation; the typical example would be fractions which are as simple as it gets with drawings and hard as hell using only numbers, for most people discovering them. The same is true for most common functions and transformations (which, when you reduce it to the maximum, are the entire body of applied math).
- real-world application (typically the best candidates are simple physics or statistics in high school). The point here is to give a point of reference, a "feeling" of the mechanism or logic or paradigm. The deeper problem is that this application must feel 'interesting', like a puzzle, and not everyone is interested by the same things. That's where, imho, narrow AI could help craft customized courses with ad hoc examples that fit people's "world view" and "approach" to problems, and show animations for every variable, equation, let people play with those and see the results.
Both probably fit in the "faster feedback" approach, i.e. have the teacher/teaching material give feedback as fast and as often as possible, to guide the learning mind on the right path. This is an extremely important discovery of UX in the last 50 years and I believe education has much to learn from these very applied insights into human cognition.
This approach breaks down when you go into higher math. You end up working with these abstract objects that have no visual representation. You may be able to find an equivalent object from geometry or graph theory, but it may be so complicated you could never draw it. Heck, even basic shapes like the Platonic solids are difficult to visualize, let alone draw, correctly.
I solved a problem recently requiring me to count the number of vertex colourings of an icosahedron, up to rotational symmetry. Trying to draw one of these things and visualize all of the possible rotations was basically impossible for me. I ended up loading Blender and playing around with one in 3D, using the coordinate planes to see all the axes of symmetry.
If I had been given a higher dimensional object like a tesseract then all bets would have been off. I would have had to find another approach entirely, likely algebraic.
It doesn't have to be literally visualization. Just some "feeling" for the objects. Some conception of them as actors, actees, things interacting, or having emotions or whatever. Again, whatever works. Maybe some people can work with concepts just based on strictly memorizing the definitions and drilling through proofs, but others need to conceptualize it all into a narrative. I don't mean dumbing it down, but making it easier to "grab" mentally. Hard to describe.
The problem with math is that it's seems much harder than it actually is. Every time I have to look into some specific math I haven't worked with before I spend a lot of time decoding what they actually mean. Usually what is happening is not that difficult at all, mathematicians just insist on writing it down in the most convoluted and incomprehensible way imaginable.
It's like they took every bad coding practice and applied it all to math. Why have descriptive variable names if you can just use random greek letters ? Why give a function or operation a name at all if you could make up some weird symbol instead ? And of course you want those symbols to have different meanings depending on context. Imagine if programmers worked like that and wrote everything as obfuscated C++ code, because fuck you.
This is a common complaint I see from programmers all the time. However, I've seen people trying to do real maths with descriptive names, and it fails very, very quickly.
This is by no means comprehensive, but as a (probably thought) experiment, try writing reasonable complex code without variable name completion. You write the same variable name over and over and over, and after a while you realise that since this variable is only use in this screenful or two of code, it's easy enough just to use a short name and know what it is, because you're only thinking about it here, in this context.
I'm not going to try to defend mathematical notation in general because there are enormous inconsistencies, many of which are historical, accidental, and indefensible.
But when you're doing the maths it becomes tolerable, then usable, then actively helpful. It's like the parentheses in Lisp - all newbies complain about them, and those versed in the art know that after a while they not only don't matter, they are a genuine positive.
But unless you take the time to do the math, that won't happen for you. That makes it sound like a deliberate barrier, but it's not, it really isn't.
So why don't math tools have variable name completion ? and/or why insist on still doing things on paper in 2019 ?
The other things about variable names is that they force you to think about what a variable actually contains. This in itself is very helpful not only for others reading your work, but also for yourself when trying to grasp a problem.
But your everyday research mathematician will just stare in disbelief.
I don't know your background, your profile is empty, but it sounds like you are someone who genuinely has no idea of how research in math works, and therefore feel that you really must have a better way of doing things. And maybe you have. But speaking as someone who has a PhD in pure math, and who has worked in safety critical software, I can only say that so far everything you're suggesting just really doesn't make sense.
The reason that for centuries mathematicians use single letter glyphs to represent the things they're dealing with is because it is, for the purpose of doing the work, the most effective thing to use.
I'm not talking about computer assisted proofs or anything like that. Just using a readable syntax and the mathematical equivalent of a word processor would be an enormous step forward. No one is writing books in cursive with a fountain pen anymore either, which is basically analogue to what mathematicians are still doing.
No, I'm not talking about proof assistants either, I'm talking about actually doing math using any kind of computer system.
> Just using a readable syntax and the mathematical equivalent of a word processor would be an enormous step forward.
Do you have any idea of how to do that? I've done research in math, and I've written software for safety critical systems. I don't know how to create a system like a word processor for math that would let me actually do the math.
Do you know how to do that? If so, please, let me know.
Because math is abstract. The variables and constants don’t mean anything in most cases and are only given different symbols to distinguish one from another. Descriptive variable names or even descriptive subscripts get OLD very quickly when you’re working through a page of calculations to solve a problem.
The beauty of math, if you’re using it to solve some real world problem, is that you can forget about what the symbols mean and focus on solving the equations, evaluating the integral or derivative, or whatever other calculation you’re doing.
Once you’ve completed all of the calculations and gotten your answer simplified as much as possible, then you can go back to the problem you were trying to solve and interpret your result in context. Since you’ve done all of your calculations purely symbolically, you can see the relationships between the quantities you’re working with. In many cases, some quantities you thought were important actually cancel out and don’t appear in your final answer at all. This tells you something fundamental about the independence of your quantities. Perhaps the most famous case of this comes from physics: the acceleration of an object in free fall is independent of its mass. You would not see this so clearly if you substituted numerical quantities as soon as possible.
Don't they really mean anything or are mathematicians just unable to grasp what they mean ? To me this seems like a symptom of an underlying bigger problem in our understanding of math rather than those variables not having a meaning.
That's just a name. You don't need to know the etymology to understand the topic at hand. But if you want to know, you can think of co-efficient as "together-effector". In 3x, 3 is a coefficient of x, as it's something that "acts together" with x. There isn't really much more to it. You don't understand concepts by studying their names in much detail.
Another thing to get used to is that the same word may be used for different concepts in different contexts (or different words for the same thing). Often there is very little connection between them. You have to accept this as a fact of history. You can of course try to look for connections, but don't get frustrated because of not finding any. And some concepts are just badly named. Naming things is hard. Don't try to deduce things based on the names of things. Learning to understand names as just labels is an important step in acquiring good abstraction skills necessary for math.
I think this may be an issue for certain people that they approach math from just the wrong angle. The jargon and terminology is of course important for understanding of the content, but the prerequisites are not really lingo-understanding, but concept-understanding. Unlike in other fields, you don't learn math by pouring over the text and reading page after page. You read something and try to understand it. You play with it, you stand up, take a walk and try to work out why something is the way it is, think of examples, try to clear up what you don't quite get. You cannot use the same learning tactics that you'd use for, say, accounting or humanities. The pages read per hour is pretty low in math.
Absolutely this. Math is a not a spectator sport, you can't acquire the skill and knowledge by reading. You must engage with it, fence with it, wrestle with it, make it your friend and spend time with it.
I remember not so long ago playing with some equations and accidentally proving Pythagoras' Theorem. It wasn't new, it wasn't deep, but it was satisfying, in much the same way as getting code to perform as you want, accomplishing some task in an elegant way.
But if you don't spend the time, you'll never get the insight(s).
I sometimes even think (though I'm not so sure) that having too good textbooks can be an impediment for above-average students as they have less to wrestle with and things are laid out and pre-disgested too much. I may be wrong though, because you can then just get to the next levels until you hit the wall.
But I feel like anecdotally I got good value from deriving some basic things and reorganizing the somewhat badly presented materials in some of my classes. Later on I found very good American textbooks (although widely out of the reach of my wallet at the time), from MIT etc. which were crystal clear in some of the intuition that I had to sweat out for myself. Maybe I could have spent that energy at higher levels, though.
The difficulty of a student is knowing which book is good, and which could be doing a better job at teaching.
Is it a difficult subject or do you need a better book?
I learned more about trig working out what angle I needed to input in some design software to make a line cross two exact points than I ever did in high school.
I'm very much a visual learner so I find geometry in particular very satisfying since I work out relationships visually (and then mathematically to prove it).
This also applies to computers. Just get your hands dirty, try to build something and you'll find yourself learning about so many things and tools incidentally while trying to fix something.
I can learn much better this way than going chapter by chapter in a book.
But interestingly, even graded, project-style assignments don't accomplish the same effect, only if I'm really onboard with the topic. I seem to need a spark of excitement of "this is not exactly the way you're supposed to be doing things" and just breaking things and playing.
I can pick something up very quickly when I have an actual reason to know it, and getting a good grade in a course is not a strong enough reason compared to “Learning this will help me save the world”. I’m not going to be passionate about it or inquisitive or asking myself the extra questions I normally ask myself when I’m learning something in order to apply it to a problem. And real problems are better than made up problems.
I’m hoping to change this, not for all high school students, but for those I meet. I’m majoring in pure mathematics with a teaching option right now. My current plan is to teach high school algebra and calculus, as well as physics.
The other comments are right about terminology. I have no idea where the word coefficient comes from, yet I use them every day and understand them pretty well. At the moment, I’m studying ring theory, ideals, quotient rings, and ring homomorphisms and isomorphisms. Trying to figure out where these abstract terms come from may be interesting but it doesn’t help me in my proofs at all.
If you want to understand anything in math, the best approach is to read the definition, read some basic theorems, look at a few examples, and then start playing around with these things to get a feel for them. Try to prove some of the basic properties of the object you’re working with in terms of the axioms. Keep going, proving larger and more complicated theorems, and try some exercises that apply this knowledge to solve counting problems or measurement problems. If you’re learning about isomorphisms then look at some examples and try to understand how classes of object relate to one another, for example by having the same structure in their operations.
If you’re not able to understand 3blue1brown’s videos then you might benefit from using Khan academy to build up your understanding of the fundamentals. It has material stretching from grade 1 to college. Solving problems feels like playing a game, so it can be fun to sit there for hours just doing the problem sets.
Math is a deep, deep subject but it doesn’t require memorization. It just requires lots of effort and struggle in order to develop mastery.
As someone with a mechanical engineering degree with minors in math and physics I would have loved to have been exposed to this while I was learning the stuff.
For you. But I think this is far from being a given. At some point programming is a complicated thing and both OOP and FP get weird in their own ways.
I wonder, are there toy FP languages for kids, like there is a ton of imperative ones? If not, maybe there is an opening ?
It requires a lot of investment to become familiar.
I've found this mischaracterization very common among people who are proficient with FP: they forget where they came from, how long it took them to get familiar with all these concepts (the Haskell syntax first, then the FP mindset, then advanced concepts like monoids, functors, applicatives, monads), etc...
I do a lot of I/O and there are arguments against FP in those scenarios.
I think imperative programming languages with functional addons often result in better applications from what I have seen. They are also just simpler to write and may net faster code.
The assertion that not having in depth knowledge about functional concepts is lazy is lazy.
Nevertheless, it has its use cases.
It downloads, installs, configures, builds and runs from your declarative description. This is my understanding of how nix works anyway.
sign me up
ORDER BY tweet.time DESC
Sure, not the best short-hand, but it seems most people understood what I meant.
For example, https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Like this submission: https://news.ycombinator.com/item?id=20184282 where people will shorten the "evil" to just "the algorithm".
Best I can come up with is it'd make promoted comment more apparent?
But yeah, I wish a simple timeline was the default, and twitter stopped switching away from it.
For example, if someone follows two people and one person simply tweets at 1000x the rate of the other, I would argue that it would be better UX if the rare tweet from the other person gets more weight.
Another thing Twitter does is show you popular things that have been liked by the people you follow. It might be way too much to show you every thing that every person you follow has liked every time. But it can introduce some interesting content to your stream to see such second-tier content.
I don't see how promoted content plays into it since you can interpolate it anywhere.
Also, it's just a very premature optimization in a world where CLUSTERED INDEXes exist. The database engine doesn't have to cluster by primary key, it can cluster directly by time (or any other index) if you ask it to. The power of doing it that way is that you can flexibly change it based on real performance issues (how do your execution plans look?) and characteristics (are you read heavy or write heavy? which ones are your bottle necks?), whereas if your application makes assumptions about ID format it's a lot harder to on-the-fly tune queries that all need to be rewritten.
> The best person I knew told me to index if a column wasn't unique, but also wasn't something with only two or three choices.
Yeah I think this is too broad advice, and you need to understand what you want to achieve. Mentally, choosing indexes is like choosing whether to use a hashtable vs. for loop vs. binary tree etc in an algorithm in code. There is not golden rule or "always use a hashtable if there are 100 entries" type thing. You just need to figure it out on a case by case basis. And usually there are only 2-3 tables in your DB worth a lot of effort in figuring it out!
It has that and more!
Open source - https://github.com/kgthegreat/sensible
It's fair to argue auth should be included in a nontrivial example though. I honestly don't think it would add that much clutter either. Although unlike the other components, I don't know if there's a simple off-the-shelf Haskell solution for auth.
Easier to work with -> fewer people needed -> fewer people hired -> fewer people learn -> fewer people know.
Now there's fewer people in the market who know Simple, vs many people who've learned OverEngineered (TM). Leadership wants to pick a language/style they'll be able to hire for as-needed. OverEngineered has a much larger talent pool.
import Database.PostgreSQL.Simple.SqlQQ (sql)
...
let index :: Handler Markup
index = do
tweets <- query_ [sql|
SELECT "user".name, tweet.contents
FROM "user"
INNER JOIN user_tweet ON "user".name = user_tweet."user"
INNER JOIN tweet ON user_tweet.tweet = tweet.id
ORDER BY tweet.time DESC
|]- there are fifteen LANGUAGE directives (what do they all bring?)
- there's an ungodly amount of ASCII-art: What do any of these do, and in which contexts: ! @ :> :<|>
And so on: just three things that caught my eyes looking at the code on my phone
Servant (the routing library being used here) has pretty great and clean authentication support. https://docs.servant.dev/en/stable/tutorial/Authentication.h...
As for validation of input, what do you mean? Haskell tends to excel there as well, with the availability of parser combinator libraries like Attoparsec.
> LANGUAGE directives (what do they all bring?)
In a real project you hide these in a config file for your project. They're usually well documented, and you can usually guess what they're doing from the name once you have some context.
> What do any of these do, and in which contexts: ! @ :> :<|>
All of those except @ are just functions or types. You can look up what they do in the same way you would look up what any other function does. @ is the only one that's a syntactic operator, and it has 2 meanings depending on context. It's either specifying what a type variable should be, or it's pattern matching and binding a name at the same time.
etc. etc.
You're not helping the cause of "this is 99% readable" ;) If you add proper authentication and parser combinators [1], and configs, and.... It becomes anything but readable to a person without specific Haskell and very specific library knowledge.
And yes, I do have exposure to FP having worked with Erlang for a number of years.
I also seriously detest the unexplained love for ASCII art among many lib authors in the FP space. Servant is one such example: :> :. :<|> ! At this point, why not use J :)
[1] By the way, unless I'm mistaken, there's next to zero useful documentation on Attoparsec, there's only barebones package documentation. And no, you don't validate data using parser combinators unless your data is only strings that resolve to some DSL.
1 - https://github.com/dom96/nim-in-action-code/tree/master/Chap...
https://github.com/gothinkster/realworld
It's pretty easy to tell which frameworks are mature and which are not simply by looking at how many wheels that need to be reinvented.
Laravel, for instance, has so many really nice wheels, but it's organization can feel restrictive at times.
web.py, on the other hand, has basically no wheels but I can drop into a project really quick.
Maturity is a spectrum, and sometimes you don't need a wagon when a bike will do.
It would be awesome if Nix, NixOS and NixOps replaced the current mess that is Docker and K8s.