CactusRocket

> In what sense Israel is not a theocracy.

I find this very disingenuous because the person you replied to was talking only about Iran, and stating that Iran is a theocracy in their opinion. They never mentioned anything about Iran, let alone stating that Israel isn't a theocracy.

So asking this question, this way, is quite strange in my opinion.

I tend to disagree with that, also. :) Even within one codebase there's immense value in having separate structs/classes per "layer" or domain. E.g. a different set of structs for the database layer than for the "business layer" (or whatever your application's internal setup is).

When that boundary is moved to outside the application, so an HTTP API between microservices, I feel even more strongly (though indeed still not as strongly as in what you call a "public API").

E.g. I have seen plenty of times a situation where a bunch of applications were managed within one team, the team split up and now this "internal API" has become an API between teams, suddenly making it "public" (when viewed from the teams perspective).

I think you and I read a different article. For example, about treating JSON keys without case sensitivity:

> In our opinion, this is the most critical pitfall of Go’s JSON parser because it differs from the default parsers for JavaScript, Python, Rust, Ruby, Java, and all other parsers we tested.

It would be kind of difficult to argue that this is not about Go.

Don't get me wrong, I love Go just as much as the next person, but this article definitely lays bare some issues with serialization specific to Go.

I think I didn't explain myself well.

As long as a language has bytes and arrays, you can implement anything on top of them, like unsigned integers, 8-bit strings, UTF-8 strings, UCS-2, whatever you want. Sure it won't be native types, so it will probably be slower and could have an awkward memory layout, but it's possible

Granted, if a language is so gimped that it doesn't even have integers (as you mentioned JavaScript), then that language will not be able to fully support it indeed.

I think it's just kinda dumb parsing. E.g. JSON is an extremely simple spec. Most of those issues that the Go JSON parser has, are because of specific choices of the Go implementation, not about JSON. The fact that it allows case-insensitive key matching is just insane. Also that it parses invalid XML documents (with garbage) into valid structs without returning an error is very much a problem with the parser and not with XML.

I imagine that one of the points of a solid protocol buffers library would be to align the types even across programming languages. E.g. explicitly force a 64-bit integer rather than "int" relying on the platform. And to have some custom "string" type which is always UTF-8 encoded in memory rather than depending on the platform-specific encoding.

(I have no idea if that is the case with protobuf, I don't have enough experience with it.)

If you use the same struct in both an HTTP API and an ORM, you're Doing It Wrong in my opinion. These should be completely separated. Exactly to prevent accidental leaking or injection of data.

That's the whole point of the first item in the article, and the original comment you were replying to. In Go (and some other languages) that formatting is implicit and automatic. So you need to write to code to NOT format the fields out. Which leads to the potential security issues where data is leaked, or you can inject data into "hidden" fields. So since it's implicit and automatic, it's safer to, as a rule, define separate structs for the data input and map them, so that there is absolutely no chance (implicit or explicit) to leak or inject data.

I feel like "perfect is the enemy of good" only works when you (still) have to put considerable effort to make it better, e.g. when building software.

However currently there are already better alternatives than Signal, so in my personal opinion I feel like that saying does not apply.

It's very fine if you (and most people) are OK with sharing some personal information with a United States organization. That does not mean that everybody is fine with that, or that it's a very good solution to a chat service problem. I'm glad that Signal is a good match for your needs. But there are those of us who would rather see a decentralized service with which no personal information has to be shared.

In these kinds of discussions, I often find it a little strange when others decide that a certain solution or product must be good for everyone only because they are fine with it themselves.

I think in this day and age, it's "fine I guess" that it's set up that way: most services do that. But going forward, I think it's much better if services work in the way that e.g. email and IRC work: decentralized and federated. Nobody can know what will happen with Signal, or the USA in general. We'll be having this whole conversation about switching chat clients again in a couple of years. Whereas with a decentralized service, it doesn't matter. Anyone can build the software, anyone can run a server. Regardless of what happens to the people or organizations behind it.

Could it be Consolas? It would make sense I believe it's the default monospace font on recent Windows.

Thoughts go faster than fingers. It's already hard enough to keep up with my stream of thoughts when coding, when I'm touch typing pretty fast. I can't imagine my coding experience if I had to look at the keyboard to input my thoughts into the editor. It's subjective, everyone has a different experience, but I feel I would be severely impaired.

The Telegram clients are actually open source and I think pretty solid. The Matrix protocol is open, federated, and secure, but the clients are kinda janky. I've been playing with the idea of what if someone were to fork the Telegram clients and modify them to work with Matrix. That would be a "best of both worlds" situation I think.

I think in general Total War and its genre is relatively niche. While almost everybody is up for a bit of cartoony racing.

You need to install the phone app to be able to activate it. If you've been offline on the desktop app for too long, you need the phone app again to re-active the desktop app. I've also noticed a lot of issues synchronizing messages between computers using the desktop app, without having the app on a phone.

They allow usernames as an alternative to sharing your phone number with other people. You still need a phone number (and the phone app) to create and activate an account.

It's very phone-first.