angus_gh

> locking their cards to the hardware

Are you talking about game keycards? Those don't lock to the hardware, you can resell them or lend them to others with no issue

Editions allow making breaking changes to Rust without splitting the ecosystem - no hassle caused to existing code unless it opts into the new edition and its breaking changes. There's currently editions 2015, 2018, 2021, and 2024. When a new edition is introduced, it can make breaking changes such as introducing new keywords, but every previous edition remains supported forever by newer compiler versions.

The key part is that editions are configured per-library - libraries A and B might use editions 2015 and 2021, and your application could use edition 2018 and depend on those libraries, and it works.

If you wrote a library with the original 2015 edition, and never upgraded it to deal with new `async` and `await` keywords added in the 2018 edition, that's totally fine. Newer compilers will continue to compile it in its configured edition=2015 mode, where the new keywords don't exist (so your local variable named `async` still compiles), and new code written against newer editions may still use this 2015 edition library with no issue.

Editions are different from Go version directives because you use them to say "my library needs features added in this Go version", but they don't enable Go to make breaking changes to the language.

Editions can't do every kind of breaking change however - they mostly work for syntax level changes, and don't work for things like tearing out regrettable parts of the standard library.

Java's arrays use a signed 32-bit int as their length, so the longest they can be is about 2 billion elements.

If your code has arrays over a billion elements, then it will fall over the moment someone inputs slightly larger data

The no-gil fork of Python makes the builtin collections thread-safe, so that will remain not an issue (see the "Collection thread-safety" section of the design doc https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsD... )

Sidenote: this website performs poorly on Firefox for Android; every time the background updates, the page freezes for a second, so scrolling is jumpy

Does your suggestion allow passing an extra argument into any of those functions? Like the

    value |> someFunction(1, %, 3)

You can feel secure knowing if you lost your job, any other job you find would at worst pay $2.26 less than you're receiving now, so you wouldn't suffer an awful drop in living standards (and you'd hope it would also pressure your employer to give you a raise..)

The reason you get warned for doing

`logger.debug("Got %s results", num)`

instead of

`logger.debug("Got {} results".format(num))`

is that in the first case, internally it checks if the logger is disabled and if so skips formatting the string, whereas in the second case you've already formatted it before passing it in, so that work can't be avoided. This isn't the case for print statements because they don't execute conditionally, so you don't ever skip doing the format.

You could also override the font-family of the main <code> to make it more readable; since it isn't code there's no need to use a monospace font.

    body code {
        font-family: sans-serif;
    }

Try checking this website for the model of phone you have https://dontkillmyapp.com/

In some ways yes, Java is not so strongly typed; a statically-typed language can be weakly typed.

See C where ints, pointers, floats, and bools can almost all coerce into each other, such that the compiler will allow you to use arithmetic/logic operators with most different types, whether you meant to or not.

As the article says, they examined lots of languages, not just Kotlin (it would be arbitrary to confine their research to JVM languages..)

>> While Java could not adopt the Swift approach wholesale because of existing language constraints, the Java approach took as much inspiration from the good work that the Swift community did as we could -- and left room to take more in the future.

> can you provide links that show most js developers use typescript?

They didn't say most developers had switched, they said most large projects have switched

Where did you get the idea that records can't use annotations, have methods, or implement interfaces?:

"Beyond the restrictions above, records behave like normal classes: they can be declared top level or nested, they can be generic, they can implement interfaces, and they are instantiated via the new keyword. The record's body may declare static methods, static fields, static initializers, constructors, instance methods, and nested types. The record, and the individual components in a state description, may be annotated."

https://openjdk.java.net/jeps/359