Hacker Newsnew | past | comments | ask | show | jobs | submit | jdjb's commentslogin

The HashSet would be the owner of the IP address type. Your function would call the "take" method of the HashSet to take ownership of the IP address. Now the IP address cannot go back into the HashSet unless you give ownership back and no other thread/caller can take ownership.


If you're using React.useCallback to avoid triggering further hooks down the line, then you're using it wrong. Since React.useCallback is ostensibly just React.useMemo wrapped around a function, this note in the documentation is just as applicable:

  You may rely on useMemo as a performance optimization, not as a semantic guarantee. In the future, React may choose to “forget” some previously memoized values and recalculate them on next render, e.g. to free memory for offscreen components. Write your code so that it still works without useMemo — and then add it to optimize performance.


You're only using it wrong if you're trying to avoid triggering hooks as something other than a performance optimization.

For example, something like this should work correctly even without useCallback, but you would be constantly re-subscribing for no good reason.

    const callback = useCallback(...);

    useEffect(() => {
        const unsubscribe = subscribe(callback);
        return () => unsubscribe();
    }, [callback]);


I was following a pattern similar to react-table, where I'm destructuring a function off of a previous hook and passing it to another hook as a callback. This allows the 2nd hook to update state in the first, which causes it to infinite loop if the function isn't wrapped. I think this pattern is more complicated than it sounds, but really helps to remove business logic from a component


If we have a component <ProfilePage id={id} onLoad={handleOnLoad} /> and inside profile page we use an effect to load from id and call handleOnLoad with the loaded profile data, then we need to put handleOnLoad in the useEffect dependencies. So we have to pass a callback wrapped in useCallback else the effect would fire every time ProfilePage rerenders.


I have a few reason why I almost exclusively shop online at Amazon. I try to trust as few companies as possible with my credit card details. Amazon having nearly anything I need makes this easier and convenient.

I prefer the convenience of a brick and mortar store (the convenience being able to browse the products in real life and take it home with me immediately) but it's not always possible to find what I'm looking for locally.

Lastly, for every person complaining here on Hacker News about their one anecdotal issue with Amazon there's thousands of products being shipped every minute that have no issue. Amazon mostly works, though I wouldn't trust it for very large fragile things.


There's nothing wrong with hoping a freely licensed open source competitor will come along and lower the cost of developing in the space.

PyQT are free to extract fees from the ecosystem as long as they can, just as some open source devs are free to try to eat their lunch money.


For me it's not that Google is more trustworthy, but that their influence and abuse of monopoly position doesn't affect me as much. As a developer I'm well aware of my options for search and operating systems.

I can choose not to use an Android phone. I can choose not to use Google search, block Google domains in my hosts file, etc. While the alternatives are probably not as pleasing or convenient, I can definitely get by without Google.

I can also get by without Microsoft. I've used Linux almost exclusively for 15 years now. But choosing to stick on Linux has been made harder with Microsoft's monopoly. It's easier now but I can remember when it was very difficult to find good hardware to run Linux and not have to pay a premium or pay for a Windows license even if you never wanted Windows (and definitely didn't want to pay out of principle).

As far as I know, Google's dominance on search doesn't affect my experience when I use other services. I haven't seen a "Halloween documents" event out of Google's camp.


They should also add a toggle that prevents the client from retransmission to unknown keys without human approval.


Then don't use a messenger that promises end-to-end encryption. Client side encryption is all about ensuring only clients that hold private keys can read messages delivered to them.


More like, you can stop using this messenger because, guess what? It does what I want and not what you want. You move.


Thibault simply wants to deliver the best online chess experience. Period.

It's purely donation driven and he pulls a small salary from whatever's leftover after buying enough servers to keep the site up.



I'm supprised that they get $47 mn in donations. Rarely see the patron icon when I play.


$47k, not million. Amounts in that spreadsheet aren't in thousands.


Apologies, thanks for clarifying


mn?


Yeah, that survey was incredibly lackluster. Also felt some of the questions were pretty leading.

Questions like implying online voting would lead to higher electoral costs or that a more mixed representation in the house would immediately slow down government. While some of those effects may occur, it seems disingenuous to pick out one random negative effect to single out in a questionnaire like that.


I wonder how much of this is due to the idea: 1) non-technical users need to be able to use our software. How much code today is about preventing users from doing something they should know better? 2) we're less and less able to say "no, that goes way beyond the project's scope" to our bosses. Our bosses will quickly reply "yeah well Google's ______ does it, so why can't we?".


this is due to the idea that modern sw developers do not care what they do, but care a lot about how they do things. They pay no attention to the business problem at hand (in my experience they get very upset when I try to draw their attention to the business requirements) but spend all their time discussing what *-pad framework is the best candidate.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: