fesc

It makes absolutely no sense to base this decision on the number of users. We have some applications that don't even have 10 users but still use k8s.

Try to understand the point that was made in the original comment: Kubernetes is a way to actually make infrastructure simpler to understand for a team which maintains lots of different applications, as it can scale from a deployment with just one pod to hundreds of nodes and a silly microservices architecture.

The point is not that every application might need this scalability, no the point is that for a team needing to maintain lots of different applications, some internal, some for customers, some in private datacenters, some in the cloud, Kubernetes can be the single common denominator.

Hell, I'm a hardcode NixOS fan but for most services, I still prefer to run them in k8s just as it is more portable. Today I might be okay having some service sitting on some box, running via systemd. But tomorrow I might want to run this service highly available on some cluster. Using k8s that is simple, so why not do it from the start by just treating k8s as a slighly more powerful docker-compose.

During a duration of time it is okay so say an amount of energy (MWh) was produced, right?

You abuse the term leaky abstraction here. That isn’t a leaky abstraction as a merge commit is literally a commit, isn’t it?

But a 3rd party app will always be less integrated, have less permissions than functionality included by the manufacturer.

And for all this AI integration wide access is pretty much required as you'd want it to access your photos, notes, all kind of apps, etc.

This way manufacturers would have too much leverage over companies developing that kind of AI, as they could always develop better features than them with their own AI agent.

I think Apple Watch is a pretty good example of that already. Third party watches will never be as good as Apple Watch just because Apple won't let them.

  Testcontainers is awesome and all the hate it gets here is undeserved.

  Custom shell scripts definitely can't compete.

  For example one feature those don't have is "Ryuk": A container that testcontainers starts which monitors the lifetime of the parent application and stops all containers when the parent process exits.

  It allows the application to define dependencies for development, testing, CI itself without needing to run some command to bring up docker compose beforehand manually.
  
  One cool usecase for us is also having a ephemeral database container that is started in a Gradle build to generate jOOQ code from tables defined in a Liquibase schema.

What you describe would be 1 Minute of work and maybe 10 clicks with a very low probability of shooting yourself in the foot in Tower.

I ask because in my team we also a long time made the destinction between unit/integration based on a stupid technicality in the framework we are using.

We stopped doing that and now we mostly write integration tests (which in reality we did for a long time).

Of course this all arguing over definitions and kind of stupid but I do agree with the definition of the parent commenter.

This is just a very weird comparison. Seems like the author doesn’t understand why people run K8s.

Of course they also “managed” several k8s clusters using… wait for it… AWS.

I’d say, when you are all in AWS, then fine don’t use k8s. But you also don’t need Nomad then in most cases.

And if you do need nomad on AWS then that’s fine as well, but it’s not comparable to k8s in general.

This is just plain old static site generation?

By "docs as code" I expected something like programmatically verifying that the code examples compile, maybe even spinning up VMs and testing that the example commands lead to the expected output.

Is this less an OS and more like a toolchain to build container images?

I wish macOS had something like WSL built-in.

I think in the case of Nix it is especially important to have a good grasp of the fundamentals so that you can verify your (possibly wrong) assumptions when troubleshooting a build failure, evaluation failure or when using the higher level constructs of nixpkgs.

What's even crazier is that they are so confident in their spam filter that they simply reject mails classified as spam. But that hasn't been a problem since the few years I have been using them as well.

We use them because then what’s running in prodcution is 100% the same as is running locally when testing the application.

You can hardly get there using Ansible.

That's only partly true. And yeah they're callbacks but not like e.g. we know from JS.

