Never? Never is a long time.

That said, by the time you can actually run a significant software company without any programmers it seems likely that you could also run most white collar firms with vastly fewer employees and then we're going to have bigger problems.

Those two things are related.

Good.

That's a fair point. I don't think that's the case here because he talks about all the bad ways he prefers to receive contributions (email, patch files, git bundle etc.).

Hmm I think just using SQLite or DuckDB with normalised data would probably get you 99% of the way there...

Config should be pretty flat.

Why? I don't see any reason for that.

TOML rocks precisely because it nudges you into making simpler configs.

This is just "you're holding it wrong".

In most cases you don’t, and when you do, it’s possible and not unreasonable.

Really. Here's the first Gitlab CI example I could find:

lintDebug:
  interruptible: true
  stage: build
  script:
    - ./gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint
  artifacts:
    paths:
      - app/lint/reports/lint-results-debug.html
    expose_as: "lint-report"
    when: always

Let's see the TOML:

[lintDebug]
interruptible = true
stage = "build"
script = [
  "./gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint"
]

  [lintDebug.artifacts]
  paths = [ "app/lint/reports/lint-results-debug.html" ]
  expose_as = "lint-report"
  when = "always"

Gross. The tool I used to convert even added extra indentation because otherwise it is unclear.

IMO JSON5 is the best:

{
  lintDebug: {
    interruptible: true,
    stage: 'build',
    script: [
      './gradlew -Pci --console=plain :app:lintDebug -PbuildDir=lint',
    ],
    artifacts: {
      paths: [
        'app/lint/reports/lint-results-debug.html',
      ],
      expose_as: 'lint-report',
      when: 'always',
    },
  },
}

This is much clearer than TOML and less ambiguous than YAML. It could do without the outer {}, but overall it's still better.

I think those jobs are a myth. You probably get like a 20% premium for using COBOL, so if you look up the salary of a Cobol consultant in America it's going to seem like an enormous salary on an absolute scale.

But so is a C++ consultant in America or whatever. Probably not worth learning COBOL for.

Feel free to correct me if I'm wrong, but I have looked once or twice and the COBOL salaries seemed entirely normal.

I dunno maybe once a week or so? We don't actually have a system that detects if your pip install is out of sync with pyproject.toml yet so I run it occasionally just to make sure.

And it runs in CI around a dozen times for each PR. Yeah not ideal but there are goodish reasons which I can explain if you want.

they wouldn’t have made a different tool altogether if it was really a 1:1 replacement

Why not? It's 10x faster.

I think it might have some other new features but you don't need to use those.

i doubt one person on the team could be using uv while everyone else sticks to pip

This is exactly what we do at work. There's no way I could convince everyone to switch to uv so I just switch between them based on an environment variable.

It even supports random stuff like pip install --config-settings editable_mode=compat --editable foo which is required for static tooling to work (e.g. Pyright).

Matthias Wandel has a video on this is YouTube. He didn't talk about it they keyboard is any good though which I think is probably the most important thing.

Yeah I think RISC-V is probably still about 10 years away from being a sensible choice for a laptop. There's a load of platform stuff around things like ACPI and Device Tree that's still being decided. Also some ISA extensions that are standard on x86/ARM are either unratified or very recently ratified (e.g. Vector).

For microcontrollers it's ready now, and for server applications it's probably doable now and will be solid in a few years. Laptops & phones will be last though.

You can count Ruby out immediately. Terrible language.

Also replace JavaScript with Typescript. It's strictly superior.

I don't think Go has any mature GUI libraries.

For desktop GUI your main options are:

• Qt, via C++. Probably the best option but if you don't know C++ that's a huge barrier.
• Qt, via Python. Reasonable but Python is quite a shit language. It's very slow and the tooling/infrastructure is absolutely abysmal. Be prepared to bang your head against the wall trying to e.g. get relative imports to work.
• Dart/Flutter. This is quite nice but not super mature for desktop apps. Also the Dart ecosystem is very small so libraries you want may not be available.
• Electron/Typescript. This is quite a good option. Nobody here will recommend this because nerds have a slightly weird hatred of Electron because the minimum download size is like 80MB. But normally it doesn't really matter. Especially for big apps.

For the web frontend you basically want Typescript. For the backend you can use literally any language.

I would recommend Electron for the GUI and Typescript for the web frontend and Electron GUI. It means you can use the same language everywhere and you won't need to even implement the same program twice.

If you're worried about the download size / RAM usage you can look into Tauri which uses your OS's browser engine. I've never used it though.