I have a hard time agreeing that exceptions (as they exist in kotlin, unchecked) are superior. There is no way to communicate (outside of docs) to callers that a function is possibly unsafe and that they should handle it.
Good callout on the stdlib `Result`, a lot of people aren't aware of the `CancellationException` issue. Another pain point is that the error is constrained to `Throwable`, which is rather obtuse for general business logic (and you're likely generating stack traces needlessly unless you disable `writableStackTrace` on your custom throwables).
I'm a fan of https://github.com/michaelbull/kotlin-result which has a fantastic API and supports monad comprehension which helps avoid the "arrowheads" from not having a built in operator.
Author here. I have no idea what you could possibly mean with this comment. The coroutineBinding implementation correctly uses the coroutines API for parallel decomposition of Result bindings, exactly how the Kotlin Coroutines guide tells you to, backed by a Mutex[1]. The coroutineBinding isn't even the main selling point of the library, you can use it without using this feature entirely.
Please could you elaborate on what "looking thread safe" means to you? The only portion of the library that supports concurrency *is* thread safe - the unit tests[2] prove it and the use of concurrency primitives such as Kotlin's Mutex[3] are indicative of this.
I truly have no idea how you've judged the entirely of the library on whether it's "thread safe" when there is a single function (in an extension library, not the core one) that's related to concurrency and it is very clearly using concurrency primitives as intended.
With regards to "being cautious using it", you don't need to be. The maven central statistics suggest its being downloaded 300,000 times per month. If there was something wrong with it, it's likely somebody would have raised this already given how frequently the project has been adopted over the last seven years.
I don't see the connection you're making between knobs that adjust runtime behavior and tooling. As an aside, "you can't just run java code" is a bit hyperbolic, plenty of people "just run" java apps and rely on the default ergonomics. The modern JVM also offers more automated options, such as ZGC which is explicitly self tuning.
I think I’m missing something, because I’m pretty sure you understand the go module proxy (having seen you around here before) but I really don’t understand what problem you’re talking about.
If a module author deletes or relocates their module, the old module is not deleted or renamed from the module proxy. It is kept around forever. Code that depends on it to not break does not break.
If they relocated and you want to update to the new location, perhaps for bug fixes, then you do have to do a bit extra work (a find and replace, or a module level replace directive) but it’s a rare event and generally a minor effort, in my opinion, so I don’t think this is a significant flaw.
For most users most of the time they don’t need to think about this at all.
> good luck doing just run when a code repo breaks all those URL hardcoded in source code
You're on a tear in this thread being wrong about how Go works, but I'm really curious what extremely specific series of events you're imagining would have to happen to lead to this outcome. If I use a dependency, it gets saved in the module proxy, I can also vendor it. You would have to, as a maintainer, deliberately try to screw over anybody using your library to accomplish what you describe.
They use a ton of java, they even have their own distro. In fact, they answer this question on its landing page (https://www.microsoft.com/openjdk):
> Java at Microsoft spans from Azure to Minecraft, across SQL Server to Visual Studio Code, LinkedIn and beyond! We use more Java than one can imagine.
Counting Minecraft as a somehow important use of java in Microsoft is pretty funny when they bought the company that introduced it and then rewrote it from scratch in c++ for w10
Having little experience with k3s, how big of a workload (“nodes” aka virtual kubelets, pods, crds, etc) can you have before saturating the non-HA control plane becomes a concern?
That’s exactly what I pivoted to once I realized my naive replace wouldn’t work. That sort of moment is what makes AoC feel so rewarding in my opinion.
It’s not immediately obvious to me how this differs from something like ansible which people have been using for years for basic deployment topologies. What am I missing?
edit: after looking a bit closer, I think it’s a bit misleading to call what this is doing “zero downtime”. as far as I can tell, your services are essentially going to be unresponsive until they start, which can be brutal for slow starting ones (and that’s assuming they start successfully)
There is a project by a RSPS community member to accumulate all caches (https://archive.openrs2.org/) by similarly asking people, pulling from other archives, etc. This is probably the best archive in the rsps scene / I'm sure they are aware of it, there are just caches nobody has.
Good callout on the stdlib `Result`, a lot of people aren't aware of the `CancellationException` issue. Another pain point is that the error is constrained to `Throwable`, which is rather obtuse for general business logic (and you're likely generating stack traces needlessly unless you disable `writableStackTrace` on your custom throwables).
I'm a fan of https://github.com/michaelbull/kotlin-result which has a fantastic API and supports monad comprehension which helps avoid the "arrowheads" from not having a built in operator.