Hacker News new | past | comments | ask | show | jobs | submit | thoradam's comments login

It is true that I don’t this publication. I also don’t know the author or what The Manhattan Institute is. In general unless a piece of text is asking me to take something on faith or I am unable to reason with it I don’t care in the slightest who wrote it, where it was published or what their affiliations are.


> In general unless a piece of text is asking me to take something on faith

The longer I live the more I realize I don't know. For me it means I have to have some trust in the people communicating with me - that they're operating in good faith. More so when their comms are persuasive arguments.

Without my trust + their forthrightness, I have to expend significant time and energy parsing and vetting their statements - for little practical benefit.


I haven't tried Remix but I can relate to Next.js being too much magic. I've had errors in `getServerSideProps` that happen on the server and then again in the client, causing a client side error instead of simply rendering the 500 page. I've accidentally bundled server code in the client because there's no clear separation. The automagical client side navigation with <Link> has caused scroll position to be forgotten when navigating back.

I recently tried Deno Fresh and it has made many different choices that I resonate with:

- "When you create a route, all of the components used are rendered on the server. No javascript is sent to the client, unless you specifically include something from the /islands/ folder."

- "For stronger resiliency and user experience, Fresh relies on native browser support for form submissions with the HTML <form> element."

For example a route that renders a form and accepts a `POST` with that form is trivial, which amazingly can not be said for many server side React frameworks.


Deno Fresh pushing "islands" is a huge negative... but that's to be expected when Vercel's VC enforcers are behind it.

99% of the React ecosystem does not function without reactivity enabled: it's literally in the name.

As a result most applications written in React depend heavily on interactivity. The only category that is an exception is ecommerce where you're normally pulling from a CMS... and Vercel needed to fight Shopify for that space so they went and "helped" the React team turn the framework into something it's not with RSC.

_

Also most of your complaints aren't at all addressed by Deno? It uses an amount of magic closer to current Next.js than pages-era. It actually removes some conventions for separation that Next.js has (all routes potentially being api routes for example). And as far as I can tell both libraries expect you to explicitly handle errors during data fetching (and your users would probably appreciate that too)

_

One of these days I might get annoyed enough to fork Next.js 1.0, sprinkle in a folder router for express and call it a day on a framework that doesn't fight React and just stays out of my way.


Tin foil — third parties can be passkey providers: https://blog.1password.com/apple-passkey-api-wwdc/


> This whole thing would have been much better if they’d positioned it as a work and personal entertainment machine

Honestly most of the presentation had this exact vibe for me. That the Vision Pro is directly positioned as a device for deep immersion, like movies, gaming, and engrossing work. The two exceptions I remember were those moments where a person plopped their Vision Pro on to take a 3D moment of their children and the one where a person answered a FaceTime call with the Vision Pro while packing their suitcase. I don't see those moments happening in reality with this sort of device.


If you're talking about coverage in the usual sense (% of lines that were executed), it's pretty much useless. Here's an example of 100% test coverage in that sense:

  add a b = 2
  test_add = assert_equals (add 1 1) 2
A more useful definition of coverage would be the entire possible state of the program, but this is tantamount to a proof, which is a really hard problem for programs in general. Property based testing, e.g. QuickCheck[1], gets us close, but it is often hard to come up with the right properties.

[1]: https://hackage.haskell.org/package/QuickCheck



> It does more than that. It understands how to do basic math.

It doesn't though. Here's GPT-4 completely failing: https://gcdnb.pbrd.co/images/uxH1EtVhG2rd.png?o=1. It's riddled with errors, every single step.


It already fails to answer rather simple (but long) multiplication like 975 * 538, even if you tell it do it in a step-by-step manner.


This is a recommendation for another Apple Arcade game. The only gain for Apple if you click this notification is if you get the game, like it, and continue to pay for Arcade. This is like taking a screenshot of Netflix's "Top Picks for You" list and saying they are ads. This notification is not from the game you're playing but directly from Apple. There's no way to ship a game for Apple Arcade if it includes ads, interstitials or in-app purchases, that's the whole point.


> the decision not to include various MLs, OCaml, Scala, or F# in the chart of functional languages seems controversial

I don't know why that would be controversial. There's a very clear distinction between (MLs, OCaml, Scala, F#) and (Haskell, Elm, PureScript, etc.).


Sure, they are in different language families. But a chart showing the "top dozen functional-programming languages" should include all languages that were given a separate workshop at the International Conference on Functional Programming (https://icfp22.sigplan.org/): Haskell, ML, OCaml, Scheme, Erlang, miniKanren (the last two are arguably specialised enough that they could be excluded to put more focus on general-purpose languages).


> Without this expansionist step from our side the situation would have never escalated.

Where do you put the annexation of Crimea in this timeline?


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

Search: