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.

Can't remember tbh. It was a work setup. It wasn't an unreasonable one though. 32 is not very many!

Right, I'm not saying it isn't simpler in terms of syntax. The point I was making is that the syntax is simpler but in a way that makes it worse because while it's easier for computers to read, it's harder for humans.

it was only later discovered that they can be compiled down to native code.

That sounds extremely unlikely. I think you're misinterpreting this quote (which is fair enough; it's not very clear):

Steve Russell said, look, why don't I program this eval ... and I said to him, ho, ho, you're confusing theory with practice, this eval is intended for reading, not for computing. But he went ahead and did it. That is, he compiled the eval in my paper into IBM 704 machine code, fixing bugs, and then advertised this as a Lisp interpreter, which it certainly was. So at that point Lisp had essentially the form that it has today ...

As far as I can tell Lisp was always intended to be compiled and executed. That quote is about compiling the eval() function (which was just meant to explain how Lisp is executed) into a binary and using that as an interpreter.

Also I skimmed the paper that is from, and in fact Lisp was intended to be targeted by AI (in the same way that we get AI to write and execute Python to solve problems), which explains a lot. It wasn't designed for humans to write, so why bother with nice syntax; just have the machine write the AST directly!

(I expect that was only part of the motivation tbf, but still!)

Actually chars() is pretty simple - it's just UTF-8 decoding which is elegant and simple.

The complexity is all around unicode, not UTF-8.

This is awesome. It gets closer to Deno which I think is one of the only things that have actually solved the "ad hoc scripting" challenge, which requires:

1. Easy to install language.
2. Easy to use third party dependencies (from a single file script).
3. Easy to import from other files without setting up a whole project.
4. IDE support.

At one end we have Deno which nails all of those. At the other, Python which fails all of them pretty miserably (despite this being one the most popular use cases for Python).

Seems like with this Rust will have 1 and 2 solved, and I guess 4 isn't too hard. What about 3 though?

If I eventually decide I want to split my one file script into two files will I be able to?

Edit: I had a play and actually it's good news!

• If you want to split up a script you can just do mod foo and it will look for foo.rs (or I guess foo/mod.rs) in the same directory!
• For common code, which you might want to import from e.g. ../../common you can't just use mod but you can add common = { path = "../../common" } to [dependencies]. That directory has to be a proper crate with Cargo.toml but I think that's ok and probably desirable.

The only downsides I found are:

1. No IDE support yet.
2. It prints compilation messages to stdout, which kind of sucks.
3. Even after it has been built, it still does incremental compilation every time you run it, leading to more compilation message noise, and ~100ms startup time.

This is 14 years old by now - hardly "modern". RAII itself is even older.

Ah the old "I don't make mistakes" classic. Some weapons grade hubris here...

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.

It's not really messaging that's the differentiator here - it's scale (specifically write scale). If you can't have a single master database then sure you might need NoSQL. But you almost certainly aren't anywhere near that scale. Giant sites like Stackoverflow and Shopify aren't.

1. If your alternative is C++ then it removes the enormous burden of manually tracking lifetimes and doing manual memory management. C++ does have RAII which helps with that enormously but even then there are a gazillion footguns that Rust just doesn't have - especially with the newer stuff like rvalue references, std::move, coroutines etc. It also saves you from C++'s dreaded undefined behaviour which is everywhere.

2. It has a very strong (and nicely designed) type system which gives an "if it compiles it works" kind of feel, similar to FP languages like Haskell (so they say anyway; I've not used it enough to know). The borrow checker strongly pushes you to write code in a style that somehow leads to less buggy code. More compiler errors, but much less debugging and fixing bugs.

3. The libraries and APIs are generally very well designed and nice to use. If you've ever used Dart or Go think how nice the standard library is compared to JavaScript or PHP. It took C++ like 2 decades to get string::starts_with but Rust started with it (and much more!).

4. Fast by default.

5. Modern tooling. No project setup hassle.

6. It's a value based language, not reference based. References are explicit unlike JavaScript, Java, C#, etc. This is much nicer and makes things like e.g. copying values a lot easier. JavaScript's answer for ages was "serialise to JSON and back" which is crazy.

Downsides:

1. Slow compilation sometimes. I'd say it's on par with C++ these days.

2. Async Rust is kind of a mess. They shipped an MVP and it's still kind of hard to use and has unexpected footguns, which is a shame because sync Rust avoids footguns so well. Avoid async Rust if you can. Unfortunately sometimes you can't.

3. Interop with C++ is somewhat painful because Rust doesn't have move constructors.

Great language overall. Probably the best at the moment.

All the old people have learned the old systems (C, Perl, etc) and don't want to have to learn something new, whereas young people are happy to use something newer and better (Rust, Typescript, etc.) because they don't mind learning and don't have a ton of old knowledge to throw away.

Yes that's a big generalisation and there are plenty of exceptions, but in my experience it's broadly true.

I work on an open source project which has a C component. I offered them our closed source C++ version which is way better and fixes a load of issues... Not interested. They learnt C in the 70s and don't see why they should have to change.

Actually that project is a mix of old curmudgeons and young PhD students so there is a bit of a mismatch, but I didn't feel like fighting the naysaying so...

Python lets you add static type annotations to your program, so you can say "this variable should be and int or a string", and that means Pyright (a fantastic static type checker) can tell you if you screw up and forget that it might be a string.