I've found it way more hit and miss in terms of quality. From some examples I gave:
- JSON: Yup, stdlib is good here
- HTTP client: There is urllib.request, although people maybe reach for requests more.
- HTTP server: No, it's just some super basic thing (it's not even 'nice' to write for local dev). Would never let anything here near production.
- Unit testing: Yes, I think unittest is pretty good (I actually like it a lot, and think pytest is overrated).
- Crypto functions: No, not equivalent. There is hashlib but basically anything else you're pointed at pycrypto or cryptography with all the associated ecosystem nonsense (oh I need a Rust compiler now? Great...).
The difference is Python _has_ all of these things in the standard library, but the quality is super mixed, and not all of them are suitable for real use.
In my experience, people building APIs w/ python are almost always using frameworks, while people building APIs w/ golang are almost always using stdlib
Isn't it crazy how the media can do that? It really doesn't matter how much good you do in the world if your enemies speak louder. At least in the public's perception.
It’s a common pattern for upstarts to embrace openness as a way to differentiate and gain a foothold then become progressively less open once they get bigger. Android is a great example.
Last I checked, Android is still open source (as AOSP) and people can do whatever-the-f-they-want with the source code. Are we defining open differently?
I think we're defining "less" differently. You're interpreting "less open" to mean "not open at all," which is not what I said.
There's a long history of Google slowly making the experience worse if you want to take advantage of the things that make Android open.
For example, by moving features that were in the AOSP into their proprietary Play Services instead [1].
Or coming soon, preventing sideloading of unverified apps if you're using a Google build of Android [2].
In both cases, it's forcing you to accept tradeoffs between functionality and openness that you didn't have to accept before. You can still use AOSP, but it's a second class experience.
Core is open source but for a device to be "Android compatible" and access the Google Play Store and other Google services, it must meet specific requirements from Google's Android Compatibility Program. These additional proprietary components are what make the final product closed source.
Was "Android" the way you define it ever open? Isnt it similar to chromium vs chrome? chromium is the core, and chrome is the product built on top of it - which is what allows Comet, Atlas, Brave to be built on.
That's the same thing what GrapheneOS, /e/ OS and others are doing - building on top of AOSP.
> Yes. Initially all the core OS components were OSS.
Are you saying they "un-open sourced" things? Because that hasnt happened. Just beacuse a piece of code is open source doesnt mean additional services need to be open source as well.
vscode core is open source, but MS maintains closed-source stuff that builds on top of vscode. That doesnt mean vscode isnt open source anymore.
The app in question relies on the network effect (lots of people crowdsourcing information) so introducing that much friction would kill its usefulness. 99% of users wouldn’t jump through the hoops, and without enough users the app is useless.
