Indeed. Escape characters add a lot of additional complexity, footguns, and performance penalties.

Generally a bad idea to use in-band signalling like that. They won’t do anything weird but consider what happens if the actual data contains them.

Well I’m no fan of Python either but it doesn’t describe itself as a scripting language (and neither does Ruby) so I think you’re way off there.

And I dunno about Ruby being a better Python. It looks way worse to me. In particular the story for static type annotation seems pretty dire. The syntax is worse, it’s less popular, and even slower!

I can believe the tooling is better though. Python’s is abysmal (unless they officially adopt uv - ray of hope there but I have zero faith the Python Devs would make such an obvious decision).

Funny because Rails is often touted as the main reason to use Ruby!

Ah yeah you’re right - I missed that.

Yes this is true, but it’s a little advanced for this level so I didn’t mention it. Probably better for beginners to focus on good code style than optimal performance.

Some suggestions:

1. Declare input in the loop. That limits scope which is basically always a good idea.
2. Trim the newline like

let input = input.trim();

This is better in several ways:

1. Simpler
2. Doesn’t allocate a new string.
3. Removes all whitespace at the start and end.
4. It makes input immutable after that line.

Also attempts is never read - you should have got a compiler warning about that.

Otherwise, good work.

Oh yeah I can’t read 😄

I would be extremely surprised if any compiler was smart enough to short circuit that.

I would be a little less surprised if checking the whole string was actually faster anyway though… but I would still bet against it.

You only need to check half of the string, so I think a technically optimal solution would have some take_while and maybe char_indices in there…

Aside from the better solution with iterators that Flipper mentioned, you can also:

• Omit the type annotation for is_palindrome - it will be inferred as bool anyway
• break; after setting is_palindrome = false
• Use the (0..input.len()/2).all(|i| ...) iterator method instead.

Very good points. A codebase that gets this VERY wrong is Gitlab. I think it might be a dumb characteristic of Ruby programs, but they generate identifiers all over the place. I once had to literally give up following some code because I could not find what it was calling anywhere. Insanity.

Another point: don’t use - in names. Eventually you’ll have to write them down in a programming language, at which point you have to change the name. CSS made this mistake. foo-bar in CSS maps to fooBar in Javascript. Rust also made this mistake with crate names. A crate called foo-bar magically becomes foo_bar in Rust code.

It can understand, just not as well.

You can’t confidently say that because nobody knows how to solve the bullshitting issue. It might end up being very similar to current LLMs.

He’s right that it’s probably harder for AI to understand. But wrong in every other way possible. Human understanding should trump AI, at least while they’re as unreliable as they currently are.

Maybe one day AI will know how to not bullshit, and everyone will use it, and then we’ll start writing documentation specifically for AI. But that’s a long way off.

I wouldn’t recommend it. I actually looked up COBOL jobs a while ago, and while they paid more, it was only like 20% more - not enough to make it worth it IMO.

Huh I did not know Roku (the on-the-way-out TV company) made their own scripting language. How bizarre.

Has anyone used Jujutsu and Sapling? Which is better?

Rust async has quite a lot of footguns that other async runtimes don’t have. There are some listed here:

• https://www.qovery.com/blog/common-mistakes-with-rust-async/
• https://google.github.io/comprehensive-rust/concurrency/async-pitfalls.html
• https://bitbashing.io/async-rust.html
• https://carllerche.com/2021/06/17/six-ways-to-make-async-rust-easier/

Honestly if you’re using an async Rust web framework (which they pretty much all are) it may be the path of least resistance to still use async. But in general I would strongly prefer scoped threads, channels, rayon etc.

many simultaneous requests

Unlikely to be so many that threads would be an issue.

Have a go on your free time and see if you like it. There is an absolute ton of free learning material online. You don’t need to pay anyone.

Most programming jobs (e.g. making web sites) are easy enough for the average person to do, but I think most people would find programming far too tedious and boring to learn.

It’s like law - there’s nothing particularly difficult about it but most people find it incredibly mind numbing to read legal documents.

So I would have a go in your free time first to make sure it is something you could do.

I don’t really know anything about Vim so I’d have to take your word for it.