mightyham

I've recently been reading the Pensees, so it feels timely that this article was posted. I'll add here a couple more practical pieces of advice that Pascal offers for dealing with what he considers the wretchedness of human experience:

"One must know oneself [reference to Socrates]. If this does not serve to discover truth, it at least serves to regulate one's life, and there is nothing better"

"Physical science will not console me for the ignorance of morality in the time of affliction. But the science of ethics will always console me for the ignorance of the physical sciences."

Wow, I never imagined you would respond to my comment, a little embarrassed ngl :D

I understand that under the hood Solid's reactive system is not quite simple; though, the mental model needed to use it, is very simple, which I greatly appreciate when building complex application logic on top of it. That's really my main concern: that one-way "push" semantics are easy to follow and think about, and adding new mechanics complicates that picture. It seems deceptive that what presents itself, at least conceptually, as just a value access, might now cause arbitrary code execution (another way of putting this is that it feels like it violates the principle of least astonishment).

As I mentioned before, I also haven't run into situations in practice where lazy memos seem like a desirable behavior. If I initialize a derived value, it's because I plan to use it. If some computation needs to be "delayed", I place it inside an if statement with a reactive condition, for instance, createMemo(() => shouldCompute() ? computeValue() : undefined).

All that's said, you've done a fantastic job with Solid. I hope you continue to innovate and prove my objections misguided.

I've found the ecosystem to be perfectly serviceable for every complex piece of functionality I needed to bring in: remote state, forms, tables, and routing, come to mind. Complex state management can easily be handled using the library's standard reactive primitives and the community "solid primitives" project has a ton of well made utilities so you don't have to reinvent the wheel for common use cases.

I'm not going to sugar coat it though, SolidJS is not necessarily a batteries included ecosystem. There is a severe lack of components/component libraries. Luckily integrating vanilla (or "headless") JS libs is dead simple once you have enough experience.

Having used Solid on a largish web product for over a year, I am thoroughly convinced and will not be returning to React in the future.

This is somewhat of an aside: I am aware that the creator of Solid has long been experimenting with adding laziness to the reactive system. I think it would be a mistake. That everything is immediate keeps state changes intuitive, fairly easy to debug, and is one of the strong points of Solid's design. I've never run into a real world scenario where delaying computations seemed like an optimal way of solving a given problem.

> it has raised the issue of how journalists verify the credentials of sources in the AI age

Performing background checks is not difficult. Professional background check services are fast and commonly used in hiring processes. It seems like this article is (deliberately?) missing the actual questions raised by this case: why are these various outlets/journalists so lacking in rigor when it comes to the accuracy of their content, and how is a fraudulent expert consistently being chosen for their articles.

There are simply too many economic incentives encouraging doctors to not act in a patient's best interest that, as the parent comment points out, it would be irresponsible to not be skeptical of their advice.

It is strategically beneficial, for trade agreements, diplomatic leverage and in international conflicts, for a nation to have a strong industrial base, in other words an economy that creates and exports actual physical goods. Tariffs level the playing field in our own consumer economy for American made goods, because without them American manufacturing is competing with countries where labor is absurdly cheap.

Was going to comment the same thing. I try to avoid politics with co-workers and family because they are people that you are obligated, on some level, to interact with and have decent social cohesion. Friendships are entirely voluntary, so I can't begin to understand choosing to spend time with people that you can't honestly share your thoughts and feelings with, political or otherwise.

> I claim it is easier to make this mistake in a GC language because it's not "in your face" that you're carrying around all these object relationships that you didn't need. In a toy system (e.g. your unit tests) it will work as expected.

I simply don't see how these mistakes would be any less obvious than in an equally complex C codebase, for instance.

You make some really good criticisms of OOP language design. I take issue with the part about garbage collecting, as I don't think your points apply well to tracing garbage collectors. In practice, the only way to have "memory leaks" is to keep strong references to objects that aren't being used, which is a form of logic bug that can happen in just about any language. Also good API design can largely alleviate handling of external resources with clear lifetimes (files, db connections, etc), and almost any decent OOP languages will have a concept of finalizers to ensure that the resources aren't leaked.

Implementing a settable derived primitive like that is already possible in SolidJS userspace. You can roll your own or simply use https://primitives.solidjs.community/package/memo#createwrit....

You certainly don't have to be a Christian apologist to acknowledge the unique contributions Christianity has made to the development of the west.

It is an obvious fallacy to conflate the usage of tear gas canisters with the usage of mustard gas in WWI. They differ drastically in amount/concentration, area of effect, and long term health risks, thus should be treated differently in considering their usage.

Tear gas clearly sits on a spectrum of non-lethal arms with various other options that are more or less harmful. While it's entirely fair to criticize its use on a case by case basis, insofar as disorderly public gatherings can have varying levels of violence/destruction, it would stand to reason that some instances warrant the use of tear gas.

There are so many solid web bundlers that all offer a similar feature set, I am pretty skeptical that another entry is all that beneficial. It's good to have choices, but it's become difficult to keep up with such a fragmented ecosystem. I also admit that I am biased. I started using vite a couple years ago and since then have never run into any serious issues with my frontend builds/developer experience. If the main benefit of another tool is marginal performance gains, I am thoroughly uninterested.

Everyone has their own tastes, but I personally don't understand the appeal of SNL. Even skits that are so called "classics" don't strike me as all that funny. Maybe it's a generational thing.

