dehora

CDPR, 2002. Larian, 1996. Valve, 1996. Remedy, 1995. Nintendo 1989. FromSoftware, 1986. Capcom, 1979. That said, before the details, I agree and resonate with your sense of frustration. Every shop you mentioned is one I not just admired for their games, but loved for their games.

I imagine there are others that might pass a bar (seriously, a good exercise to stress the thinking is to argue Rockstar out rather than in). But what's interesting is they're all on a good arc at the moment.

CDPR have 'dug up' for the last few years and Cyberpunk 20077 is now not just a fine game, it's a great game. Their redemption arc will someday be a great documentary or movie. It would not have been hard to see them collapse as an entity, but credit to their grit.

Larian are arguably going to be this breakout AAA, and could imo be a Rockstar/Blizzard level company in terms of gamer attention and production. BG3 is as much a moment as a game. It feels a bit like Doom, or Half-Life, or GTA3, or Halo, or Skyrim. I suspect they have steadily and quietly built out the best game character primitive engine and production setup in the industry by some distance, in the sense the way to compete is year on year capex investment that might pay off in 5-10 years. You might compare Larian to early Pixar or ILM. Even if you were willing to stake, you don't have anything like the network of mo/vo cap talent they do.

Valve is the House of Gabe, it's difficult to quibble with the quality they've put into the new Steam Deck. Looks like a a fine device and worth getting. I get there are criticisms of Valve/Steam but every time I use steam I feel like it was built by gamers. I can't really explain it other than to say Valve has serious, brand authenticity—Your-most-respected-brand-here—for gamers. Sony could be all that but can't be all that because of a broken divisional model. Xbox might well get there. Nintendo are already there.

Were Remedy in cinema or the golden age of tv, we'd be talking auteur level work. It's easy to imagine Alan Wake crossing over in television, and possibly film.

Nintendo are their own category, doing their own thing.

FromSoftware have become like Larian are becoming, this other level company. Elden Ring and Armored Core 6 indicate a serious breadth in ability. They are the biggest surprise to me in the sense of being founded the earliest other than Capcom. I would have said 1990s until I checked for this thread.

Capcom it seems are on a tear, and are just steadily releasing solid game after game after game. They in particular, but all these shops in general, feel deeply understudied in terms of game software production. Especially given the attention on AAA development cycles and cost structures that's driving plenty of the shops mentioned into spirals around live service, e-sports, in game payment that seem more like black holes than flywheels.

It's easy to put the challenges driving these companies at feet of the great god greed. And while that might be a component, I suspect a lot of game studios, backers and publishers are struggling with fundamentals of development and production and delivery at scale. Don't just think about the cost basis of ~250 vo/mo cap actors on BG3 [1], think about what you need to to make that work across the engineers and designers and writers and the actors, and, and, and. That's just extremely difficult to emulate without serious conviction and commitment on the long term. Larian did it, and the question everyone else has to answer, do we have the stomach to follow to create games with a payoff quite reasonably not in this decade or a console generation out? Especially bearing in mind, it's way cheaper to build infrastructure out when it's not obvious the value exists. Followers have all the benefits of knowing the path to take with all the negatives that every step is now priced in at a premium.

Games are now the biggest entertainment medium by some distance, dwarfing film, music, radio and books. It's reasonable to want to bring in adult management at that scale (plus games like GTA5, Minecraft and Fortnite are bordering on being their own categories and not simply, games). How Bungie goes from Halo being an era defining game to Destiny 2 being a burning platform is just extraordinary. And it makes me wonder as an example if the guidance given by them to the team working on TLOU service game, which resulted in a reset, was the best cautionary or worst possible advisory.

We haven't really touched on mobile games. In this space, I feel like King, the K in the ABK acquired by Uncle Phil and Microsoft are highly understudied. Candy Crush is also kind of its own category. So many people get enjoyment from their games while the company seems to avoid the worst forms and excesses of whale/gacha capture that plagues mobile gaming.

---- [1] https://www.reddit.com/r/pcgaming/comments/1639t1n/baldurs_g...

Are there any drawbacks of using a plugin centric approach?

Here are some:

1. You're perhaps more subject to Hyrum's law. If plugin devs can see it, they will use it. The general observation here is that it's harder to control the visible interfaces and implicit dependencies you export than the dependencies and interfaces you rely on. As one example, semantic versioning doesn't cater for this at all. Plus, most of the practice knowledge in software is on managing relied on dependencies.

2. Dog follows tail. It can happen that a plugin becomes so successful the overall system evolution slows down. The core system can upgrade, but adoption/deployment can be constrained when a particularly valuable plugin doesn't move up to the latest and the customer base sees more value in the plugin than its core platform. This can compound poorly over time, and in extreme cases the desirable plugin can become its own platform/system (something I think business savvy tech leaders are increasingly aware, and wary, of).

