What the author touches on with before and after "declarative thinking" is largely applicable to all Directed Acyclic Graph (DAG) workflows, and not just signals. They are 100% correct that there is a mental shift. Yes, you can use magic to implicitly declare your DAGs with signals. You can also be really explicit with dependencies.
DAG-based workflows incur a cost in terms of complexity, but there are a few advantages to using DAGs instead of sequential.
1. Parallelism becomes inherently built-in
2. It's easier for a new developer to understand the direct dependencies of a node on other nodes (compared to sequential). Sometime in the future, a developer may want to split off a task or move it up/downstream of other tasks.
3. Fault tolerance & recovery becomes easier. Just because 1 step fails, doesn't mean that the whole workflow must come to a halt.
The Signals libraries I know of (including reaktiv) are throwing an exception if a dependency cycle is detected in the computation step. But that doesn‘t solve infinite executation loops completely because the user still can define an Effect that updates its (in)direct dependencies - that means User caution is still needed. Angular tried to prevent that in their older versions by not allowing to set other Signals in Effects. But they reverted that decision.
I have aphantasia, and today I learned that I also have SDAM.
There are benefits. For example, I find that I have no issue forgiving people. It's more work for me to harbor a grudge. I don't relive the burden of that initial pain of betrayal when someone close to me harms me, so it's easy to forgive and literally forget.
I also have aphantasia and I do believe I have SDAM, too. I also had a traumatic childhood and am a combat veteran. I think I've always been this way but that's a hard question for me to truly answer and is one that I grapple with a lot, actually.
> How about the pain of reliving old memories? I could do with a little less of that right now.
I don't relive the past the way it seems most people do. I know what it's like to feel hurt or feel stuck but I don't generally feel emotions about things in my past. That's good because I've endured a lot of bad shit but also sucks because my wedding day is kind of like any other day to me, as was the birth of our kids. I guess I know all of the good and all of the bad things that have happened to me -- though I don't really carry them with me the way some people seem to, they're part of me but I don't spend much if any time ever thinking about them -- but I don't feel any particular way about any of it. I know that I love my wife and kids more than life itself, I know these facts and I know the timelines but there's not much else there. I know these things but there's no emotional weight to them.
Me too. I’ve had some very traumatic experiences the last few years, and the emotional scars will never heal. I’m not the same person I was before, and I never will be.
Some people these days are hoping to combat aging and make potentially infinite life extension possible. I find that idea far more terrifying than death. Infinite lifetime would mean that experiences more emotionally and physically painful than I can even imagine would happen countless times. Slowly I would become so messed up by all the accumulated traumatic memories that I would no longer be able to function at all. I would only consent to an infinite or radically extended lifetime if I could also selectively erase memories I don’t want to keep.
I have many times thought about how scars and tattoos have a lot of similarities. From a certain perspective, a tattoo is simply a bit more intentional. A tattoo is like saying, "I belong to this group and it shows". I think of an emotional scar as a tattoo that is 100x bigger than a regular tattoo: it's so big, that you can't see it, it's like not being able to see an image when you zoom in too much. And, even though you might not see it with the naked eye, you can feel it, it's something on you that says "I was there", "I experienced that", "I used that to become the person I am".
And, then you might recognize that all of our personalities are constructed out of these scars, it's just that most of them we're not aware of and most of them aren't painful to think about. A time comes, when you notice that your association with a given negative memory becomes more neutral, there's a bit more distance between you and it.
I can say for myself that every experience I labeled as negative, I was haunted by, turned out to have a positive outcome at the end. There are hardships that "haunt" me now, and I don't know how it will have been a positive influence on me, but I believe that it will, and that helps.
I hope I don't come across as pushy with my viewpoints. I resonated deeply with what you said, and felt the need to share.
By the way, a practical tip, I find that if I prompt an LLM with something like:
> I'm going through [a difficult time]. Help me reflect. Ask a question or give me a prompt, I'll respond, and so on. Act like a friend.
That has been for me surprisingly effective for releasing debilitating emotional stress.
Sounds like functional forgiveness, as apposed to decision or emotional arc forgiveness. "Letting go" being a very strong default, that would require special maintenance to avoid doing.
I am this way in the long run. Regardless of the situation, at some point I just realize I completely don't care.
Once I know someone operates in a problematic way, I spend some time figuring out how they tick. People really do operate differently internally, and understanding the variety of cognitive damage that nature and nurture can inflict goes a long way to being able to be objective about people's shortcomings.
Then I use common sense to avoid any recurring problems, without negative feelings. I may not want to be connected with someone anymore, but if I run into them, or we are thrown together for some practical purpose, I can be amiable, without any conflicted feelings.
I think it's more about not remembering the feel of being hurt by someone - like he knows that this person did something bad to him but he doesnt't remember emotions connected to that event, that's why it's harder to hold a grudge.
What is it about React that you hate? React has been the near defacto framework for frontend development for a decade now [1]. Like it or not, it's not going away anytime soon.
As a Svelte / vanilla TS dev, I hate React because looking at it makes me feel like I’m drowning in obtuse, leaky abstractions, none of which feel necessary and all of which are required to do _anything_ at all.
Another react hater here. Here are some of my beefs.
* Components don't have exposed identities, but component state is based on identity. Secretly they're fibers.
* Everything is treated as if it's immutable. Reference equality is used to infer no changes. Working with array-based state, or almost anything really, is awkward and unnecessarily verbose. Spread all the things.
* The rules of hooks. These are just implementation constraints based on the rest of the design decisions of react.
* You can't use symbols as keys. This is small, but particularly irksome for me.
* The smallest unit of UI change is the component render function.
* Effect dependencies need to be listed explicitly.
> Everything is treated as if it's immutable [...]
Immutability is a great callout; frontend ecosystem is quite divisive on it.
For my flavor, as React exploded, redux and the advanced state management frameworks came and made everything bananas[1]. "It solves real problems for advanced apps"; maybe but I could never shake that these problems are self-inflicted.
There's a mathematical functional purity that's nerd-snipe worthy; but reactivity with mutation observers just seems to model the real world of UIs better.
Anyway, https://mobx.js.org/README.html is the exact opposite take: mutate your state! Subscribe to changes to your heart's content.
The divisiveness is real, it's what makes staying up to date exhausting.
[1] Come on, no one seriously thinks "bind action creators" made intuitive, ergonomic sense.
Mobx is cool. Nice to see some other mutation enjoyers. I also made my own thing[1] called "mutraction" (portmanteau of "mutate" and "tracking") based on this premise that uses jsx and mutation. I mostly made it prove that it could be made and to understand how it would work.
The Australian and the USA's immigration system are substantially different in terms of underlying values. The Australian system assigns points based on skill and merit. The US has an emphasis on reuniting families, a lottery system, and difficulty through ambiguity. Anecdotally, my friend who immigrated from Silicon Valley to Australia was able to explain his process to me in about an hour. In contrast, I have had the USA system explained to me many times, and it still hasn't clicked. I can't help but to feel like this is by design.
As for our (USA's) housing crisis, the New York Times had a podcast about that just four days ago [1]. There are some notable parallels to what you have described. TL;DR: The 2008 recession pushed us from building 2.2 million houses a year to 600K, for the last 20ish years. The skilled laborers and tradesmen who used to build houses have closed shop. Now here we are years later and millions of houses short with no clear way to reboot the industry.
There's substantially more immigration to Australia through university scams (fronts that don't actually educate) than genuine immigrants. The majority is not skill and merit based because of the "temporary" "students" who can work and never leave the country, as well as the chain migration loopholes.
Australia has almost the highest immigration per capita in the world, and a massive chunk of that is pure fraud. [1]
75% of "students" come in via unregulated agents, many of whom direct students to these university fronts.
In fact, Australians overwhelmingly reject mass immigration. 71% oppose it and are regularly ignored by the powers that be on both sides. The left imports immigrants for ideological reasons and the right imports them for cheap labor for their corporate buddies.
While Australia might have a lot of fraudulent immigration, they harass the normal tourists under the pretense of preventing fraudulent immigration.
This happened some years ago, so perhaps the system has been improved meanwhile, but I strongly doubt it.
At that time, I was living in an European country, but I was working for a subsidiary of an Australian company. There was a reciprocal agreement with Australia that visas must not be required for visiting the other country.
In Europe, the agreement was observed, so any of our Australian colleagues could visit the local subsidiary at any time, no questions asked.
However, there was a moment when the Australian headquarters decided that a team from the European subsidiary must come in a visit to them, for an important meeting where some future strategies had to be decided.
We expected that the travel to Australia would be as easy as the reverse travel for the Australians, but no, while Australia could not demand a visa, which would have been illegal, they had replaced the visa requirement with a requirement for some kind of "electronic" permit, whose name I do not remember, which was nothing else but a visa with another name, because without it you would have been denied entry in Australia.
To obtain the Australian permit one had to provide a really ridiculous amount of personal information about yourself and about a lot of family relatives (not only spouse, parents and siblings, but even grandparents), certainly at least as much as when applying for some security clearance of the highest level. I have traveled through many countries, and even those that require visas do not request such an amount of information. You do not need to provide such information even when going to Israel, where they have reasons to be more careful.
The most annoying was that they were not satisfied with providing a bank account where you held an amount of money greater than would be required for all your travel and stay in Australia. They also required for that bank account a detailed lists with all the transactions done with that bank account for the past three months.
Initially we have provided the list of banking transactions with only the amounts of money that had been transferred, but that was not good enough, they wanted for each transaction the complete information, like the invoice that has been paid and for whom. I could understand if they had required only the source of the money that credited the account, to determine who was paying for the travel to Australia, but a complete list of transactions, including everything that you have bought, was an abusive request.
If we had known in advance the Australian system, we would have created three months earlier a bank account with the only purpose of storing money for the Australian visit, which would have had an empty list of transactions. As it was, because this was a business trip, the account with money for the trip was the company account. Disclosing all the transactions from the company account could potentially disclose some confidential information for competitors and it would also disclose to the employees going in that trip information considered confidential by the company, i.e. the salaries of all employees.
Due to the complications created by the need to provide all the information requested by the Australian authorities, the process for completing the applications for the permit was very long. Even after providing all the required information, on-line to some immigration offices located in Tasmania, the processing of the applications took a few months. Because it was delayed so much, eventually the Australian headquarters has cancelled the visit to Australia and they have organized a meeting in Europe, where they did not fear that the Australians are illegal immigrants.
Our case was certainly not a singular one, because at the same time there was in the news a case when there had been an important meeting of some international organization, which happened to be organized in that year in Australia, and the representatives of some countries could not reach the meeting because they had received Australian visas much too late, even if they had been requested early enough and there was no doubt that they had a valid reason to come to Australia.
I think the author has a point with one-way doors slowing down the adoption of distributed systems. The best way to build two way doors is to push for industry adoption of a particular API. In theory the backend of these APIs matter little to me, the developer, so long as they are fast and consistent. Some examples that come to mind is that Apache Beam is a "programming model" for Data pipelines, Akka is a "programming model" for stateful distributed systems, OpenTelemetry for logging/telemetry, and Kubernetes for orchestration. Oh, and local development is a strong preference.
> Being able to bring the whole application up locally should be an absolute non-negotiable.
This usually doesn't work that well for larger systems with services split between multiple teams. And it's not typically the RAM/CPU limitations that are the problem, but the amount of configuration that needs to be customized (and, in some cases, data).
Sooner or later, you just start testing with the other teams' production/staging environments rather than deal with local incompatibilities.
> Sooner or later, you just start testing with the other teams' production/staging environments rather than deal with local incompatibilities.
That's probably about the time when your development pace goes downhill.
I think it's an interesting idea to consider: If some team interfaces with something outside of its control, they need to have a mock of it. That policy increases the development effort by at least a factor of two (you always have to create the mock alongside the thing), but it's just a linear increase.
> That's probably about the time when your development pace goes downhill.
Oh, absolutely. But at this point, your team is probably around several dozen people and you have a product with paying customers. This naturally slows the development speed, however you organize the development process.
> I think it's an interesting idea to consider: If some team interfaces with something outside of its control, they need to have a mock of it. That policy increases the development effort by at least a factor of two (you always have to create the mock alongside the thing), but it's just a linear increase.
The problem is, you can't really recapture the actual behavior of a service in a mock.
To give you an example, DynamoDB in AWS has a local mock in-memory DB for testing and development. It has nearly the same functionality, but stores all the data in RAM. So the simulated global secondary indexes (something like table views in classic SQL databases) are updated instantly. But on the real database it's eventually consistent, and it can take a fraction of a second to update.
So when you try to use your service in production, it can start breaking under the load.
Perhaps, we need better mocks that also simulate the behavior of the real services for delays, retries, and so on.
This reminds me of an article I read somewhere (probably here in HN) wherein people implementing Banking Services just straight up test the API in Production after a few cycles of mock development, due to constantly having to deal with edge cases not present in the dev env.
In theory it should be the cloud providers themselves maintaining the locally-runnable stand-ins for their services, but as it stands you basically either get it as a third party effort (MinIO for S3) or in cases where the service is just a hosted version of some existing OSS product (Postgres for RDS).
Either way, once the local version exists, then the job becomes maintaining all the infrastructure that lets you bring up the pieces, populate them with reasonable state and wire them into whatever the bits are that are being actively hacked-on.
OTel being a capture & ingest only specification is kind of messed up. There's no attempt from what I can tell for how to query or present stored data; it's just an over-the-wire specification, & that drastically limits usable scope. It means vendors each get to make their own services & backends & tools, but it's greviously limiting the effort as a whole, makes even an open spec like OTel a one-way door.
Ideally OTel would be more than observability, imo. Traces would be event-sources, would be a thing that begets more computing. The system to observe computing should in turn also be the system to react & respond to computing, should be begetting more computing elsewhere. That's the distributed system I want to see; local agents reporting their actions, other agents seeing that & responding. OTel would fit the need well, if only we could expand ourselves beyond thinking of observability as an operator affordance & start thinking of it as the system to track computation.
Otel works as a standard since there isn't any need to innovate at that level. Despite the over complications it has, all the implementations largely have the same requirements, and it's useful to instrument everything the same way.
Querying unfortunately has lots of room for innovation, and it's really hard to nail down in a spec especially when the vendors all want to compete.
Otel is nice and all but I still think you are best off going 100% all in prometheus. Prometheus is so common that it has become a de-facto standard in metrics.
At BigCo we have migrated a number of internal things to Otel but I don’t think it has been worth the effort.
So many projects come with prometheus metrics, dashboards, and alerts out of the box that it becomes hard to use anything else. When I pick some random helm chart to install you can almost guarantee that is comes with prometheus integrations.
With grafana mimir you can now scale easily to a few billion metrics streams so a lot of the issues with the old model of prometheus have been fixed.
Like you said I don’t think there is much to innovate on in this area, which is a good thing.
You're describing the parallelized web-scraper that they pointed to their own internal site? Yeah that was fun. Too bad everyone got the same question.
Link warning, this site a rather quite aggressive fishing scam. The Google Ad displays that the link will resolve to "www.nytimes.com", however it instead redirects to a [spam fishing site](https://lpeedxcddfgffdsxxxzzs.z13.web.core.windows.net/index...).
Good question. The ad looks like an innocuous link to www.nytimes.com, but clicking on the link actually goes to https://www.googleadservices.com/pagead/aclk. (I didn't try actually clicking the link.)
