In one of my work projects it was the Turkish İ that gave us trouble. In some case-insensitive text searching code, we matched the lowercase query against the lowercase text, and had to handle cases like that specially to avoid reporting the wrong matching span in the original text, since the lowercase string would have a different length than the uppercase string. This was one of my first real-world projects and opened my eyes a bit to the importance of specifications and standards.

Can't mention the Turkish case situation without mentioning the actual murder that took place because of it: https://languagelog.ldc.upenn.edu/nll/?p=73

The murder is a tragedy, of course, but I would hesitate to blame the cellphone. There’s overreactions, and then there’s… this.

In PHP the Turkish locale caused quite some trouble. In some situations a different locale was used for compiling and for runtime while handling "case-insensiteve" identifiers, fo that sometimes names with an "I" could not be found anymore.

I had this exact bug with the same character:

https://github.com/rendello/layout/issues/8#issuecomment-235...

I haven't had this experience with TypeScript. In the projects I've worked with, we turn on strict mode and heavily discourage using `any`. I generally feel pretty confident that the type annotations match the runtime values.

But where do you store the URL for the S3 bucket? Can you really say it's usefully preserved if nobody knows the URL (or the account credentials)?

IMO the formatting of the error string returned by errors.Join is atrociously opinionated and not very logging-friendly - it adds a newline between each error message. I know I'm not the only one that has this opinion

It's a trivial function: https://cs.opensource.google/go/go/+/refs/tags/go1.23.1:src/...

You could write your own errorsJoin() and change Error() method to suit your needs.

But really in this particular scenario you would be better served by something like:

    func errorsConcat(err1 error, err2 error) error {
      if (err1) {
        return err1;
      }
      return err2;
    }

And then do: err = errorsConcat(err, f.Close())

In the scenario described in this article, errors.Join() would most often reduce to that (in terms of what Error() string would produce).

Wouldn't you use slog if you want logging friendly?

I think you are conflating ES6 classes with TypeScript.

Static/strong typing is not necessary in JS.

Yes, ES6 brings the OOPiness

That’s just like your opinion, man.

Just because you think that doesn’t mean it’s true. The sheer fact that TS has overtaken JS for the majority of web development says enough.

> TS has overtaken JS for the majority of web development

Has it? Or is that "just like your opinion, man"? Any citation? There's some sources that say it's more popular based on things like social mentions, etc, but that's a vanity metric. Perhaps the statement is true if you mean "web development" to be a very limited scope (like SPA using a build step), but I'm not even sure that's true then.

For new, modern projects, yes. Very much so. There is practically no reason to choose JS over TS, even for high performance projects where every byte counts and you may want stricter control over the transpilation. The ecosystem has grown to the point where other optimizations like tree shaking do far more, and the improvement in the local dev cycle is insurmountable between the two.

Obviously this doesn't apply to existing projects; you're grandfathered into the language barring a pretty big undertaking to move over, but if you go to any competent company doing modern web development on relatively new codebases, they will use TS over JS.

And if they don't, as an engineer, you should ask hard questions as to why not. Because if the answer is someone stuck in the early 2000s complaining about OO and strong typing not being needed, then that's completely missing what TS does (and especially what it did when it was released, which was pre-ES5) and how big of an impact it has to speeding up development.

I don’t think your comment could be interpreted as anything other than snarky and rhetorical.

Nevertheless, it is of course very well known that efficient code in JavaScript will never run as fast as in a language such as C, but choice of language is a trade off, and in whatever language you choose you may also choose to be as “high performance” as possible within it even if it’s still not as performant than if you’d chosen a different language.