One painful one that is still reverberating a bit in some areas is the renaming of "SafeConfigParser" to just "ConfigParser" in the standard library (in 3.12). This caused a whole lot of breaking in some areas because versioneer (a package for determining a package version from git tags) used it (in code that was placed inside your package, and so couldn't be solved by just upgrading versioneer).
Python 3.7.9 (default, Aug 23 2020, 00:57:53)
[Clang 10.0.1 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cgi
>>>
Python 3.13.0 (main, Oct 8 2024, 01:04:00) [Clang 18.1.8 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import cgi
Traceback (most recent call last):
File "<python-input-0>", line 1, in <module>
import cgi
ModuleNotFoundError: No module named 'cgi'
It's like saying nginx is better than superbase/firebase. Apples to oranges.
You could replicate PocketBase in Readbean, but you would have to implement from scratch:
- resources with CRUD API and real time subscriptions
- admin UI
- authz & authn system
I didn't say it's better. Why are people always misinterperting what they read (it's like you've never had text interpretation classes at school, or logic lessons to undestand how to infer implications from logical statements correctly)?
Please read again: I said it's vastly simpler (which may not be better for you!) and lighter (just measure it). The comparison is apt for me because the description "open-source backend in one file" matches both projects well and it's something I'm interested in, with readbean being far closer to my alley.
Your initial comment presents Redbean as a comparable solution, which it's not; they serve very different use cases.
Redbean requires you to write server code; Pocketbase does not. Redbean does not offer a realtime database, authentication, an admin dashboard, integrated file storage, or an inbuilt API.
I like Redbean, but it's in a completely different "market sector". It's like comparing a kit car to a luxury car: yes, they both technically serve the same purpose, but one requires much less assembly and offers a much more usable experience out of the box.
They are comparable solutions to the problem "Open-source backend in one file".
I don't care at all about "realtime database, authentication" and whatever, I care about what the title of the post says. For that purpose, Redbean is a nice alternative.
> It's like comparing a kit car to a luxury car
If all I need is a bicycle, a kit car is already over the top but will do. A luxury car makes no sense. You're thinking like everyone has the same needs that you have or something.
Ah, I see - my apologies, I think there's an unfortunate misalignment over the word "backend."
When Pocketbase is talking about a backend, they're talking about something like Firebase, which is a complete backend-as-a-service that implements everything you need for a service where the majority of the logic is in the frontend; it's meant to involve as little backend engineering as possible.
You're referring to the more general, standard sense of the word "backend". I agree with the sibling comment that you're not necessarily wrong in offering Redbean as a point of comparison, but the target user of Pocketbase has limited overlap with the targeted user of Redbean; the people looking for a Firebase-like solution would not be served by Redbean, and your initial post could be read as suggesting that they could be.
I do think the use of the word "backend" here is unfortunate, because it's really referring to something much more specific than the conventional use of the term.
I think people are being a bit harsh but your original comment (especially starting with "It seems to me" which makes it sound like a value judgment) was phrased in a way that did sound a lot like you were implying that redbean was better for the same requirements, although you didn't actually explicitly say that.
I think you would have gotten a more positive reaction if you said something like "As an alternative take on the idea of an "open-source backend in one file, redbean is a much simpler, vastly lighter one-file web server + sqlite DB: https://redbean.dev/" to make redbean isn't necessarily intended to be the same type of "open-source backend in one file"
Anyway, redbean does look really neat even if it's not necessarily totally interchangeable with pocketbase
Without any hesitation. Google won't kill Go given how much they use it internally. Even if they do, someone else will take over. Additional benefit of choosing Go over Python is lack of breaking changes in minor releases.
What if Google goes under? What if the next big lawsuit against Google makes it disown portions of its business, and they say goodby to Go as a result? (That actually happened to IBM for example, at the time they were virtually the sole provider of all software services in the world -- that's more or less why and how we have software industry today).
What makes you so convinced "someone" will take over? Is there anyone who offered themselves in such capacity? I've heard a lot of people making similar bold claims about Python 2.X -- sure, someone will step in and maintain Python 2.X indefinitely... Well, no one did.
Then Go is still an Open Source Project with massive community support, that everyoen is free to form and extend or maintain by himself.
> What makes you so convinced "someone" will take over?
Because tens of thousands of projects depend on the language? Because the people who developed go don't just vanish if Google suddenly did? Because OSS has a long history of maintenance changing hands?
> sure, someone will step in and maintain Python 2.X indefinitely... Well, no one did.
There is a simple reason for that: Py2 was obsoleted by it's successor, Py3. There is simply no point in maintaining an obsolete language, especially if it has a direct successor, that is both similar, and an improvement in every single way.
And even so, Python 2.7 was still supported for almost a decade after it's release.
You took just one example. And, although there weren't many cases of proprietary languages or almost-proprietary languages dying in recent years, there are, of course, examples of them dying. You just picked one where this didn't happen...
So, ActionScript would be one example. Dylan would be another. There are probably many more of lesser known proprietary languages that died never making the news.
And, looping back to the original subject: parent believes there's no danger in using an almost-proprietary language, where the evidence is that owners of proprietary languages do kill them every now and then. Do they do it all the time? -- well, no, but I didn't claim anything like that...
---
As to your observation about Python 2.X -- you didn't understand in what context the argument was made. C, or any other language with a standard is warranted the lifetime that's as long as humanity is able to read and understand the standard as well as implementing it. So, 20 years will be essentially insignificant compared to the longevity of a language with a published standard.
Please don't confuse this to me advocating for every language needing a standard. Writing one severely restricts what a language can offer, while at the same time, immortalizing potentially harmful features. Going back to see, we wish today that all the str* stuff would be gone, or stuff like atoi()... but that's not an option anymore, because this stuff made it into the standard. Languages w/o one can shed their skin and remove bad decisions. But, this same feature makes them less viable for long-term projects.
How is asking for examples for a statement a "terrible comment"?
>go is changing the loop semantics to scope loop variables to the loop. Now, I like and agree with this change, but it is a breaking change.
Please explain what exactly that change breaks.
> Behavior changes that are only apparent at runtime is where go makes breaking changes.
Such as? And yes, I am asking for examples. Because I have personally compiled and run code that was written in Go 1.8, with a modern compiler. And the only change I saw so far, is better performance.
> How is asking for examples for a statement a "terrible comment"?
Demanding 10 examples is a terrible comment.
It communicates hostility and disbelief rather than curiosity.
> Please explain what exactly that change breaks.
https://github.com/golang/go/issues/60078 is where this is discussed.
Again, I _agree_ with this change, but I'm pointing out that it is a breaking change. rsc points out in the proposal that it is a breaking change.
> Such as? And yes, I am asking for examples. Because I have personally compiled and run code that was written in Go 1.8, with a modern compiler. And the only change I saw so far, is better performance.
I gave multiple examples already.
If you are truly interested I'm sure you can find more either in the go issue tracker or on google.
> Demanding 10 examples is a terrible comment. It communicates hostility and disbelief rather than curiosity.
It followed the same tone of your comment, where you claimed that they were doing frequent changes, without providing any examples, of which there should be numerous, if they really occur so frequently.
We can discuss semantics here, but a breaking change, to me, is one that that breaks well-crafted existing code. Well, what kind of real world code would rely on the fact that closures over an iteration target examine a value that depends on runtime behavior instead of the actual value that, semantically, seems to have been closed over?
I have stumbled upon this issue myself when I first learned Go. I have used Go professionally and in private projects and since long before modfiles became a thing. I have NEVER seen code that relies on this completely unintuitive behavior. This is not a change that breaks something good, this is a fix that removes a footgun from the language.
That's some of the real-world evidence in favor of changing 3-clause loops.
I have looked, and I found no evidence in favor of not changing them.
If you want to make the case for not changing them, the way to do that would
be to provide real-world examples of code that breaks with the new semantics.
So, semantics aside, no, I do not consider this a breaking change, because while it is, technically, not backward compatible, it doesn't break existing code.
> I gave multiple examples already.
What exactly breaks in the archive/tar package? I looked it up, only found some bugs and issues, but nothing I would consider a change that breaks existing code.
What exactly did modfiles break? I can still compile code without modules. Yes, modern versions of the go-tool require a flag via envvars, but they are still compatible with old projects. And libraries changing is not the same as the language changing. If a build relies on a certain commit on the library, I can always check out that commit.
reply