bit_flipper

A lot of what you're saying depends greatly on the exact game you're talking about and what winning and losing means, for instance if the game has discrete places instead of a bimodal winner/loser.

For a few of the games I worked on, random matchmaking like you describe is a non-starter. If you're a 90th percentile player in one of our games, you effectively never lose to a 70th percentile player or below. Your rating will be so high that we can't give you any rating system points for the win. So the person who won got no reward other than the feeling of winning, and the person who lost played a match they had no hope of winning. It ends up feeling pointless to play as a top player because only 1 or 2 matches in 10 on average have any meaning for you. Needless to say, it also feels worse as a low rated player because you simply lose more often.

Thanks for the link, I hadn't read this one yet. Very interesting. I feel like as an industry we're still in the stone ages on how we do skill matching systems. A lot of the current and even future system they describe is really not great, and these flaws are definitely not unique to them (the systems I worked on are even more flawed)! Trying to matchmake dozens of players at a time is such a cool, challenging problem.

I've written game matchmaking before for games and found it far more challenging to do the portions related to matchmaking groups by skill. If you're hyper latency sensitive then perhaps this blog post is really useful? But for the games I worked on we would trade 10ms worse average ping for 10% better skill pairings without question. If you have any advice on improving skill matchmaking I would be quite interested.

Definitely an interesting question. Some things that may explain why --

Mongo was always AGPL and relicensed to SSPL. This had the following consequences:

* Very few companies and zero large cloud companies ever attempted to run the MongoDB codebase in production as a managed service, other than MongoDB the company.

* Mostly because of the above, MongoDB did not receive many code contributions that did not originate from within the company. There were some, but not nearly to the extent of the others you listed

* The difference between AGPL and SSPL is not nearly as large as the difference between BSD and SSPL or Apache and SSPL.

I've run Postgres at large scale (dozens of machines) at multiple companies. I've also run MongoDB at large scale at multiple companies. I like both generally. I don't really care about data modelling differences - you can build the same applications with approximately the same schema with both if you know what you're doing.

I don't understand how folks seemingly ignore Postgres' non-existent out of the box HA and horizontal scaling support. For small scale projects that don't care about these things, fair enough! But in my experience every Postgres installation is a snowflake with cobbled together extensions, other third party software, and home-rolled scripts to make up for this gap. These third party pieces of software are often buggy, half-maintained, and under-documented. This is exacerbated by Postgres' major version file format changes making upgrades extremely painful.

As far as I can tell, there is no interest in making these features work well in Postgres core because all of the contributors' companies make their money selling solutions for HA/sharding. This is an area where MySQL is so significantly better than Postgres (because so many large Internet companies use MySQL) that it surprises me people aren't more unhappy with the state of things. I don't really want to run another Postgres cluster myself again. For a single node thing where I don't care about HA/scaling I do quite like it, though.

You can also build whatever you want with SSPL, as long as absolutely everything you use to run a service that supports it is also licensed as SSPL. It's not that different from the AGPL in spirit.

By which metrics are you evaluating those companies' license changes? Both are significantly more profitable than before they changed licenses, MongoDB especially. I'm not sure there's a causal relationship, but it doesn't seem to have significantly harmed them.

I'm not sure what experience you have, but I've run both their Enterprise licensed database on prem as well as migrated to Atlas and there have never been any licensing issues preventing vertical scaling of databases. One of our clusters on Atlas right now has machines larger than 256GB of RAM -- you're more limited by what your cloud vendor has available than Atlas.

This article seems to have inspired others to look at MongoDB again, so I'll give my thoughts after using it recently.

MongoDB Atlas is a surprisingly good managed database product. I'm not a huge fan of someone else running my databases, but I think it might be the best one you can run across any cloud. If you like MongoDB (and, ignore the memes, there is a lot to like nowadays), and are OK paying a bit more to have someone run your database, I'd strongly consider Atlas.

SSPL has no provision even close to the reach of the "anti-competition" clause Hashicorp is using. While SSPL is not considered open source, it isn't that far off from the AGPL. The difference between SSPL and AGPL is that SSPL (1) is in effect regardless of modification of the service and (2) extends copy left virality to all programs which support running the service, including those that interact with the software over a network.

