You're right, the developer (or operator) will still need to know how to troubleshoot. For this first stage we're focusing on improving development and iteration speed while maintaining status quo on operating & troubleshooting. One of our design principles is to keep the application debuggable, which means if there's a problem in the application it should be easy for the developer to use the tools and methods they're used to to figure out what's going wrong. Similarly for the infrastructure, since Klotho utilizes existing cloud providers, existing tools are still a good way to debug.
To make sure troubleshooting the code is as smooth as possible, we keep the transformed code as close to the original source as possible. It's important that the code for the application that is actually running in the cloud is recognizable to the authors that wrote it.
Later on, we do plan on trying to tackle this problem (easier to troubleshoot with less knowledge requirement).
I don't think having your infra with your code precludes a lot of these things, depending on how it's done. They're good points, and as engineers we'll likely need to be able to do this for a while (until maybe an AI can).
> Seriously, when shit's on fire, the last thing you want is to be deciphering the magic that brought it to its current state. How many layers to dig thru are there, between "thingctl deploy" and a critical S3 bucket having somehow been deleted?
I see it as analogous to how higher-level languages abstracts machine code. When it was a newer technology, people absolutely needed to debug and analyze the "magic" but as the space has matured that's becoming less and less common.
> I see it as analogous to how higher-level languages abstracts machine code. When it was a newer technology, people absolutely needed to debug and analyze the "magic" but as the space has matured that's becoming less and less common.
The fundamental difference is that you can keep analyzing a program in isolation as much as you like. Infrastructure is a living organism - if you shoot it in the head, you can't copy-paste an old working version over it; you have an outage.
> until maybe an AI can
Why is the solution to every problem always more layers, and never less? We understand running production infrastructure far better than we understand AI.
It's not that I don't appreciate ML/AI - it's fairly impressive what it can do, given you keep nudging it in the right direction - but I would never delegate unsupervised authority to it.
I tried nushell for a few days, but sh syntax is just too ingrained... It slowed me down a bunch and couldn't get over the initial learning curve. Ended up going back to zsh. Also, losing a bunch of completions for tools I used was a bummer. I wish nushell could parse bash/zsh completion scripts or something to help ease the transition.
Maybe I'll revisit it at some point in the future.
It took me about a decade after fish came out for me to finally switch from bash. Nu looks like an improvement over fish, but I expect it will also take me about a decade to bite the bullet and use it. :P
I'm not sure I'd agree that software engineering isn't looking to great right now, though I'll admit that I have a limited set of experience. Even in a boring job, there are things you can find interesting. If you're (re-)implementing the same CRUD interfaces, maybe look at some templating or code generation to cut down on the time that takes - get meta about your work and find new ways to be more productive. Up to you whether you use that boosted productivity to do more work or to spend less time working.
To make sure troubleshooting the code is as smooth as possible, we keep the transformed code as close to the original source as possible. It's important that the code for the application that is actually running in the cloud is recognizable to the authors that wrote it.
Later on, we do plan on trying to tackle this problem (easier to troubleshoot with less knowledge requirement).