dikei

That code looks like a proper object-oriented design to me, nothing to do with type-hints actually.

$72

Though if you are only spending $350 monthly on VM, Database and Load Balancer, you can probably count resource instances by hand, and don't need a K8S cluster yet.

GCP has $74 free credit for Zonal cluster, so you effectively have the first cluster for free.

And even $70 is cheap, considering that a cluster should be shared by all the services from all the teams in the same environment, bar very few exceptions.

> For most small setups, the cost of running an empty kubernetes cluster (managed) is typically higher than setting up a db, a couple of vms and a loadbalancer, which goes a long way for running a simple service.

Not really, the cost of an empty EKS cluster is the management fee of $0.1/hour, or roughly the price of a small EC2 instance.

> Just feels like lots of devs will take whatever random configs they find online and throw them over the fence, so now you just have a big tangled mess for your CRUD app.

Agree.

To reduce the chance a dev pull some random configs out of nowhere, we maintain a Helm template that can be used to deploy almost all of our services in a sane way, just replace the container image and ports. The deployment is probably not optimal, but further tuning can be done after the service is up and we have gathered enough metrics.

We've also put all our configs in one place, since we found that devs tend to copy from existing configs in the repo before searching the internet.

Even for on-prem scenario, I'd rather maintain a K8S control plane and let developer teams manage their own apps deployment in their own little namespace, than provisioning a bunch of new VMs each time a team need some services deployed.

Sarcastically, CDE is one way to move cost from CAPEX (get your developer a Mac Book Pro) to OPEX (a monthly subscription that you only need to pay as long as the dev has not been lay off)

It's also much cheaper to hire contractors and give them the CDE that can be terminated on a moment notice.

> The amount of time it takes to publish a multi-platform Kotlin library for the first time can be measured in days. I published my first Golang library in minutes, by comparison.

It's a bit Apple & Orange comparison: publishing a JVM only Kotlin library is quite easy, it's the multiplatform part that takes time.

In JVM world, the de factor equivalent to `go build` and `go test` are `mvn compile` and `mvn test`, which works 99% percent of the time.

Other build tools and plugins just compete/fill in for:

* improved build speed / test speed: using background daemon to reduce strtup speed, intelligent caching / task reordering to avoid redoing, etc..

* extra functionalities like code generation, publishing or deployments. As code generation is really big in JVM world, and there are many ways to deploy an application: jar + libs in a zip file, uber jars, container image, etc...

I only know this one

https://www.mqtt-dashboard.com/

But a quick Google search will get you some others.

> Verticle tabs, seriously

Yes, I use Edge due to its vertical tabs

The usual way is to put conflicting versions in optional-dependencies, and then build one target for each conflicting set of deps. That'd work fine if the code path of one target doesn't touch the others, which is often the case.

You'd obviously need to have tests for both targets, possibly using a flexible test runner like `nox` to setup separate test env for each target.

Actually, I prefer spending my time writing right-pad

One way is to publish 2 variants of your packages: one with the major version number appended to package name and one without the version number. Users who need to install multiple versions can use the first variant, while user that just want to follow the latest can use the second.

Just like JS has npm, yarn, pnpm, bun...

It seems the more users a language has; the more dev tools get written for it.

Yes, that used to be the weakest part of Wine. Luckily, we have DXVK now.

I'll refer you to the MPV FAQ for historical context.

https://github.com/mpv-player/mpv/wiki/FAQ#how-is-mpv-relate...

There were lots of drama in the media player scene. Even "wm4" the original maintainer, who forked mplayer2 into mpv, is no longer with the project: he deleted his Github account and disappeared.

mplayer was forked into mplayer2, which in turn was forked into mpv

Though AFAIK, most of the rendering code behind mpv has been entirely rewritten.

I used to use restic with scripting, then I discovered resticprofile, and swiftly replace all my scripts with it.

https://github.com/creativeprojects/resticprofile

I also use Kopia as an alternative to Restic, in case some critical bugs happen to either one of them.

https://kopia.io/

> The problem with the naïve design is that even with virtual threads, you risk running out of (heap) memory if the threads ever block.

The key with virtual threads is they are so light weight that you can have thousands of them running concurrently: even when they block for I/O, it doesn't matter. It's similar to light weight coroutine in other language like Go or Kotlin.

One team in my company insists on storing everything related to a target in an MB-size Elasticsearch document and then do all the aggregation client-side, because they already use ES for everything else and don't know how to use a relational database.

So, you launched your complete rewrite, without any testings and still make ~100% compatibility with an existing vendor solution. Call me skeptics.

While Eclipse truely have an incredible incremental compiler for Java, IntelliJ's better integration with external build systems like maven and gradle, together with better cross-languages support, was what win me over.

> While MinIO's setup is complex, SeaweedFS's setup is much simpler.

Are you sure you are not talking in reverse?

I find Minio single binary deployment very easy, and you also complained about SeaweedFS's complexity in the previous paragraph.

Maybe, but I'm just talking about the potential here.

Most type of volunteer works require more people, with some level of organizations before it becomes effective.

While open-source software projects are often started by one very good SWE, as a hobby, in his own time: a very low barrier of entry. Plus, a project can live with a solo maintainer for a very long time. Though, I digress that can be detrimental in the long run, like the recent xz-utils fiasco.

To be fair, there are not many professions that a single individual can make so much impact as Software Engineering.

People say 10x Software Engineer, rarely 10x Electrical Engineer.

TIL: Jane Street use OCalm in production

I wouldn't be surprised if that is just a bot.

He even follows me, though I have never published any open-source project on my own.

MapReduce was basically a very verbose/imperative way to perform scalable, larger than memory aggregate-by-key operation.

It was necessary as a first step, but as soon as we had better abstraction, everyone stopped using it directly except for legacy maintenance of course.

It's a long, random password, that you generate anew for each application that needs it: one compromised app can be revoke quickly without affecting other.

But more importantly, app password can only be used for email, not other Google's service, so even if it gets leaked, the impact is severely reduced.