fesc

for a few thousands users

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.

I disagree, seems like a pretty standard structure of one directorz per app and inside that subfolders for configuration, secrets, opaque various data. Not complicated at all really.

Why is it obviously wrong?

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

We sometimes call merges "commits" in Git, and, again, leaky abstraction and overloaded term.

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

Some YouTuber talked about this and I think they were pretty on point: Of course for consumers this could all happen in some app on the phone.

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.

Yeah but once per page, which is why it is okay to disable cache as the author wanted to simulate a cold load of each of those pages.

Honestly I don’t understand why not more people use a GUI for git.

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.

What would "integration tests" (that you don't write) look then in your opinion?

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.

The same reason why most people stopped manually editing some random files via FTP to do deployments: to get a proper reproducible, automated and monitored production environment.

But on the other hand it seems that produce is of higher quality in NL on average than in DE.

I stopped reading when the solution for DNS was AWS and the solution for stateful sets was AWS EC2.

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.

I am a little bit disappointed.

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.

What the hell is an OS without a kernel?

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

Except it isn't, so e.g. running containers still need a VM.

I wish macOS had something like WSL built-in.

Great article! I think I knew most of it already but I’ve never seen all of it covered so succinctly and easy to understand!

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.

I am using a small German email provider and I can't remember the last time I got spam.

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.

Yeah, but having that is clearly not aligned with making money. They could make it more difficult or impossible to use headscale at any moment.

If you think Ansible and Docker are solving the same problem you haven’t understood yet why people use containers for deploying software.

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.

Kotlin's co-routines are simply syntactic sugar for simple callbacks

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.

I think right now this Isn’t possible with “normal” Spring because Spring and various other libraries you’ll normally use make heavy use of reflection.

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

Man, there’s a lot of negative comments here. Just to add a different experience: my company loves Nix, it makes it really easy to integrate new tools into the dev/build environment without needing to document which packages, configuration, … a developer needs to apply to their machine manually.

There’s nothing like it, really.

I disagree.

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?

But at least in WhatsApp I can scroll as fast as I want while the App never is stuck.

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

Eh, there have been quite a lot of good Electron apps lately.

Where do you draw the line exactly?

edit: spelling

I feel like the example you gave is pretty bad as to me that's a perfectly sensible function definition. I didn't write Swift from the beginning but I believe a function like this would've been valid Swift from the beginning? Just seem like core features of the type system.

I think Kotlin has the utility methods you have in mind.

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.

Wow, I have never got that error but I haven't used nix-env much.

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.

Then I would look into home-manager and/or nix-darwin if you are on macOS.

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.

So let's say the developer has a Mac and wants to have Go and Node on their machine; how do you specify these versions in a central way so that all team members have the same versions of tools?

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.