zemo

having written a websocket game server that serves hundreds of thousands of simultaneous connections, I find the tone of this article really frustrating, because the author is peddling a lot of FUD about websockets while at the same time building a SaaS websocket server product. Websockets involve different challenges than traditional http servers, but I've always found them to be fun and stimulating.

> Not every system need to scale to many machines (ex. multiplayer games with limited number of players)

the author writes a websocket board game server. Most, if not all, of these complaints read like the author isn't partitioning the connections by game.

having played with generics over the past few weeks: my guess is that there will be a period of widespread misuse, the first six months or so after 1.18 is released. So... between February and August of next year I'm expecting a lot of the Go discourse to be characterized by a very poor signal to noise ratio. I think there's virtually no chance that Go 1.18 will come out and people will use generics well; people will use generics poorly before they use them well.

A bunch of people will write libraries that utilize generics in some way that's not very orthogonal to the rest of the Go ecosystem. They'll put these libraries out as quickly as possible, because they want a first-mover advantage in picking up adoption. A handful of people will take their time and learn how to utilize generics in a way that is native to Go. Eventually those people come out of the woodwork, and it turns out that utilizing generics in Go looks different than it looked in some other language, so a lot of the early assumptions about how to use them were wrong. A bunch of those early libraries turned out to be badly designed once actually deployed into the real world, so they fade out of use as their problem domains get written by newer libraries that utilize generics in a manner more orthogonal to the rest of the Go ecosystem. A few of those libraries picked up significant market share, and maybe a startup has shipped stuff that generates revenue with those libraries, so they fund those projects, which continue to exist as a result of pure inertia. So now you have some big libraries written in like ... March of 2022, which are just bad, but people keep promoting them because they have a vested interest in doing so, but the ecosystem at large moves on, and by late 2022, generics will fit in very nicely with Go and not complicate things in an unnatural way. I'm wary of what's coming in the short term, but optimistic of what's coming in the long term as a result of this change.

that's not at all accurate of any of the monoliths I've worked on. This in particular describes exactly zero of them:

- one shared database

Usually there's one data access interface, but behind that interface there are multiple databases. This characterization doesn't even cover the most common of upgrades to data storage in monoliths: adding a caching layer to an existing database layer.