MongoDB, Elastic, etc. cannot stop you from running a competitor based on the terms of their licenses, they just ask that you publish the source code for whatever service you're running in its entirety (I acknowledge there are disagreements about how far "entirety" extends). The clause in Hashicorp's license actually revokes the right to use their software at all if you're a direct competitor.

OK, no one is going to build an open source competitor to Elastic or MongoDB because then you have no moat and your business will probably fail, I get it, but it's still possible to do without repercussion. It's not like the AGPL is that far off in terms of limitation, either, which is why you don't see many copyleft services run by large corporations unless they've been dual-licensed.

Source for which claim? Kyle was paid for work testing 3.4.0-rc3[1] and 3.6.4[2] which analyzed single document concurrency in a sharded configuration. Those tests run in their CI [3]. MongoDB had some somewhat misleading copy on their website about the result of those tests, so Kyle decided to test the new multi-document transactions feature for 4.2.6 and found some bugs.

It's fair to not trust the database or company, I don't blame you for that. But I think Kyle's MongoDB 4.2.6 report was not nearly as concerning as his PostgreSQL 12.3 report which found serializability bugs in a single instance configuration, among other surprising behaviors. MongoDB's bugs were at least in a new feature in a sharded configuration. I don't think his most recent report was actually as negative as it may read to you. I say this as someone who mostly runs PostgreSQL, by the way!

As a side note I believe there are consistency bugs existing right now in both MongoDB and PostgreSQL (and MySQL and Cassandra and Cockroachdb and...) waiting to be discovered. I'm a jaded distributed systems operator :)

[1] https://jepsen.io/analyses/mongodb-3-4-0-rc3

[2] https://jepsen.io/analyses/mongodb-3-6-4

[3] https://github.com/search?q=repo%3Amongodb%2Fmongo+jepsen&ty... (note: not an expert in when or what suites it runs, just have seen it running before as a demo)

Not your main point, but MongoDB didn't commission Kyle to do that report as they had in the past, he did it on his own time. That's why his report doesn't mention repeat testing. They do actually run his tests in their CI and those new tests were used to isolate that specific bug. Moreover, some of the complaints about weak durability defaults for writing were later fixed: https://www.mongodb.com/blog/post/default-majority-write-con.... They still do default to a weak read concern, but writes are fully durable unless you specifically change the behavior. For what it's worth I agree with Kyle that they should have stronger defaults, but I don't really see a problem with MongoDB's response to the report because there is room to disagree on that.

Where is the root of trust for package signatures? Who is verifying signatures: the package index or end-users? How do you distribute public keys? PGP is mostly maligned because of its support for old cryptography standards, some needless cruft, and especially the poor usability of its defacto standardized implementation in GPG, but cosign by itself doesn't actually make any of the trust questions I mentioned go away. There are major tradeoffs to be made about who-trusts-who and what that actually means in terms of security beyond just theatre. I'm not convinced that there exists a good trust mechanism that a package index can enforce that actually moves the needle on supply chain security.

If you use Musl 1.2.4+ (or Alpine 3.18+), there are no longer the same DNS fallback issues: https://www.openwall.com/lists/musl/2023/05/02/1

To summarize the issue: DNS is done optimistically over UDP because it's faster, but this doesn't work when DNS responses are large because of the design of UDP. TCP should be used as a fallback mechanism when responses are large. This is uncommon normally, but increasingly DNS responses are large in special scenarios; for instance when you're querying an internal DNS for service discovery (read: k8s or nomad deployments, most commonly).