3. Operational complexity. It can be harder to run and maintain a plugin based system than a closed one. 2 is a consideration here, but so are other concerns, such as security and resource isolation. Strategies vary, but who pays this cost on a relative basis is one of the more (and perhaps the most) interesting aspect of working on or using plugin systems. As one example of this, think about allocating responsibility for bugs.

4. R&D complexity. It may take more time to design and build a plugin system than a closed one. Incrementally evolving to a plugin system can be difficult if you didn't start there to begin to with. So you usually need a clear opening motivation to delay reward (or avoid over engineering) to invest in a system design where functionality can be extended by non-core developers.

To the poster's credit, he does frame this in terms of balancing concerns. I'd argue the post overstates the non-technical mitigation, but they seem worth being aware of, and even as a rhetorical device, overstating helps bring them into focus.

The deeper question is why is software quality only loosely correlated, if at all, with business outcomes?

Because quality is on a spectrum and context specific: commercial domains need quality levels—you have to set magnitude or quantify in some way. The software profession such as it is, tends to come at this a binary matter (cite pretty much any debate about speed vs quality). That gets, I think, amplified in technical communities where correctness is deemed more important or simply more attainable in terms of claims.

But the optimist understands that great engineering will leapfrog competitors and leave them in the dust.

I agree with the sentiment; I actually do think we're in a phase where engineering leverage is underestimated, but would qualify it and say this is different to correctness. What great engineering can do is offer a short term technical advantage (eg "secret sauce") and/or a sustainable one (eg "organisational speed"). It's not clear correctness provides that kind of benefit, unless we want to frame as increasing precision/accuracy/reproducibility of results.

I agree with pretty much all of this. The point I'm making and not conveying well is that the state eventually has to be held somewhere. So not that it has to colocate with application services, but that if you want to store something with something, then Kubernetes as the substrate makes things harder. Even where you have say replication built in and are not reliant on 'the' file or disk, you tend to need to bolt on an operator to handle replication/placement. An example is Etcd used within Kubernetes. You don't get to just run Etcd on K8s itself; it needs an operator which was about 9KLOC last time I looked.

Yes for sure, in terms of expansion/adoption. It's not so certain in terms of function/utility. As a Google outsider, gRPC really does seems like Stubby for the rest of us (with balancing left as tradeoff for the community). Kubernetes does not seem functionally at all, to be a Borg/Omega. it's more like a porcelain for running Heroku/12-factor/Nanoservice style workloads on top of a Borg-like (that's no small thing, but it is just a thing) after learning what Amazon learned out the gate on AWS, that developers will not be constrained on framework choices (ie they're not ready to settle on a PaaS).

To that extent, there's a hole left dealing with things that do need to consider state versus run networked API services. Kubernetes seems to have no good story here, whether it's the evolutionary progress happening around StatefulSets/PVC/PV, or a per appliance operator for you, and you, and you, which punch a hole as big as you like in the scheduling abstraction. Streaming for example is a notable pain, but pretty much every OSS project created in this century that has state needs a compensating tool, typically an operator, to function on Kubernetes. I'm not even sure at this point whether state is a design consideration that can be retrofitted—that's not a criticism of Kubernetes, but it is a complication and investment factor for stateful workloads. So what may happen should Kubernetes be one of those things that does in fact end up being a long term technology, is the entire software industry offloads state management to vendors (ie to a handful of cloud services), or something in open source reacts and is created to fill the infrastructure gap for state management.

Great to see an answer that provides context and reason for a language preference. By way of reflection on your answers:

1) This is hit and miss for me. I have to read Go code frequently: not every day or even week, and sometimes under incident pressure. It's less verbose than Java/C#/JavaScript, more verbose than Python/Ruby/Scala. But it's sufficiently verbose to require, for me, cognitive discipline to not skim (ie, "I've been skimming, need to go back up" awareness). So when I'm reading go I put my Java/C#/JavaScript hat on not my Python/Ruby/Scala hat. Not a big problem, but it was so, so close to being in the latter camp. For me then, its regularity claims are something of a wash such that I'd like to see some supporting empirical data or summation of anecdote that it does in fact optimise well here and make good engineering tradeoffs.

2) The problem (I think) is being being to skip by the returned values. It's better than return codes in C, but you're not absolutely required to handle them. I suspect trying to patch structured returns onto an algol-like is a dead end, and if we want structured returns, we want to use a language that really induces us to 'process it forward' eg via map/flatmap/case handling, rather than adding ceremony around if. I think Go made sensible and realistic choices here.

3) Lack of generics are a pain, but a pain for writers. Go does not optimise for that concern, except afaict for its core language creators who have escape valves. The conspiracy theorist in me says Go was wait and see on generics (and exceptions, and objects) as a function of when it was incepted, and may now reasonably conclude that generics are here to stay so the language will need to solve for them, but objects and exceptions were good holds. ie, I don't completely buy it required a decade to figure it out, but could buy it took a decade to observe generics are not going away.

