6 ms·

So choose boring technology (as in old and tested) and... new technology? He likes to use SQLLite, but also S3? So all technologies. Thanks, i guess?

gwd 2y ago
At this point I don't think S3 counts as a new technology anymore.
biorach 2y ago
S3 is around since 2006 and is the default choice for object storage for many people. It's as boring as it gets.
- simonw 2y ago
  Yeah SQLite and S3 aren't that far apart in age - SQLite first came out in 2000, S3 in 2006. First release of Go was 2009.
Cthulhu_ 2y ago
My personal takeaway in a broader context is that Go code is pretty boring, predictable and repetitive as opposed to clever and customised, therefore in theory LLMs can more easily predict and generate said code. It's a tradeoff, Go can be more verbose because it's not as expressive, but using the right tooling, that labor/toil is reduced.
- moffkalast 2y ago
  The older the tech, the more training data should be available for it (assuming it's still being used today), ergo LLMs will be a lot better at it. They ought to be way better at Cpp or JS than Golang in that sense.
  - pyrale 2y ago
    Fortran is so back in business!
  - WJW 2y ago
    I don't think this is true: the older the tech, the less hype it has and thus the less blog posts/example repos/etc will be available. In particular, a boring language without a strong open source culture (COBOL, say, or Oracle SQL) will probably not have a lot of training data available despite being very much in use.
- zelphirkalt 2y ago
  But given the idea of the post, people should never have adopted Golang and Golang itself could never have risen to its current level of use.
- pyrale 2y ago
  Use a language with lots of boilerplate code so the LLM can generate more code for you?
  - loa_in_ 2y ago
    Being explicit without concerns about being terse is something that wasn't practical before assisted coding and that would be a realisation of some of most important tenets of computer science.
    - kaba0 2y ago
      Terseness is not only about practicality. Even if AI writes it for me, it requires a huge deal more reading comprehension on my part to properly check it. E.g. an if err block every couple lines will actively hinder reading that code, and is an easy source for errors to hide (no, just because you check the value of err doesn't make it proper error handling).
    - pyrale 2y ago
      > something that wasn't practical before assisted coding It still isn't practical if you read more code than you write, unless you also use a LLM to summarize the code for you.
- pcwelder 2y ago
  The simplicity of golang definitely helps. Between golang and rust, chatgpt has much easier time with golang. The standard toolchain (as opposed to python packaging) makes it easier for LLM to debug and run commands. So it's easier to develop a golang based app over python using poetry or uv.
markusw 2y ago
As others have said at this point, S3 hardly counts as new tech anymore. But even if you disagree, S3 is conceptually super simple: put binary blobs, get binary blobs, delete binary blobs. I trust the blobs to be there when I need them. I don't have to think about storage size at all, maybe not even backups (depending on use case). I still have to worry about network, but that isn't really that much different from disk access that can fail. So yeah, I think S3 counts as boring. :)

gwd 2y ago

At this point I don't think S3 counts as a new technology anymore.

biorach 2y ago

S3 is around since 2006 and is the default choice for object storage for many people. It's as boring as it gets.

simonw 2y ago
Yeah SQLite and S3 aren't that far apart in age - SQLite first came out in 2000, S3 in 2006. First release of Go was 2009.

Cthulhu_ 2y ago

My personal takeaway in a broader context is that Go code is pretty boring, predictable and repetitive as opposed to clever and customised, therefore in theory LLMs can more easily predict and generate said code. It's a tradeoff, Go can be more verbose because it's not as expressive, but using the right tooling, that labor/toil is reduced.

moffkalast 2y ago
The older the tech, the more training data should be available for it (assuming it's still being used today), ergo LLMs will be a lot better at it. They ought to be way better at Cpp or JS than Golang in that sense.
- pyrale 2y ago
  Fortran is so back in business!
- WJW 2y ago
  I don't think this is true: the older the tech, the less hype it has and thus the less blog posts/example repos/etc will be available. In particular, a boring language without a strong open source culture (COBOL, say, or Oracle SQL) will probably not have a lot of training data available despite being very much in use.
zelphirkalt 2y ago
But given the idea of the post, people should never have adopted Golang and Golang itself could never have risen to its current level of use.
pyrale 2y ago
Use a language with lots of boilerplate code so the LLM can generate more code for you?
- loa_in_ 2y ago
  Being explicit without concerns about being terse is something that wasn't practical before assisted coding and that would be a realisation of some of most important tenets of computer science.
  - kaba0 2y ago
    Terseness is not only about practicality. Even if AI writes it for me, it requires a huge deal more reading comprehension on my part to properly check it. E.g. an if err block every couple lines will actively hinder reading that code, and is an easy source for errors to hide (no, just because you check the value of err doesn't make it proper error handling).
  - pyrale 2y ago
    > something that wasn't practical before assisted coding It still isn't practical if you read more code than you write, unless you also use a LLM to summarize the code for you.
pcwelder 2y ago
The simplicity of golang definitely helps. Between golang and rust, chatgpt has much easier time with golang. The standard toolchain (as opposed to python packaging) makes it easier for LLM to debug and run commands. So it's easier to develop a golang based app over python using poetry or uv.

markusw 2y ago

As others have said at this point, S3 hardly counts as new tech anymore. But even if you disagree, S3 is conceptually super simple: put binary blobs, get binary blobs, delete binary blobs. I trust the blobs to be there when I need them. I don't have to think about storage size at all, maybe not even backups (depending on use case). I still have to worry about network, but that isn't really that much different from disk access that can fail. So yeah, I think S3 counts as boring. :)