Musl's maintainer interpreted the spec for a libc's resolver to not require TCP fallback (source: https://twitter.com/RichFelker/status/994629795551031296?lan...), so for a long time Musl simply didn't support this feature, justifying it as better UX because of the more predictable performance.

I don't agree with the maintainer on this interpretation, but I am glad the feature was added and the issue is no longer a concern as an otherwise very happy Alpine user!

You can read about why projections still very much matter for large scale (which is what I think you meant; small scale would be something that shows you whole countries and not used for road navigation) maps in the article I linked. Google Maps tried out an alternative projection back when it was still Keyhole and ran into problems with angular distortion when zoomed in. The original post is sadly lost to Google shutting down their product forums, but here's a quote from a Google Maps engineer on their use of Mercator and why it matters:

The first launch of Maps actually did not use Mercator, and streets in high latitude places like Stockholm did not meet at right angles on the map the way they do in reality. While [Mercator] distorts a “zoomed-out view” of the map, it allows close-ups (street level) to appear more like reality. The majority of our users are looking down at the street level for businesses, directions, etc… so we’re sticking with this projection for now.

Sourced from https://ilyabirman.net/meanwhile/all/map-and-reality-distort..., but there are other citations of the same quote as well.

This article doesn't touch on the actual reasons why Mercator is still in widespread use:

* It was the first widespread projection because of its practical use for nautical navigation (where it is still the best projection available), so it was easy for map makers to sell for non-nautical uses, even after "better" projections became available. And inertia is a hard thing to overcome for something considered somewhat inconsequential.

* Mercator and its cousin Web Mercator are extremely simple and fast to calculate relative to other projections. Compare the formula for Web Mercator (https://en.wikipedia.org/wiki/Web_Mercator_projection#Formul...) to Equal Earth, an excellent compromise projection for general use (https://en.wikipedia.org/wiki/Equal_Earth_projection#Formula...). Web Mercator is very easy to generate and serve tiled maps out of, Equal Earth and the like require somewhat non-trivial engineering to make serving those maps at scale to users in a web browser economical and quick.

* Preserving angles is legitimately important still for large scale (very zoomed in) road maps. Projections which preserve size can cause things like 90 degree road intersections to render at very strange angles which confuses drivers. Mercator and Web Mercator are therefore excellent choices of projection for local road navigation, which is by far the most common use of maps today for most people.

I strongly recommend folks interested in map projections to read this from Mapbox: https://www.mapbox.com/blog/adaptive-projections. Google Maps now has similar features, but both companies relied on Mercator for many years with good reasons before technology caught up and better solutions became available.

The author should investigate their networking setup. I can run their Go fetchall example in no more than 70ms. Their benchmarks are surely dominated by noise.

Sorry, I should have been more precise. encoding/gob is not optimized for situations where you create an encoder or decoder, read/write a single value, then discard that encoder/decoder. As the author noted, payloads for a single call to Encode() are quite large. Additionally, re-instantiating a gob encoder for each call to Encode() is very expensive allocation-wise and benchmarks where this happens will show gob to perform poorly in these scenarios. You can certainly still use gob this way, and if the performance works for you then have at it! But it performs significantly better in situations where you make multiple calls to Encode() with the same encoder.

Your note about encoding/gob being inefficient is somewhat accurate for how you're using it, but I want to talk a bit about how you could improve your use.

encoding/gob is intended for streams, not stateless marshals/unmarshals. The first thing that is sent over the stream is the type information the receiver should expect, that's why it's so large. After the first type is received, subsequent messages are much smaller. You can see this by extending your example to do multiple writes; each write after the first is only 10 bytes: https://play.golang.com/p/Po_iaXrTUER

You have to plan differently, but you could get large improvements to transmission sizes by changing to append only files and creating the gob encoder once per file. If you find you're creating a gob encoder/decoder very often, that's a telltale sign you're not using it as intended.

Go has probably the most extensive stdlib of major languages outside of Python (happy to be corrected on that). You can get a sense for what is available by looking here: https://pkg.go.dev/std. There is also the "pseudo stdlib" that is maintained by the Go project but for one reason or another is not available in the stdlib currently: https://pkg.go.dev/golang.org/x

It's fine to dislike Go's philosophy on error handling, but in order to save you and your co-workers a lot of headache down the road, I'd recommend you just use another language. This is not something you want to do in Go and very few folks who program in Go would be happy to work with that style of code.

In case you actually are interested in Go's take on stack traces: You are intended to annotate your errors so you can build your own stack traces with whatever information you want. This leads to better error messages because additional context (values of things) can be logged with your custom stack trace.

I had a look through some of your comments here and elsewhere and just wanted to give you some friendly feedback: This style of commenting is quite toxic. I think you'll feel happier if you let go of the tribalism and engage with others in good faith.