As far as I know CPS basically means that the Kotlin compiler turns a function like that:

    suspend fun myFunction(param: String) {
      val asyncVal = someSuspendingFunction()
      val asyncVal2 = anotherSuspendingFunctio(asyncVal)
      return someCalculation(asyncVal2)
    }

     // The different parts of the function get put into different ifs
     // The state that is normally in the JVM stack frame is holded in a custom class which is a subclass of https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.coroutines/-continuation/
     // Some integer tracks where in the function we are
     fun myFunction(param: String, continuation: Something<MyFunctionClass>?) { 
        continuation = continuation ?: MyFunctionContinuation(param)
        if (continuation.state == 0) {
          contination.state = 1
          someSuspendingFunction(continuation)
          return SUSPEND
        }
        if (continuation.state == 1) {
           // The result mechanism is in the Contiuation interface/abstract class. It can be used to later receive the async result
           // of callig annother suspending function
           continuation.asyncVal = contiuation.getResult()
           anotherSuspendingFunction(continuation.asyncVal, continuation)
           return SUSPEND
        }
        if (continuation.state == 2) {
           continuation.asyncVal2 = contiuation.getResult()
           return FINISHED(someCalculation(continuation.asyncVal2))
        }
     }

     class MyFunctionContinuation: Continuation {
        
        // Function arguments
        val param: String
        
        // Every suspending function needs this. It tracks where in the function we currently are
        val state: Int = 0
       
        // Local variables inside the function. Those would normally live in the JVM function stack 
        // But the  Coroutine runtime needs to be able to "rehydrate" the JVM function stack once a non-blocking call finishes
        var asyncVal: <Don't remember>
        var asyncVal2: <Don't remember>

     }

I read this sometime in some book about coroutines. But you can see that there is some overhead. The basic idea is to replicate the function call stack in a custom datastructure. This way we can be deep inside a normal JVM callstack and also have a separate Kotlin Coroutine callstack.

Once the coroutine wants to suspend it can simply return from the JVM callstack but the Kotlin callstack is preserved. Later when we want to continue we can call the same function again, with the Kotlin callstack now containing the result of the async operation.

If the JVM can do this natively we wouldn't need this second Kotlin coroutine callstack because the native JVM callstack would support this.

Frameworks like Quarkus and Micronaut have been written with native in mind and I think Spring is also working on it (Spring Native).

There’s nothing like it, really.

Yeah, you always start out with K/V pairs but it never takes long until you need the same configuration but just with a slight tweak here or there. For example consider the same configuration but for different running environments.

People always come up with custom solutions per tool which some sort of metaprogramming, again in YAML. This is just bonkers IMO.

So why not just use a proper language from the beginning?

With iMessage it loads for seconds every 20 messages or so. I also really don't get it.

Where do you draw the line exactly?

edit: spelling

Im not saying C# is bad as I don‘t have experience with it, just that Kotlin is a more realistic replacement for most Java shops.

Yeah, to be honest familiarity with the NixOS module system doesn't hurt for home-manager. For me it was worth it but I was also just interested in Nix enough to read through the Nix-pills, etc.

Maybe given some time Nix will be polished enough that a smaller time investment will be enough.

Another thing: Yes, even if customizing your home-manager config could lead to hard to debug errors, once it works it is hard to brick and it will most likely work on new Laptops, colleagues machines, ...

That's why for my small at work my colleagues don't have to be as deep into Nix as I am but they can still benefit from the changes I am introducing in a pretty "safe" way.

I think under the hood home-manager basically declaratively manages a Nix profile for you. You (or even better a home-manager managed .bash_profile) can then put that profile into your PATH.

The easiest setup would be to use `nix-shell`. This would also have the benefit that you could have different versions for different projects.

If you also install `direnv` on the machines you can use `use nix` in the `.envrc` file to automatically load the packages that are declared in `shell.nix` into the PATH once a developer enters the project directory in the terminal.

Containerization is also one thing that's awesome about Nix: Instead of saying: "start with image xyz, then run apt-get to install further software, then do some cleanup" you can just say "please build me an image with e.g. jdk11 and openssl".

Nix will put everything into the image thats required for those packages, not more, not less. And for Nix that's easy to: It just has to put all the packages in a tar file and call it a day (more or less).

At work we use this for Java Spring Boot projects and we started using Nix container images in production as well.

For development we still use a JDK installed through IntelliJ as it is not that easy to teach IntelliJ about a JDK installed through Nix.

But on CI and when running the project from terminal we can use exactly the same JDK as in the container images.