• 0 Posts
  • 13 Comments
Joined 2 years ago
cake
Cake day: May 31st, 2024

help-circle


  • True, and that’s exactly why I said parallelism.

    Concurrency without parallelism is just like Python/JS, a single thread drives all the coroutines, and it’s the easier one, as the runtime doesn’t really need to lock.

    GO on the other hand has parallelism. It maps goroutines to a thread pool, which requires locking, making things more complicated.

    This is also why Rust has two types of reference counting, Rc and Arc.


  • This AI slop is so baffling.

    GO uses a garbage collector because it has to: removing this GC fundamentally complicates parallelism. If it’s manual management, then who owns the data? Of course there are ways to work around, but none of them are free; in fact those can be even more expensive.

    Assuming it enforces single ownership, then the allocator is responsible for freeing resources. How can it know the resource can be freed, if the resource is processed in another thread? Inter-thread communication? The complexity will be insane. Pass ownership? There’s no move semantic in GO. Reference counting? No such a thing in GO either.

    I even have a feeling that those 1.1k stars are fake.










  • While some of the claims may be valid, this article is full of propaganda.

    How can Telegram distribute messages in channels with more than tens of thousands users with P2P encryption? If there’s 10k users, should Telegram store the same plain message 10k times simply because there’s 10k public keys? If the sender encrypts and signs the message with 10k public keys, can the sender handle such a resource-hungry task? How can newly joined users decrypt old messages?

    Of course there’s fishy things, but the unprofessionalism severely drags down the value of this article.