Joke’s on them. My coffee maker has a physical button!

Yes, containers make your application logic work.

That’s the lowest hanging fruit on the tree.

Let’s talk about persistence logic, fail forwards, data synchronization, and write queues next.

Let’s also talk about cloud provider network egress costs.

Let’s also talk about specific service dependencies that may not be replicatable across clouds, or even regions.

Oh, also provider specific deployment nuances, I AM differences, networking differences…etc

I’m not sure if you are referring to the same thread.

I’m talking about the effort to build multi region and multi cloud applications, which is incredibly difficult to pull off well. And presents seemingly endless challenges.

Not the effort to move to the cloud.

It’s phenomenally expensive from a practical standpoint, it takes an immense amount of engineering and devops effort to make this work for non trivial production applications.

It’s egregiously expensive from an engineering standpoint. And most definitely more expensive from a cloud bill standpoint as well.

We’re doing this right now with a non trivial production application built for this, and it’s incredibly difficult to do right. It affects EVERYTHING, from the ground up. The level of standardization and governance that goes into just making things stable across many teams takes an entire team to make possible.

Screw the compute budget, the tripled team size without shipping any more features is a bigger problem here.

This is a good reason to start investing in multi region architecture at some point.

Not trying to be smug here or anything, but we updated a single config value, made a PR, and committed the change and we were switched over to a different region in a few minutes. Smooth sailing after that.

(This is still dependent to some degree on AWS in order to actually execute the failover, something we’re mulling over how to solve)

Now, our work demands we invest in such things, we’re even investing in multi-cloud (an actual nightmare). Not everyone can do this, and some systems are just not built to be able to, but if it’s within reach it’s probably worth it.

There’s a good reason why I refuse to use cloud connected or Internet required “smart” devices.

It’s essentially an excuse for shitty engineering.

If you really need a device to be cloud connected then it can also maintain local data when the remote server is down. Even better, it uses an open spec and you can standup your own server.

This isn’t technology news.

Still linear time at least, could always be much MUCH worse

This… Is a very possible future

But I wasn’t facility. I was a student.

The dorm itself did not have internet and had no plans of running ethernet or providing internet to students.

I got internet through a wireless access point, positioned very carefully in window for a WISP. And they distributed that to rooms near me.

It’s old magic too and in a pinch it works reasonably well.

We use this as a networking option for an old dorm I was in which didn’t have ethernet and the concrete walls between rooms made Wi-Fi unusable.

Blocks of rooms were not separated on different circuits which made this possible

TIL.

Is this redundant with DNSBL?

Honestly, the people that shit on C# as a Microsoft product are just as bad as the Microsoft Fanboys. It’s an asinine position.

Point at the objective reasons to use it such as first party frameworks, being incredibly stable and having some of the best devex and performance in the ecosystem. There are many reasons to use this, especially for large performance orientated, cross platform, long term stable applications.

It’s a FOSS language anyways, the majority contributions aren’t even from Microsoft employees, seeing crazy high levels of community contributions… Its also supported by a legally separate entity from Microsoft themselves.

Yes, typescript is my favorite language. There’s literally no other language out there that is as expressive and has as strong of a type system as typescript. It is the master of making impossible states unrepresentable through meta programming. Being able to move domain complexity into the type system instead of into the runtime is some of the best ways you can reduce your runtime complexity and defects.

Though .net is my favorite ecosystem, by far. It’s first party frameworks are unmatched in performance and developer experience. And its ecosystem is incredibly stable, unlike JavaScript. C# Is unfortunately a much less capable language from a type perspective than typescript though.

If C# got discriminated unions and strings as first class type citizens that would launch it pretty far.

I mean yeah you can do anything with it like most other languages. The problem comes in with the unstable ecosystem JavaScript has.

You simply don’t have longevity with libraries and frameworks. They churn and become deprecated far too quickly for really any stable project that requires a low maintenance burden.

I mean…

Yeah, depending on the word, it can invoke specific feelings. Words don’t end to have that effect…

I was about to say C# seems to be in a weird spot here.

It’s entirely FOSS. It does of course have corporate daddy providing dev resources for it but it definitely is not anywhere near the location for proprietary as Java.

It should be well and truly on the same side of this graph as Rust.

This is how you get thousands of defects at worst and multiple engineers time worth of tech debt at best.

We have a mantra that “If it’s good enough to merge, it’s good enough for production”. With the intention of automatic production deployment sometime in the future.

That’s has helped us improve quality, a lot.

Bullets are lead. How exactly does one expect an EMP to have any effect on them…?