(this is the one I meant: https://github.com/BurntSushi/go-sumtype)

lol the arrogance. Hilarious.

there are tools to do this, they’re not widely used because it doesn’t fit Go well. You’re trying too hard to write Go in the style of another language.

If you want an exhaustive type switch that badly, it’s usually a sign that your interface definition is wrong. https://github.com/nishanths/exhaustive

here, have fun. You’re gonna write some tests, make new types to satisfy interfaces for testing, and then wind up with branches for your test paths in your live code, but go for it, I guess. You know everything! I am but a simple blubbite, too dim, too dim to get it.

you can make an exported interface with an unexported method in it and voila, nobody else can implement it. That’s just broadly not that useful so it doesn’t come up a lot.

I hate this pattern too but there's not "no good reason", there's a specific reason why it's like this, and it's a conscious design choice.

When you call `go get somedomain.com/whatever/thing`, what it does is makes an HTTP request to that URL, then looks for a `<meta>` tag on the page telling it where to download the module. Check out the source of any Go project on github and you'll find the relevant `<meta name=go-import ...>` tag. Here's the meta tag for the gorilla router, a common http routing library:

    <meta name="go-import" content="github.com/gorilla/mux git https://github.com/gorilla/mux.git">

The tool is designed so that you can serve modules directly from version control repositories, because the goals were to avoid having any central authority on modules. It turns out this is a huge win in terms of making it dramatically easy to empower people to release modules, AND a huge win for decentralization: if you can host a git repository, the git repository is the module source, and that's the entire system. Just use Go as normal and make a public github repo and it's automatically importable through `go get`. No central registry required.

It's a tradeoff. In making it "one module per repo", it dramatically lowered the barrier to entry for producing modules that other people could adopt right away, but it requires that you have one module per repo, because the versioning scheme is based on tags having semver version strings in them.

Could they have made it something like "a tag can specify a directory and a version"? Hahha, yeahhhhhhhhhhh probably. But they didn't.

In any case, you can also serve modules out of a go module proxy directly, but then you have to set that up yourself. That would free you of the "one module per repo" thing, but now you don't get "a repo is automatically accessible as a Go module". You'd have to implement the Go module proxy protocol yourself. I'm ... doing this now in my spare time but it's not really ready to share yet.

The protocol is actually super easy to implement. It's described here: https://go.dev/ref/mod#goproxy-protocol

the fact that the set of types that can satisfy an interface is open is the source of their power. "closed interfaces" are broadly an antipattern in Go.

with generics you wind up with two parameter lists, and type parameters have metatypes. All type parameters need to have a metatype, and the metatype `any` comes up a lot. Once you start using generics you'll start to feel the pain of writing `interface{}` in those signatures, especially when you are dealing with functions like this one:

    func doSomething[X interface{}, Y Fooer[interface{}]](v X, src Y) error {
    }

versus:

    func doSomething[X any, Y Fooer[any]](v X, src Y) error {
    }

the signatures can get long pretty quickly when you have more than one type parameter.

this assumes a lot about what type of hackathon you're going to and why you're going to a hackathon. If you're going to a hackathon that's a judged competition with prizes for the specific purposes of trying to win a prize, this is accurate, but what you're really doing when you attend hackathons like that with those goals is working for the hackathon organizer without a contract, hoping that you'll get paid, knowing that most of you won't. That's not play, that's work. Is that worth it? Maybe. If it's your only opportunity to potentially get paid or you would have nothing to do otherwise or you're really motivated by competition (and not learning/fun/socialization), sure, that can be worth it.

If you're going to a hackathon with the intention of learning/fun/socialization this post is terrible advice. I went to hackathons for years. I never went with the intention of winning. I always enjoyed myself and always got what I wanted out of it. I've never placed first in a hackathon, but I met several friends at hackathons that I am still friends with years later, learned many technologies through attending hackathons, built lots of fun little projects that I'm proud of, and met my wife at a hackathon.

And to all those people saying "that's not really a hackathon", that ship sailed long ago.

huh, my impression is that the Rust community is famous for being unfriendly.

Here is the Rust code of conduct: https://www.rust-lang.org/policies/code-of-conduct

Can you provide an example of something in the code of conduct that you think makes people walk on eggshells?

> Linux has changed the world -- in a very substantial way and much for the better -- even though Linus flew off the handle at people for years. That doesn't mean he is completely beyond criticism, but it does indicate to me that we need to put a significant check in place against these "feelings committees." Their sensibilities are becoming ever more delicate.

I think that's a pretty bad example, considering Linus took time off and reevaluated, publicly apologized and acknowledged how his behavior was harming Linux.

> competency often makes people a little rougher around the edges.

That seems pretty unsubstantiated.

The thing about "functions should be X lines long" is that an appropriate value for X differs substantially from industry to industry, language to language, and domain to domain. My game code (mostly C#/unity stuff) often has longer functions with more commenting, whereas my server code (Go stuff) has virtually none of this. I definitely write 100-line long functions with lots of commenting in C#. I never ever, ever do that in Go. Maybe I would if I was writing a game in Go, but for Go I'm writing servers, and I never ever wind up with code that looks that way in server code.

I think people want "no-code" solutions because they're intimidated by code. I think they're intimidated by code because they're intimidated by programming culture. If a large number of people outside of programming are intimidated by programming culture then it is by definition intimidating.

If programming was instead seen to be a welcoming, warm, and supportive culture, I don't think no-code would have very much persuasive power. The effectiveness of no-code as a brand should cause more people in programming to pause and consider the fact that the value proposition is not having to deal with programmers. People literally sell products on the basis of not having to interact with our community. That should cause us great concern about the health of our community and should trigger introspection.

what’s the problem with the links? They’re clickable in the document and still state the URL if it’s printed to paper.

anyway to your other point: synthesizing concepts from many writers to join them into one new framework is an age-old style of writing. There’s nothing particularly strange about it; it’s putting the author’s viewpoint in context with other prior writing that the audience is either familiar with or may be interested in reading to see those viewpoints further explored.

people aren't paying huge sums of money for a collaborative virtual graffiti wall, they're paying huge sums of money to signal that they have huge sums of money. People have been doing that for centuries.

the whole "centralization = bad, decentralization = good" argument strikes me as very half-baked. The assumption is that decentralization is inherently liberatory. That assumption isn't guaranteed.

Every cryptocurrency that exist is built on the same fundamental principle: people with the most existing wealth (hash power in PoW, existing crypto in PoS, storage space in PoST) make the most income (whatever crypto in question). All cryptocurrency fundamentally is built on the basis of enriching the already-rich. Yes, cryptocurrency is decentralized, but decentralization alone is not a magical recipe for something being of benefit to all mankind.

Take BAYC, for example. Tradeable membership to a "community" whose only significance is that you purchased membership into an ever-expensive community to belong to. We can say what the price of a membership is quite easily, but can we say what the value of that membership is? If the price of membership goes up, does that make the community "better"? It is decentralized, is it therefore good? The drug trade is decentralized, is it therefore good?

In non-crypto assets, what percentage of wealth is owned by the top 1%? How about in crypto assets?

as for IPFS: You put something on IPFS, what is the guarantee that it will continue to exist on IPFS? It's entirely consensual; there's no guarantee that such a thing will continue to exist on the network unless someone consents to store it. So if you want to actually deliver on that guarantee, what do you do, run an IPFS node that always hosts that file? Feels like you're back at square one, needing to run a server to guarantee that a given file continues to be available.

Now, that's not to say IPFS isn't useful at all! It's very cool! The promise of duplicability and the way in which frequently-accessed data will be more widely replicated is incredibly fascinating on its own, and has tremendous value. I'm a server operator, so the notion of setting up a node to permanently host a particular item in IPFS doesn't bother me. But we shouldn't pretend that IPFS is a magic solution that guarantees the permanent storage of everything put on it. It's a nice addressing and content replication system.

I'm really optimistic about the concept of NFTs in the long run, and about the applications of solutions to the double-spend problem generally. My pessimism is not in the concept of NFTs, it's in the concept of blockchains, which are fundamentally only capable of increasing inequality. The entire concept of what makes blockchains secure is "in order to attack it, you have to have a lot of wealth, so you'd be destroying your own wealth": the security paradigm is "a rich person would not elect to sacrifice their own riches". The entire system is based on this premise.

When we have non-blockchain solutions to the double-spend problem, or NFTs that can be implemented without this promise of increasing inequality, I'll be excited about the space.

BAYC is a community in the sense that it has members and non-members, but what binds that community other than having purchased some asset? Sure, that's one definition of community, but it's not a definition of community that I'm inspired to participate in, or a definition of community that I would be willing to stake my own money on.

On slide 57 he takes the following position:

    Memory model
    – Garbage collection should be the only option

an interesting position to see Sweeney take up, since so many people in games reflexively say that garbage collection is totally non-viable whenever it comes up.

but he also says:

    By 2009, game developers will face...
    CPU’s with:
    –20+ cores

MacBook Pros, Razer Blades, the XBox Series X, and the PS5 all use 8-core CPUs, so the prediction of an ever-escalating number of CPU cores seems to have not really panned out. One thing that has been majorly outside of these predictions is the dedicated ML chips like the M1's Neural Engine.

The presentation isn't explicitly dated, but since the sample game is Gears of War, which came out in 2006, later on he says "by 2009" as if it was not-yet 2009, and the file name is "sweeney06games.pdf", gonna say this is almost certainly a presentation given in 2006. At the time this was given, the iPhone hadn't even come out yet.

It's an interesting presentation. I wonder what Sweeney would say today about this presentation, about how much of it still rings true, and about which things he would second-guess nowadays.

nothing I said precludes the ability to also transfer money, so I'm really not sure what you're getting at there.

The whole thread is that taking an object from one simulation to another is not really the opposite of having distinct simulations: it just forces us to reconcile with what an object is.

The only way you can have separate simulations is if a person can define their own simulation. If you can't define "I won't let you bonk your coworkers on the head with a stick" then you're not in control of your simulation; you're not defining your own simulation, you're just running another instance of some agreed-upon single simulation. At that point, those are the same simulation. So a person setting up a space has to be free to define the behaviors of the objects in that space, otherwise it's not really their simulation.

If you take an object from one simulation to another, and it does not behave the same way in the two simulations, they're still the same object.

> Objets are not just here to mean something, but also to do something.

The fact that they do something does not identify them as objects. A pickaxe in Minecraft doesn't truly break anything. It plays a sound and deletes a cube. If you're in creative mode in Minecraft, it doesn't even increment your inventory. You can also delete a cube in a voxel editor like Magica Voxel. Is the pickaxe in your Minecraft game the same object as the delete button in Magica Voxel? Is the pickaxe in your Minecraft game the same object as the pickaxe in my Minecraft game? Obviously no. They all do the same thing, but they're not the same object.

The only thing necessary to satisfy "moving an object from one simulation to another" is that they be provably of one distinct identity and not be duplicable.

> what would the Staff of Westfall be in a virtual coworking space? Could you beat up people with it?

You’re still limiting the question to the plane of content: the object’s physical (virtual) characteristics.

Consider the staff as it exists in the plane of expression: what is the person expressing by displaying the item? It would express that you play WoW, are an Alliance player, and play a caster of some sort. That might be a valuable ice breaker or conversation starter; a thing that helps people identify a shared experience or facet of their shared identity.

You have to see through the object’s simulated characteristics and into what the object’s existence means for it to have value. If the object doesn’t mean anything, then there’s not much point in moving it from space to space.

in the absence of actual examples, fiction can and sometimes does function as thought experimentation. It can be valid, although in this case, I would argue is not, because Ready Player One does not actually offer any real critique of the OASIS or of the metaverse concept generally; in the story, the OASIS is the damsel in distress, not the aggressor.

there's only one metaverse, and there's only one economy in the metaverse. I'm not advocating that you should be moving game objects between games, that's a distinct concept (and probably not a very useful one). https://news.ycombinator.com/item?id=29086415

right I agree with all that, I'm not advocating for the idea of moving the content that an item represents from one simulation to another, but the idea that transferring what that thing symbolizes should be considered separate and isn't as easily dismissable. See this comment: https://news.ycombinator.com/item?id=29086662

> taking an object from one simulation to another and having different simulations are oposites

not really, we just have to get into some semiotics here and consider the difference between the signifier and the signified (https://en.wikipedia.org/wiki/Signified_and_signifier). In semiotics, a signifier is a physical artifact; the manifestation of something. A physical stop sign, for example. The signified is the concept embodied by a signifier. All of the stop signs in the world correspond to (roughly) the same concept of stopping, but they are separate instances of that concept. Separate signifiers (instances of "stop sign"), all with the same thing signified (the idea that you should stop).

Now in games, we have the notion of the signifier and the signified, too. Let's take an example item from WoW. I'm using this as an example because it's a game I'm familiar with. An item like Staff of Westfall (https://classic.wowhead.com/item=2042/staff-of-westfall) expresses several things. The first thing that it expresses is that it's a weapon so it uses your weapon slot to equip it, and the stat bonus of +5 intellect that gives you additional mana and +11 spirit that gives you mana regeneration. Great, that's nice. Those things can be taken to be the content of the item: its in-simulation properties and effects. But what does the existence of this item signify? The Staff of Westfall can only be obtained by each player exactly once, cannot be traded between players, and can only be obtained by going to The Deadmines, a particular dungeon, and defeating the final boss. Equipping the Staff of Westfall has the effect that it gives you mana and mana regen, but it also communicates something non-mechanical: that the player carrying the Staff of Westfall has gone to the Deadmines and fought and beaten Edwin VanCleef.

Now, can the Staff of Westfall be transferred to another simulation? Yes and no. The signifier, the physical (virtual?) staff can be transferred to another game in some sense. The 3D model can be transferred, the physical appearance of the item can be transferred. But that was always on your computer all along; it's not particularly meaningful. The effects of the item may or may not be transferable; if a game is not the exact simulation that WoW is, what does +5 intellect and +11 spirit mean? The game operator may elect to translate that to some other concept in their game, or they may not. I think this notion of "transfer" is what you're eluding to: the transfer of the signifier. This concept is probably very useless. It's also the concept that people are generally talking about when they talk about the transfer of items between games. I think it has no merit at all.

But there's something else that can be transferred: the thing that ownership of the Staff of Westfall signifies: the concept that the person holding that item has slayed Edwin VanCleef (in WoW). Transferring the Staff of Westfall may not mean transferring the physical model or its attributes, but it may mean something more along the lines of transferring the meaning of what the player has accomplished. Admittedly, I'm not sure why this would be useful or what the applications of such a system would be; what I'm getting at instead is the idea that transferring an asset may mean many things, and that transferring an asset from one simulation to another is not necessarily the opposite.

Raph Koster, for one. https://www.raphkoster.com/2021/09/02/online-world-or-metave...

not really, WoW is a game, and no game can be a metaverse, because one of the most core and intrinsic qualities of what makes something a game is that it is a separate space from reality. Games studies people refer to this as "the magic circle" (https://en.wikipedia.org/wiki/Magic_circle_(virtual_worlds)): the boundary separating reality from "game space".

For example, let's say you're playing a game of Checkers. That's separate from real life. You can't buy a captured Checkers pieces on eBay and then in your next game of Checkers, start with more pieces than your opponent. Being able to do those things would cause the game to break down, because the game would no longer be a contest of your wits in Checkers, it would be a contest of your existing wealth. You can't purchase points in a basketball game, you can't purchase mulligans in golf, etc. A lot of people in the blockchain/NFT space seem to be of the position that games don't currently let you purchase things with real money or sell them to other players for real money because they lack the technical capabilities, but that is not and has never been the problem. There's also the "trading an item in one game for an item in another game" but that's equally useless, it's the same thing but with a barter system, and the barter system would eventually just give way to money anyway. The problem is that introducing those mechanics causes the magic circle to break down.

By contrast a metaverse is a metaverse because the things happening in it are not in a separate, isolated space. Both games and metaverses are virtual in nature, but what makes something a metaverse is the lack of a magic circle, while what makes something a game is the presence of a magic circle. The metaverse is a virtual facet of reality; games' whole thing is that they are not reality.

A metaverse can contain a game, but not vice versa. Plus WoW is entirely owned and operated by one entity; a metaverse is pretty definitionally a situation in which any party can create their own space without needing the permission of another party, kinda like anyone can create a website without needing the permission of any party. Well, of course, you need an IP address and if you want people to be able to reach it, a DNS record and if you want SSL some certificates, so that's not a perfect analogy, but the web isn't really decentralized anyway (for these specific reasons).