Rationalism, which you seem to be an ardent supporter of, is a strain of philosophy. We all have some epistemological system we live by, so discrediting philosophy on its whole is not an option.

So by your standard, the works of Nietzsche are worthless because he was a strident anti-rationalist, and his works of literature contain many (mostly purposeful) contradictions?

The problem is that sacred texts like the Bible (other examples might be the Pali Cannon in Buddhism or Vedas and Upanishads in Hinduism) do not contain "flat contradictions". If people hundreds of years apart write down conflicting ideas that later get complied together by another person/group who are using those texts for non-logical spiritual guidance, in what way is that a meaningful contradiction? Also, the idea that wisdom must be strictly rational is a modern, scientific standard that these texts fundamentally disagree with.

The Bible is a small library of different books written by different people at different times. I don't think it's all that surprising that there are contradictions. In fact, I would say that pretty much every faith tradition with a long literary history suffers from this problem. I don't think that undermines that idea we can glean meaningful wisdom from sacred texts.

Your complaint doesn't make sense to me because `use` is essentially the same thing as `await` in JS. It hoists the rest of the function body into a callback so that the logic can be flat. In fact, `use` is an improvement on `await` because it is more generic and avoids the issue of function coloring. Promises also don't make as much sense in BEAM languages where callback based asynchronous code is not all that common or encouraged.

We are at an impasse then because I have no desire to write you an analysis of money interests in American politics.

It certainly seems to me that you, along with the author, are just trying to rationalize a biased viewpoint on the issue. If you don't have any specific criticisms about the various firms and billionaires that influence the Democratic party (you clearly have criticisms for the Republicans), that's a pretty good heuristic that you aught to be more scrupulous in your research.

> implied that the guy who wrote the article was being hypocritical

So it seems like you did get the point of my comment, and purposely didn't address it the first time you responded. I'll say the same thing again in different terms: the author's ethos when it comes to criticizing corrupt political administrations is significantly harmed by the fact that he has worked for corrupt political administrations with seemingly no issue.

Both sides are bad, that much is obvious. If that's all you gleaned from my comment, you completely missed the point being made.

I'm also not going to argue with you about which party is more controlled or hurting the country more. That is a terribly uninteresting online discussion to have.

> This is a wholesale attack on the American safety net, led by billionaires and far-right politicians who are frighteningly comfortable with fascism and autocracy. The last month has been called a coup by politicians, researchers, and watchdogs alike.

I find it amusing that many left-wing people are only now getting up in arms about the extent to which our government has been infiltrated by money interests. I understand not wanting to work for Trump's government, but why not just leave it at that? If this person was willing to work for the Biden administration regardless of it's billionaire influences, it betrays that this issue, for them, is a rationalization and not a reason.

To be clear, in this comment, I am referring to async in the broadest sense. I am specifically NOT referring to the Rust compiler keyword and runtimes (like tokio) that work with rust future state machines.

If I understand OP correctly his current proposal is to create a different runtime for rust. That runtime happens to be written in scheme using his own compiler. It is meant to make writing async rust applications easier by having simple rust interop.

Given the authors implicit argument that an async runtime with a stack-based context switching model can provide better debugging. Is it possible to write something like that in rust? That may be better for some use cases, as it wouldn't result in a multi-language project.

This seems like a great idea and I support the effort. It was not clear to me on first read though that what was being proposed is not an extension to current async rust (compiling code to a series of state machines), but a completely alternative design utilizing a context switching runtime like Erlang or Go. If I interpreted that wrong please correct me.

Part of me wonders, considering that rust is a systems programming language, how difficult would it be to write a runtime like that in rust so that there is no need to use a second language?

What is your actual point? You are criticizing Meta for building complex systems by iterating on boring tech like PHP and MySQL, and instead suggesting that they build their systems on top of different boring tech like YAML and Ansible. Why? The fact is that there are no "boring" off-the-shelf solutions for solving the problems that Meta is facing like whole region failures and performant cross-datacenter routing/sharding.

Your comment feels like it's not actually engaging with the contents of this article. It's not that Meta is creating bespoke technologies only out of fear of breaking past code. Their entire methodology of innovation is highly iterative and grounded in feedback through practical demonstration of results. You say that "Facebook creates tech to mitigate the pathologies their past continuously present", as if that is a bad approach, but considering Meta's success, I think it would be wise to seriously reconsider that position.

Not disagreeing with you, but just want to point out that billionaires and political lobbying groups have used funding (or the threat of funding) primary opponents to coerce congress for a long time.

I'm not a fan of checked exceptions because they force you to use a verbose control structure (try-catch) that distracts from the actual logic being expressed. Typically, checked exceptions are also not exceptional, so I prefer working with monadic exceptions, like Rust's Option/Result, because they encourage error recovery code to use normal control flow, keeping it consistent with the rest of the application.

I also find that generally exceptions can't be meaningfully caught until much higher in the call-stack. In which case, a lot of intermediary methods need to be annotated with a checked exception even though it's not something that matters to that particular method. For this reason, I've really come around on the Erlang way of doing things: throwing runtime exceptions in truly exceptional situations and designing top level code so that processes can simply fail then restart if necessary.

Media matters is just as biased as Andy Ngo. They are the definition of a hit piece mill, and will find any reason possible to criticize popular figures with right wing beliefs.