report-to-trees

Interesting, yeah I guess that makes sense.

I always thought those strategy games were missing a competitive community and better PvP experience but I could also see how more replayability would make them more popular.

What do you mean by infinite variations here?

What's an example of an idea that doesn't require you to be overly social? I would probably guess founders and sales in general requires a lot of social skills.

Why would you need edge rendering for ssr? What's wrong with a regular server?

If you need multiple versions of something running simultaneously then ya lambda might be simpler.

In my experience, running a single monolith server will be much simpler than 20+ lambda "monoliths" that call each other. I think the simplicity of lambdas vs a persistent server looks good on paper but falls apart when you have multiple times more deployments to manage.

I would argue that instead of starting with a Lambda Monolith and splitting routes out when they need to scale separately, you should be starting with an actual monolith and using Lambdas _only_ when a single route needs to scale separately (in a way that fits lambda). The Lambda Monolith is an unnecessary architecture as far as I'm concerned.

Gleam looks like a new language built to compile down to the BEAM. While you could call elixir or erlang libraries from Gleam code, using Phoenix probably wouldn't be useful. I imagine a new framework would be written for Gleam.

Gleam looks really interesting. I'm surprised, for some reason I was under the impression it was more like Sorbet or Mypy with type annotations in existing code and I had no desire to check it out at all. I'm now intrigued and will probably pick it up soon!

Having worked for one of those company's, I think the productivity of Rails is overstated. Yes it's quick to get a rough demo and POC working (which is already plenty quick in many other frameworks) but once you get into the weeds of actually building and iterating the difference is not so great. I think particularly if you look at these established companies, what tech stack they are running often is just a matter of what the founders knew at the time. The business wasn't successful because they chose Rails, it was a successful business who happened to pick Rails to start with.

Cool! I was looking into monetizing my OSS idea just the other day and it seems much more complicated than it needs to be. Is your idea to build a marketplace and all the behind-the-scenes license / billing tools, or just the marketplace?

I agree 15000 functions is overkill and I would never recommend something like that. I'm trying to explain why combining all 15k functions into a single Faas deployment is not going to be the best option either.

There is a middle ground that will be much faster and cheaper all around.

If you manage to lazy load your routes it may help with cold starts but I think you effectively lose the benefit of warm handlers since every request could use new code that needs to be loaded fresh.

I've never attempted lazy loading inside a Faas platform but I think generally you would be better off creating small deployable chunks and letting the platform handle scaling them up / reusing as necessary. Less fighting against the platform and if you have to maintain strict boundaries to enable lazy loading only the needed code for each route it's a short step to deploying those as their own functions anyway.

In that case you are deploying a whole monolithic app to the Faas platform. This needs to be initialized on every cold start which takes longer the larger your code is. The main selling point (that I have experienced) in Faas is that you can have small, individually scalable functions that are quick to initialize and can be torn down after executing. If you have the whole app under one handler you would be much better off with a different architecture where the app is persistent and always running.

One of the things that bothers me the most with the cooperate software development rat race is how many problems are being solved over and over again. Every company is staffing their own devops teams to build their own abstractions over these technologies so app developers don't have to worry about it. I personally know multiple devs who basically move from company to company reimplementing the same devops tools at each one.

It all just feels like a collosal waste of energy and collective resources.

I think the initial reaction of many (myself included) is pretty negative just based on the niche these products fall into. Something about a Twitter Influencer selling various products to other Twitter Influencers to manage their own business hyping is a bit off putting.

After some reflection I don't think this is better or worse than any other niche you might market towards.

Is there any other industry where workers are so beholden to their employers that they cannot simply create something of their own without fear of legal action?

How did we get to this point as an industry and how do we change this destopia?

In my opinion that would be much more helpful than what was there before, it still gives preference to built in tools above all other criteria but you at least avoid the false impression that tools provided by the ecosystem don't exist.

I think the problem with what you have now is that the feature comparison values "built in" above any other qualities. Obviously would require a much bigger article but I think the only way this is useful is if there is a comparison of tools in each runtime and "built in" is simply a pro in that comparison.

Sure, maybe. How would you know without doing some research into a specific project?

My point was that the feature checklist here is so surface level it's useless as a practical comparison.

I wasn't expecting a deep and thorough comparison just from the headline... but the feature list and comparison text here is worse than I thought it would be, bordering on useless.

"Built in" means nothing because the value prop of node compared to the other two is the ecosystem and maturity. Do you care if your linting tool is built in if it's buggy and regularly releases breaking changes? "Secure by default" in particular means nothing by itself here either.

Bun specifically promises better compatibility with existing npm modules then Deno so the comparison here is much different than the chart would lead you to believe.

I think these stories and aversion to "clever" code end up hurting programmers overall. I wish we spent more time teaching how to choose the correct time and place to be clever instead. Searching for ways to make things better instead of mindlessly copy pasting how it was done by the person before me is how I learned my most valuable skills.

The best products and features I've ever worked on were run by engineering and design working very closely together, while the PM role was pretty much exclusively stakeholder / client communication.

It's a shame how large organizations always form a layer of "product owners" who fight amongst each other for ownership and control.

Most small shop tech jobs in smaller cities pay very little comparatively. The OP said they were currently at FAANG, not that they have been at that level for 2 decades.

Having worked with lots of people with over 20 years experience, a lot of them stuck with a single company their entire career and are making nowhere near FAANG.

Good enough for who? Random internet comments and memes, sure. I have serious doubts any business will be ok paying for a tool that outputs nonsense (or worse) 1% of the time when they are already paying people who do it well.

As depressing as it is, most business is treated as seriously as life-or-death.

Models like ChatGPT and Stable diffusion will go the way of self-driving tech as everyone realizes they are not good enough to replace any actual human work.