Also, we shouldn't look at fiat currency as the only form of achievement, especially given the artificial economic environment of the past decade. Many smart people know that Slava co-founded RethinkDB and realize that it's one of the best databases in existence. That genuine brand value is way more valuable in the long run than worthless fiat paper or company stocks whose earnings are denominated in that same worthless fiat.

It's important for millennials to realize that the past 10 years of monetary policy which contributed to significant centralization of wealth and power is not normal and it won't last.

Comments URL: https://news.ycombinator.com/item?id=24857123

Points: 2

# Comments: 0

Some countries are about to get brain-drained. They will be left full of fiat money, full of psychopaths, no brains, no humanity.

I recommend also doing your own research to verify all the facts. I had a hard time believing some of the facts presented but all checked out so far.

Hidden Secrets of Money: https://youtu.be/iFDe5kUUyT0?t=69

An interesting recent discussion I found which discusses the current state of the economy: https://www.youtube.com/watch?v=kGsp45JbvnU

Actually the second one is eye-opening for anyone who wants to make sense of the current situation.

At this stage, I'd rather be the lucky recipient of charity donations than a participating member of the economy. It's just easier and more meritocratic.

Everything the elites do seems to destroy the economy and destroy justice.

I highly recommend watching Anand Giridharadas on YouTube - He explains this effect very clearly.

In terms of modularity and testability, the ideal architecture is when components communicate with each other in the simplest language (interface) possible. Otherwise you become too reliant on mocks during testing (which add brittleness and require more frequent test updates). I think very often, static typing can cause developers to become distracted from what is truly important; architecture and design philosophy. I think this is the core idea that Alan Kay (one of the inventors of OOP) has been trying to get across.

'I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging"' - Alan Kay

It's very clear from Alan Kay's writings that when he was talking about 'messaging' he was talking about communication between components and he did not intend for objects to be used in the place of messages.

The point of good state management is to ensure that each instance has a single home. As soon as you start passing instances between functions/modules/components, you're leaking abstractions between different components. Sometimes it is appropriate to do this, but most of the time it's dangerous. Components should aim to communicate as little information about their internal state to other components as possible.

When I judge things, I look at practical outcomes; and the fact is that I produce better software with more features within the same timeframe if I use JavaScript rather than TypeScript and the product in both cases is equally robust. This has been true for me both independently and as part of a team.

With JS, I can write more code and more tests within the same amount of time and there is no drop in quality.

I'm very surprised that nobody else seems to be experiencing the same thing. I've been back and forth many times between the two paradigms and for me it's clear as day.

If you have the option between creating a function which accepts a string (e.g. ID) as argument or accepts an instance of type SomeType, it's better to pass a string because simple types such as strings are pass-by-value so it protects your code from unpredictable mutations (which is probably the single biggest, hardest to identify and hardest to fix problem in software development). I think OOP gets a lot of blame for this and it's why a lot of people have been promoting functional programming but this blame is misguided; the problem is complex function interfaces which encourage pass-by-reference and then hide mutations which occur inside the blackbox, not mutations themselves. Mutations within a whitebox (e.g. a for-loop) are perfectly fine since they're easy to spot and happen in a single central place.

If you adopt a philosophy of passing the simplest types possible, then you will not run into these kinds of mutation problems which are the biggest source of pain for software developers. Also you will not run into argument type mismatch issues because you will be dealing with a very small range of possible types.

Note that this problem of trying to pass simple types requires an architectural solution and well thought-out state management within components; it cannot be solved through more advanced tooling. More advanced tooling (and types) just let you get away with making spaghetti code more manageable; but if what you have is spaghetti code then problems will rear their ugly heads again sooner or later.

For example, a lot of developers in the React community already kind of figured this out when they started cloning objects passed to and returned from any function call; returning copies of some plain objects instead of instances by-reference provided protection from such unexpected mutations. I'm sure that's why a lot of people in the React community are still kind of resistant to TypeScript; they've already figured out what the real culpit is. Some of them may have switched to TS out of peer pressure, but I'm sure many have had doubts and their intuition was right.

Nothing beats good testing and good architecture design.

Depends on how many subscriptions you want. If you have 100s of subscriptions, it can add up.

>> You can send a token as query parameter.

If using JWT or some other kind of stateless signed (or encrypted) token, that would take up a large part of the URL. Also URL length is limited to around 2000 characters in some browsers. So it encourages short session IDs instead of signed tokens (session IDs are not stateless; so it's going to force an additional database call to be made on the server-side).

>> The EventSource API allows you to close the connection at any time. It will automatically reconnect which I consider a feature.

Yes there is some control. But if it auto-reconnects too fast, then your servers could end up DDoSed if you had a lot of concurrent clients. If it auto-reconnects too slow, then your users could miss more messages than would be desirable depending on the use case.

With WebSockets, you can control the backoff to your needs and you can randomize, so you can ensure that not all clients try to reconnect at the exact same time; you can tailor it to your architecture.

>> However, we don't need this flexibility for GraphQL Subscriptions.

It seems like it simplifies things but also potentially reduces flexibility and performance. But I'm not familiar with the typical use case for GraphQL so maybe it's worth it.

Another major benefit of WebSockets is that you can control the exact timing of RPCs and subscriptions without having to worry about race conditions when the server expects to receive actions in a specific order.

Also, SSEs add a lot of overhead because you need to authenticate each SSE channel independently (unlike with WebSockets where you only need authenticate a socket once at the beginning and then use it to subscribe to almost unlimited channels); so if you have many SSE EventSources, establishing them will waste a lot of resources since you need to pass the auth token (or session ID) to each EventSource that you open - In general, SSE authentication is tricky and forces you to rely on cookies which can be a problem in a lot of situations (e.g. on mobile if the front end is loaded the local file system as part of a WebView, your cookies will not be sent to the server due to cross-origin restrictions).

Moreover, the lack of control over the lifecycle of the SSE connection makes it difficult to coordinate recovery from network or server failure/restart; a common problem happens when your server crashes and then all the SSE event sources try to reconnect immediately at the same time and this DDoSes your server again, then the reboot and crash cycle repeats indefinitely... With WebSockets, you can control the reconnect algorithm to add exponential backoff, for example (it can be customized to your exact requirements).

Finally, the statefulness of WebSocket connections can be a huge advantage; you can store data pertaining to a single active client in-memory on the server-side which can be convenient for a lot of use cases (and efficient). For example, you can attach an auth token on the back end socket (in memory) and can use it to quickly check access rights for any channel without having to make an additional database call.

SSEs are not a practical abstraction IMO. It's sad that people don't realize how good the WebSocket standard is. It's good because it's simple; it's also what makes it so flexible. WebSockets cover more use cases.

Subscriptions as a concept have to support too many use cases (too generic) to be implemented with something as restrictive as SSEs.

I have no doubt that countries in the periphery of major communist states had it worse... Just like countries in the periphery of capitalist states have it worse today.

If you ask members of the communist elite how communism was, they would probably tell you it was amazing. If you ask the lowest class of capitalists, they will tell you that capitalism is horrible - These days even many members of the middle class will tell you that capitalism is horrible; unfortunately the US capitalist system can't drain China so much anymore (now that China has become an economic superpower) so now it has to drain its own citizens locally.

Why do you think democrats are so keen on increasing immigration? You think they actually want more Elon Musks and Sudar Pichais to compete with them? They want more wage slaves to drain from! Elon and Sundar are immigrant bait!

Americans are going to find out for the first time what capitalism is really about.

Also because capitalism has a much broader global reach, it can hide poverty away in other countries.