I also think we have the data in for memory safety in C. Even the best people, with the best processes in the world seem to keep writing memory safety bugs. The “just be more vigilant” plan doesn’t seem to work.

> FWIW, FAFO is a very good way to learn. Assuming we can respawn indefinitely and preserve knowledge between respawns, driving fast and taking off your seatbelt would definitely teach you more than just reading a book.

Yes, just sucks for the person who you hit with your car, or the person whose laptop gets owned because of your code.

"FAFO" is not a great method of learning when the cost is externalized.

Well, in a language with nullable reference types, you could use something like

  fn find<T>(self: List<T>) -> (T, bool)

to express what you want.

But exactly like Go's error handling via (fake) unnamed tuple, it's very much error-prone (and return value might contain absurd values like `(someInstanceOfT, false)`). So yeah, I also prefer language w/ ADT which solves it via sum-type rather than being stuck with product-type forever.

How does this work if it is given an empty list as a parameter?

I guess if one is always able to construct default values of T then this is not a problem.

> I guess if one is always able to construct default values of T then this is not a problem.

this is how go handles it;

  func do_thing(val string) (string, error)

is expected to return `"", errors.New("invalid state")` which... sucks for performance and for actually coding.

Ideally, but realistically, I have never heard of any major programming language that allows you to express "this function only accepts static constant string literal".

Python has LiteralString for this exact purpose. It's only on the type checker level, but type checking should be part of most modern Python workflows anyway. I've seen DB libraries use this a lot for SQL parameters.

https://typing.python.org/en/latest/spec/literal.html#litera...

Beyond LiteralString there is now also t-strings, introduced in Python 3.14, that eases how one writes templated strings without loosing out on security. Java has something similar with Template class in Java 21 as preview.

We have this in c++ at Google. It's like securitytypes::StringLiteral. I don't know how it works under the hood, but it indeed only allows string literals.

Even PHP has that these days via static analysis https://phpstan.org/writing-php-code/phpdoc-types#other-adva...

In Rust, this can almost be expressed as `arg: &'static str` to accept a reference to a string whose lifetime never ends. I say “almost” because this allows both string literals and references to static (but dynamically generated) string.

For Rust’s macros, a literal can be expressed as `$arg:lit`. This does allow other literals as well, such as int or float literals, but typically the generated code would only work for a string literal.

c++20 offers `consteval` to make this clear, but you can do some simple macro wizardry in c++11 to do this:

    #define foo(x) ( \
        (void)std::integral_constant<char, (x)[0]>::value, \
        foo_impl(x) \
    )

(the re-evaluation of x doesn't matter if it compiles). You can also use a user-defined literal which has a different ergonomic problem.

Not the language, but the linter can do it. IntelliJ inspections warn you if you do it: https://www.jetbrains.com/help/inspectopedia/StringConcatena...

it does seem like something a good static analysis tool should be able to catch though

I always wondered if people actually find it beneficial to follow these "design patterns" or not.

Personally, I prefer to learn FP patterns, which tend to be backed with nice mathematical properties behind them.

But in most cases you probably want something disjoint like Rust's `Result<T,E>`. In case of "it might be success with partial failure", you could go with unnamed tuples `(Option<T>,E)` or another approach.

That's needlessly aggressive. Ignoring webapps, you could do gamedev without even knowing what a matrix is.

You don't even need such construction in most native applications, embedded systems, and OS kernel development.

I am working in embedded. Had to optimize weights for an embedded algorithm, decided to use linear regression and thus needed matrices.

And if you do robotics, the chances of encountering a matrix are very high.

To be fair, I do use matrices a reasonable amount in gamedev. And if you're writing your engine from scratch, rather than using something like unity, you will almost certainly need matrices

Even when using some game engine you need some prior knowledge. Otherwise you are just throwing stuff at the wall and see if it sticks.

This is my exactly point. Even in a highly specialised library for pricing securities, the amount of code that uses matrices is surprisingly small.

I really doubt this.

Even through UE blueprints (assuming the most high level abstraction here) you will come across the need to perform calculations with matrices. While a lot is abstracted away, you still need to know about coordinate spaces, quirks around order of operations, etc.

Has too much sugar, and without JetBrains IDE you're stuck with a plain text editor. Not sure if it's generalizable to normal Kotlin or not, but learning Gradle Kotlin DSL made me want to rip my hair out when trying to understand what happens under the hood.

I think it also depends on the community as well. Last time I touched Node.js and Javascript-related things, every time I tried to update something, it practically guaranteed something would explode for no reason.

While my recent legacy Java project migration from JDK 8 -> 21 & a ton of dependency upgrades has been a pretty smooth experience so far.

Yeah, along with any community's attitudes to risk and quality, there is also a varying, er, chronological component.

I'd prefer to upgrade around the time most of the nasty surprises have already been discovered by somebody else, preferably with workarounds developed.

At the same time, you don't want to be so far back that upgrading uncovers novel migration problems, or issues that nobody else cares about anymore.

Yeah, the JavaScript/Node.js ecosystem is pain. Lots of tooling (ORMs, queue/workflow frameworks, templating) is new-ish or quickly changing. I've also had minor updates cause breakages; semver is best-effort at best.

I don't like Java but sometimes I envy their ecosystem.

There is a reason most of stable companies use Java - stability. Outside of startups and SV, there are few reasons to avoid such a robust system.

Plus you can find endless stream of experienced devs for it. Which are more stable job wise than those who come & go every 6-12 months. Stability. Top management barely cares for anything else from IT.

Like other sibling comment said, I think it's just your personal opinion. I don't think The Greedy Cave is that complex or belong to traditional roguelike category, more like MMO's grindy number game with some microtransaction.

  > I'd like to see a future where more developers have a basic understanding of ML even if they never go on to do much of it. I think we would all benefit from being a bit more ML-literate.

Why "ML-literate" specifically? Also, there are some people against calculus and statistic in CS curriculum because it's not "useful" or "practical", why does ML get special treatment here?

Plus, I don't think a "gotcha" question like "what is gradient descent" will give you a good signal about someone if it get popularized. It probably will lead to the present-day OOP cargo cult, where everyone just memorizes whatever their lecturer/bootcamp/etc and repeats it to you without actually understanding what it does, why it's the preferred method over other strategies, etc.

> Why "ML-literate" specifically?

We could also say AI-literate too, I suppose. I guess I just like to focus on ML generally because 1) most modern AI is possible only due to ML and 2) it’s more narrow and emphasizes the low level of how AI works.