4) In Go, this seems to be satisfied by codegen and templated YAML. I wonder if this is generational, in that the need for reflection might be lessened because of how work on cloud/virtualised systems happens (networked services handling data in and out, with regular deployments).

5) Agree. GoLand I find a great tool for reading and delving into programs, and VSCode is a fantastic 'every day carry' for code.

It's great to see Microsoft release these guidelines. It's good work, a broad document with a lot of interesting topics covered. You can always debate the details (the pagination discussion here is very interesting), but having seen first hand at Zalando how much dedication and effort goes into API guidelines to support a large number of service teams, plus releasing them into the public, it's no small feat and they deserve credit for doing this.

There's naturally been some discussion around REST/HTTP APIs and design styles. One of the things we've tried to do with the Zalando guidelines (https://zalando.github.io/restful-api-guidelines) is go into more detail on using HTTP and JSON, and how REST properties are used. Zalando, like everyone else, has had to think through versioning and compatibility, so it was interesting to read what Microsoft do here. The Zalando guidelines take a different approach, using media types for versioning, document just one set of compatibility rules, plus a deprecation model, and it's working very well in practice so far (http://zalando.github.io/restful-api-guidelines/compatibilit...).

Btw, in case anyone from Microsoft working on the guidelines is reading and ever wanted to swap guideline notes or ideas, that would be awesome. And once again, great job releasing the doc :)

I was wondering, what did you think of the production readiness of Mesos independent of Docker?

Python is slightly easier in my experience to refactor and manage as the codebase grows, somewhat easier to get performance wins out of, somewhat easier to debug. But it's approximately in the same bucket as Ruby when it comes to tooling - put another way, you probably wouldn't switch to Python from Ruby because of the relative improvement in tool support.

I think Avdi's right in the sense that weak tooling is inevitable due to the language's properties. With Ruby and Python, what you gain in near term productivity and effectiveness you pay for later - your tipping point may vary.

Agreed.

YAML is easy to type, even with the whitespace. So is INI. And as verbose as XML is, it's easier, ime, to type than JSON. Of those four, JSON is the hardest to write by hand; certainly it's the one I make most mistakes with, to extent I have a particular technique for writing it out (prefixing the commas). As a result JSON as a config file format is tedious, verbose, and error prone; its sweet spot is a machine interchange format that a human can debug/read if needed.

It is a problem with JSON in the sense that it's a JavaScript subset, 'in practice' - modulo the Unicode support that goes beyond JavaScript. So it's to be expected that eval() will be used as a convenience by developers, ignoring the security implication that comes will eval() hoisting full JavaScript.

The way to have avoided the issue would have been for JSON to have a grammar that broke eval(). But one could argue the ability to pass JSON into eval() to get JavaScript is one of the reasons JSON became popular to begin with.

Apache's Cassandra deb that a similar behaviour and has a greater impact than ES's super-hero node names. A newly started Cassandra node will absent a token declaration in its yaml file, auto-assign a token. This is never what you want in a cluster distribution. So the workaround is either to patch the deb to not autostart or let it start, stop it, and blow away the data directories. This allows cluster management tools (such as Priam) to control the token allocation first, and then re-start Cassandra.

This is effectively how Debian/Ubuntu work. Once you know it, you can work around it. That said, it would be nice to have packages that don't run their service.

> It's the only formally proven,

No. RDF is formally proven via its Model Theory (as was KIF before it). That's arguably a stronger basis that relational "algebra"

Quora on MySQL failed outright when AWS EBS failed, companies on AWS using Cassandra like SimpleGeo and NetFlix did not. To their credit, Facebook were clear enough on their reasons for using HBase over MySQL and Cassandra, such as wanting to double down on their current Hadoop system/knowledge and having easily obtainable ordering guarantees on messages. It's also clear they've invested in making HBase good enough.

At large loads and footprints, imvho, Riak, Cassandra and HBase present viable options. But there are some factors to consider that don't seem to get mentioned in the pop tech press

- What are you able to operate in production?

- What are you able/willing to debug and patch?

- What hardware options do you have?

- What are your workloads?

- Which variable of C.A.P, when you lose it, most damages your business?

- Will your company's choices be evaluated in the press?

- Does your board/investors have capital tied up in business's that are using something else?

- What architecture tradeoffs and styles sit well with you?

- What kind of data access and consumption patterns make you money?

- Can you pay for help?

The right choice is context sensitive, and I'm fairly sure for this class of systems at this point in time, there's no free lunch. That means you have to do the legwork for yourself and make your own choices and commitments; doing what you heard worked for someone else is a cargo cult.