Earlier quoted context omitted.
I think what happens (and I have this attitude too) is that "learning" SQL takes a weekend...but then you know you'll wind up having to spend a lot longer learning the patterns of the language, and the nuances of the specific dialect, and which of the integration tools will work well with your workflow and pipeline. So while "sure I'll just learn SQL" is great for a personal or school project, when you've got to get…
learning" SQL takes a weekend...but then you know you'll wind up having to spend a lot longer learning the patterns of the language, SQL is a skill that rewards investment in it 1000x over, in terms of longevity. It has spanned people’s entire careers! What’s the shelf life of the latest JS framework, 18 months at most...
Bye Bye Mongo, Hello Postgres
391–400 of 427 posts
Re: Bye Bye Mongo, Hello Postgres
#392Earlier quoted context omitted.
Because of how different they are, taking advantage of them requires using them in specific ways that are also very different. If you have an abstraction layer that hides those differences, it's practically a given that it does so with the lowest common denominator approach, where you get all the flaws of both and none of their unique benefits. (Alternatively, people find ways to use the abstraction layer such that i…
I'm pretty sure you can have one interface for YeSQL an NoSQL. * getUsers() * saveUser() * listUsers() * deleteUser() and implementation can implement it in specific way to take advantage of chosen technology. If you have some esoteric use cases they could be handled in special way separate from business code.
Being tasked to come up with an abstraction layer that supports the speed of precomputed, clustered indexes with the flexibility of SQL - if I were in a content creation business and not a database engine writing business - sounds like the kind of project that would make me quit my job and go on a one year silent meditation retreat.
Re: Bye Bye Mongo, Hello Postgres
#393Earlier quoted context omitted.
I'm glad that RedHat didn't feel that way when they were sponsoring kernel development, or that Netscape had panicked and locked down Netscape instead of opening it up, or that Sun had given Java a terrible license. Or Google and Kubernetes. LinkedIn and Kafka. Airbnb and Air Flow. I could keep going like this all day. Mongo made a lot of money building a projects that runs on top of many other projects that were rel…
So Redis, HAproxy, MongoDB, ect .. should feel good that nowdays multi-billion $ companies take your product and put more people on it that you do internally, sell it and give you nothing? Explain to me how a startup of 10-20 people can compete against AWS once they grab what you're working on to make an AWS service? Changes Mongo, Redis made to their licence were made to protected against those practices.
2. HAproxy is still GPLv2.
3. Redis Labs's CCL and MongoDB's SSPL are not open source licenses, but their purveyors sure do like to give off the impression that they are open source. If you want to keep your code proprietary, keep it proprietary. Don't pretend to be open source. If you are not okay with others using your work, even making money off of it, as long they adhere to the rules of the open source licence you used to license your work to them, then don't license your work to them under open source licenses, or don't cry foul when they use it under the terms of the license.
Re: Bye Bye Mongo, Hello Postgres
#394Earlier quoted context omitted.
Would PostgreSQL + JSONB work for you there?
Allegedly, Mongo is more efficient if you need to ingest billions of records.
/dev/null is more efficient than just about anything at ingesting billions of records, but not very useful, is it?
Re: Bye Bye Mongo, Hello Postgres
#395Re: Bye Bye Mongo, Hello Postgres
#396Earlier quoted context omitted.
FWIW and insofar as I can recollect, JSON was supported by Postgres before Mongo was a thing, and Mongo was built based on Postgres.
No, that's not correct: Initial json support in PG was added in early 2012 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit... whereas mongodb was made public in 2009, according to wikipedia: https://en.wikipedia.org/wiki/MongoDB I don't see how Mongo was built based on Postgres, either?
The relevant data structures and indexing mechanisms (hstore, tsvector, gin, gist) were all available -- if only experimentally -- before Mongo launched.
Re: Bye Bye Mongo, Hello Postgres
#397Earlier quoted context omitted.
No, that's not correct: Initial json support in PG was added in early 2012 https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit... whereas mongodb was made public in 2009, according to wikipedia: https://en.wikipedia.org/wiki/MongoDB I don't see how Mongo was built based on Postgres, either?
My guess is the grandparent is (mis-)remembering the kerfuffle[0] around mongo shipping a copy of PG as a "BI Connector". But yeah, the timeline is off, that was in 2015. 0: https://news.ycombinator.com/item?id=10697692
I might be misremembering, though. And there's a possibility that what I read then was inaccurate.
Re: Bye Bye Mongo, Hello Postgres
#398It's not a great article tbh, it's well written but it shows the clear lack of knowledge running a backend. The title should be "we didn't know what we were doing so we switched to a managed DB" I mean yeah who knew that blocking NTP therefore time drifting would break everything... For those criticizing MongoDB, Fortnite generates $3B/year and runs on MongoDB, you should tell them it's a mistake and that they should…
Epic have also had at least 2 major outages directly related to MongoDB https://www.epicgames.com/fortnite/en-US/news/postmortem-of-... https://www.epicgames.com/fortnite/en-US/news/postmortem-of-...
Re: Bye Bye Mongo, Hello Postgres
#399Earlier quoted context omitted.
This actually resonates with me, maybe not in the way Ellison intended as I’m not familiar with the context he said it in. A bit off the main topic but the more I revert to just using emacs for some task I previously used a .app bundle or web page for, the more I question how much we the computer industry has just been spinning its wheels for the last 30+ years. I honestly can’t really tell what value WIMP-centric GU…
Discoverability and self documentation is generally the advantage of GUI systems. Well built systems can be understood in a few moments without needing to consult a manual. That's almost impossible in a pure CLI environment. Of course it's entirely possible to screw this up, modern phone-centric design standards are really bad about it for example, but in general you need to consult the manual (or Google) far less of…
Early GUI developers also put effort into making their GUIs at least somewhat intuitive, but they also bundled thick books of documentation on how to use their systems.
To a degree, they are self-documenting, but not because of their GUIness so much as their design choices; menus helped a lot with this. Menus actually are a good subject to touch upon, they are definitely one of the better conventions we developed, and they were based upon and analogous to a restaurant menu. However their very nature as a list of commands you can issue a GUI does also typically but not always, limit the application. If the only options available to you are what is on the menu and there is no other interface, then an application is much more limited. This isn’t even true of most restaurants which will often allow you to issue an order for something not on the menu if they have the ingredients, equipment and expertise to make it.
But as a convention, it is not limited solely to GUIs, you can incorporate menus into any interactive interface.
I think the real innovation wasn’t GUIs, it was interactive software. The innovation beyond that is scriptable software.
What is important isn’t GUIness, but the developer’s intent. If you develop software with the intent to be self-documenting and discoverable, you will end up with an interface that is both of these things provided you did a competent job of it. A GUI might help, relying on platform conventions might help, and using common cultural conventions might help, but these aren’t the necessary ingredients for those qualities.
Emacs has the quality of self-documentation, but it is emphatically not a GUI even though it is interactive.
I would say well built systems, provided you intend to do anything productive and even slightly complex, should have a manual included, or else it isn’t a well built system.
Re: Bye Bye Mongo, Hello Postgres
#400Earlier quoted context omitted.
This actually resonates with me, maybe not in the way Ellison intended as I’m not familiar with the context he said it in. A bit off the main topic but the more I revert to just using emacs for some task I previously used a .app bundle or web page for, the more I question how much we the computer industry has just been spinning its wheels for the last 30+ years. I honestly can’t really tell what value WIMP-centric GU…
> I suspect that in a year I’ll be using what is effectively an Elisp machine with an Apple logo paired with an iPhone. It's been working for me for quite a while now. And it's depressing, but here we are.