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.

Also depends on where you're coming from. My friends use WhatsApp and I don't because of privacy considerations. If they switch to Signal, I might still not use it because they want my phone number (and their servers are centralized, owned by one organization). So for them, amongst each-other, it would be fine to all switch to Signal probably. But for those of us who have been avoiding it altogether so far, it might not change anything whatsoever.

It's not in the same ballpark, but this entire topic is about "An Ethical Replacement for WhatsApp". Should we then accept potential privacy issues with another service, if they are somewhat of an improvement overall? Or should we rather strive to find an alternative which also addresses or avoids those potential privacy issues.

I've been really hesitant to view Signal as a privacy friendly alternative to WhatsApp, because they still don't offer any way to make an account without a phone number, while a phone number is definitely not required to run a chat service.

Also the fact that servers are run by just one organization is very troubling to me. It's just not the right direction.

Conversely I've been using Signal on 2 laptops and a PC for only a couple of weeks, and I face issues of messages not synchronizing approximately once a week...

I don't really use Whatsapp, or any IM client on my phone, but do have a few friends use Telegram so I'm using it on my computer. We're looking at alternatives. We tried out Signal, and that feels extremely basic and spartan, like old ICQ or AIM. We tried Matrix (with the Element client) and it feels much more featureful and modern. And the federated aspect feels much better than the centralized nature of Signal.

Can you explain a bit more about where you feel the complication comes from?

This group of friends are mostly not very technical. They were able to create an account on matrix.org perfectly fine. They felt a bit strange that they had to pick a username "like in the past" and not use their phone number. But at the same time they felt pretty nice not giving away their phone number to a foreign company/organization.

I would say that depends on how strong the friendships are, and how strong your morals/beliefs are.

That's a problem with every computer update right? Not limited to Linux.

I am not very proficient with LLMs yet, but this sounds awesome! How do you do that, to "feed it this essay"? Do you just start the prompt with something like "Act like the Grug Brained Developer from this essay <url>"?

I don't really think so. The tracker is just a tiny part of the whole Bittorrent setup, and it's only really used by clients to get a list of peers. It's basically just an HTTP call to the tracker, returning a response. The only thing that I can quickly think of is returning some malformed bencode which could cause a memory exhaustion a client written by a novice.

The peer protocol (and variants, like uTP) are much more interesting to attack, and you don't need to host a tracker for that, you can just get peer IPs from trackers or DHT, connect, and do your magic.

I am not the one who created the post, but currently it doesn't seem to be usable as a library because most of the code is in a directory called "internal", which isn't accessible when using the repository as a dependency in another project.

How hard it is depends a lot on your experience, how comfortable you are with the programming language, and if you have an experimentation mindset. To offer a perspective, I also decided to build a Bittorrent client in Go last week, and I'm about 80% of the way of the posted project in a week. But then again I have a lot of experience with Go, extensive knowledge about protocols and networking, and experimentation has become a kind of second nature for me.

If you're interested, the main Bittorrent spec is actually quite small, you can easily read and understand it in an hour or so: https://www.bittorrent.org/beps/bep_0003.html

There's a lot of stuff "around" Bittorrent, like protocol extensions. But in my experience so far, many clients have different levels of support. E.g. they would try communicating using Protocol Encryption (obfuscation, actually) and if it doesn't work fall back to the regular protocol (if configured in the settings).

If you just want to download a Linux distribution (e.g. Debian) using the .torrent file on their website, it's relatively straight forward. It has just one file, there's a tracker, plenty of peers using the regular protocol, and you could get away not listening for connections when you're behind a NAT.

Naturally when you get into the grey area of content, then you'd need to parse magnet links, use DHT to discover peers, and perhaps you'd want to implement UPnP to try and automatically map a port on your modem. But that is also an iterative process, you can just build out one by one. The more features, the more peers you'll be able to discover and have successful exchanges with.

I would like to echo performance (and other issues) with Fyne. Every time I try it again, I'm actually kind of baffled that it's so popular.

Last week I came across these Qt bindings: https://github.com/mappu/miqt

I have no personal experience with it yet, but am excited to try it out.

Interestingly (or maybe not) I started writing a Bittorrent client last week, also in Go. I don't really like AI/LLMs for coding, and my goal is to really learn from it. Not to just deliver some piece of code that an AI wrote...

So the first step is to figure out if there is an actual spec for the protocol. Well, in the case of Bittorrent there is a spec, but it's kinda... brief. Basically, this is the spec: https://www.bittorrent.org/beps/bep_0003.html

There are some additional extensions here: https://www.bittorrent.org/beps/bep_0000.html

It's very important to break the work up in tiny steps that each give some kind of a result. E.g. I started with parsing .torrent files, for which you have to implement bencoding.

That was interesting, because I downloaded the Arch Linux .torrent and found out it was basically incorrect: it has a url-list key which isn't mentioned in the spec. Then you have to go down a rabbit hole of some research trying to find out what the heck is up with that (turned out to be https://www.bittorrent.org/beps/bep_0019.html). Finally, was able to successfully parse the Debian Linux .torrent file.

Then came implementing the tracker Announce HTTP request and the peer protocol. The peer protocol was tricky, and that's when an experimentation mindset comes in handy. I stripped the announce URL from the Debian torrent and loaded it up in KTorrent, that way it wasn't able to find any peers. I used the "Add peer" option to add my client so I could see what messages it was sending me, and alongside I would implement sending those to KTorrent messages too. A lot of trial and error and debugging.

I have to confess that from time to time I had to ask ChatGPT about some small protocol details because they just didn't show up in the spec. There's also a lot of details that clients have implemented over time but which aren't really documented well. Mostly algorithms for which pieces to download, which peers to choose, how to "choke"/"unchoke", etc, is not well-defined. But web searches help out a lot.

Also an honorable mention to https://wiki.theory.org/Main_Page which has some nice information.

I'm now at a point where I can fully download and upload a torrent with my local KTorrent, so the next steps are to actually get peers from the tracker, and some algorithm to download pieces and store them in a file.

Hope this gives some insights. Let me know if you have specific questions about the process.

> and without sacrifices

There are always trade-offs/sacrifices.

The Go team isn't making new versions just for fun. Each version since 1.21 has had improvements. Especially the fix/change to for loop variables in 1.22 is very nice to have, and helps preventing to write bugs.

If there's a reasonable expectation that users will use outdated platforms, it makes sense to support them. If there is no such expectation at all, why would one forego the improvements to the language and tooling.

There's always a price to pay.

> We desperately need an open source engine that can compete with Unity and Unreal

I think this is a pipe dream. There's a lot of money behind Unity and Unreal, that buys a lot of developers.

Actually I think it's amazing how far Godot has come, and what kind of amazing and big updates they regularly do given how little money they get, and being open source.

It's seeing a lot of active development, so it's definitely not in its final form yet. It can still grow to be serious about filling that role...

> As it is it’s clear Godot’s team is more interested in reinventing wheels for fun than in making a real contender.

This is just a bad faith attack on the Godot's team, and not very much appreciated I'm sure.

See this from another comment in the thread https://imgur.com/a/6ZTCStC