soggybutter

Totally fine to paint in broad strokes, and I would probably lean towards that perspective myself. However there are some games that show off the programming more than others, at least in motion. Movement based games, like technical platformers or similar, have a lot of expression through the systems that govern them. Whether or not a game feels good is fairly easy to figure out after spending some time with it, but understanding what would make it feel better and how to achieve it is a much harder skillset to develop. Obviously non-programmers can work out in high level terms what might improve game feel, but I think you can get much better results when you have deep understanding of how things work, what's possible, and what side effects may fall out of a given change.

That said, some of the most fun mechanics are born out of happy accidents involving interactions that weren't fully considered so it's definitely not a constant

In 2024? What a ridiculous notion

My wife has suggested the latter a few times and it definitely seems like the most realistic approach. I have a small game engine I've worked on off and on again over the last few years, but it never feels like I have enough time to make real progress

I've made several half-attempts at this over the years, but it always ends up falling to the wayside when life gets hectic. Maybe one of these days I'll finally push through though!

I would've focused on game engine development and gone into the game industry instead of chasing the money in web/web-adjacent tech. It's almost impossible to make that kind of change now without taking a massive pay cut and it genuinely makes me sad almost daily

I stopped at 1144 and 114. This could really use more of a difficulty ramp. After level 20 or so I really didn't notice it getting any harder and it sort of got boring. There was _one_ level fairly early on where it dumped a ton of letters on me all at once for some reason and I actually started to fall behind, but then it never happened again

Good tests only render SST superfluous insofar as the person writing the tests is capable of never making a mistake. The thing about good static type systems is they don't typically make mistakes in the domain they work in. The fact that you don't have to muddy your test with a bunch of type checking logic and instead focus on the thing actually being tested is just the cherry on top.

> Who is "we"?

"we" is everyone in the industry. I recognize it's more of an evolutionary thing, it's just my stance that the current environment is pushing us towards an evolutionary dead end.

> Define "quality"

I also agree that software quality is fairly subjective depending on your lense, unfortunately. For example, I wouldn't view quality as permitting as many people as possible to work at every level. Diversity of ideas is great, but I want those ideas to come from folks who have the skillset. If someone who roofs houses decides to pour foundations without gaining the proper skillset or picking up different tools I would view that as a loss of quality, not a gain.

> the term is time-to-market

I chose time-to-product fairly intentionally, because I think the benefits of something like Javascript start to rapidly decay once you start approaching any sort of product maturity. The problem is teams rarely optimize towards stability and quality until they have literally no other option

I didn't really think you were saying they should be used for everything, but I do think discouraging branching out into better suited tools perpetuates using the lowest common denominator. If devs are never pushed out of their comfort zones, it's really hard for them to grow arms in order to use the saw.

I do acknowledge I have a lot of bias, though, because I work at a TS shop where the primary reason we continue to use it is because we always have. The longer I have to put up with it, the more I feel like this is a broken foundation to stand on

EDIT: formatting

This feels a lot like a self-fulfilling prophecy that Javascript just happened to be chosen for.

- Javascript is "easy" and the only option for browsers, so lets teach it to beginners.

- We have all of these beginner programmers who can't work on the backend without learning a new language, so lets put javascript on servers.

- CPU, memory, and bandwidth have continued to become cheaper, so lets just run everything in javascript because "we can"

- Let's hire javascript developers because we've made them the easiest to hire for

- It's too expensive to use a different technology because our entire engineering team is javascript developers

I honestly can't fathom the reasons why we've encouraged Javascript to eat the world, but I don't think there's any arguing that it has. Is this good or bad for business in the long term? My personal take is that it isn't, but there are enough variables to make this really difficult to say with any kind of certainty. It feels more like we've just:

- Lowered the bar for acceptable quality over time

- Convinced ourselves that the Javascript ecosystem is a one-size-fits all optimization for time-to-product

This line of thinking is precisely why node and TypeScript are so pervasive. It has nothing to do with them being the right tool for the right job and everything to do with perceived lower barrier to entry and resistance to learning better tools. I would never try and use a hammer to saw a board in half, and yet that's exactly what people try and do with node/TS

Modern JS is a passable language only after a tremendous amount of time and effort was invested to retrofit it as such. For all of the purported isomorphic benefits, I still don't know why anyone would choose to use it outside of being forced to in browsers

My team helps run and deploy a python service that is entirely CPU bound. It accepts an input, performs some computation, and returns a result without any sort of I/O outside of the initiating HTTP request. In the past week it's averaged around 144 req/s with a p95 latency of ~1s.

We average ~80 "instances" to maintain this level of performance. I have very little doubt that, if given the opportunity to rewrite this in rust, we could smash 10x perf improvements. Could we also get more perf out of tuning our python code better? Definitely. Do I think there's 10-20x improvement waiting to be uncovered? No.

Unfortunately (fortunately?) we're at a stage that it makes more sense to throw ludicrous sums of money at it than it does to ground up rewrite.

Most of my bitching that JavaScript is slow comes from node, which is quite far removed from the DOM. Fast and slow are relative terms, of course, but JavaScript's language features necessitate that it will always be slower than most static, compiled languages. Regardless of runtime. What blows me away is how unsafe the language is on top of being slow, and yet it's basically eaten the world

I didn't say no one ever has, just that there's a very strong negative reaction even when they don't have reasoning for it