At this point these jobs posts just feel like ways for them to farm PII
359 karma · joined November 3, 2018
Fast forward a few months, and most of those apps are abandonware. Not that he's not as productive, he just skipped the middlemen (the apps), and started directly asking the agent to do those things.
> CLIs have purposes for which they’re irreplaceable. Building a CLI is almost always a good idea. Building a TUI almost never is.
You're also arguing for CLIs which are absolutely great. But TUIs provide none of the composability of CLIs nor the malleability of GUIs
Using a targeted eval suite (like a test suite) tells us that.
Seems a bit ironic considering that it's supposed to be a specification on how a website should be.
With similar sentiment as well "They make us dumb" "Machines doing the thinking for us"
Cars were definitely seen as a fad. More accurately a worse version of a horse [2]
If you looked through your other examples, you'd see the same for those as well.
Some things start as fads, but only time will tell if they gain a place in society. Truthfully it's too early to tell for AI, but the arguments you're making, calling it a fad already don't stand up to reason
[1]: https://www.newspapers.com/article/the-item/160697182/ [2]: https://www.saturdayeveningpost.com/2017/01/get-horse-americ...
One small feedback: It took me a while to figure out what it actually does. The homepage makes it look more like coolify or dokku.
By every performance metric, the new app was faster.
But we kept getting user feedback that the new site was "clunky" and "slow", even though we saw that the p90 was much lower on the new site. Most of our users asked us to enable a toggle to let them go back to the old "fast" site.
I'm not sure if this is a universal experience, but I think a lot of other sites that tried the CSR -> SSR move had similar experiences. It's just harder to talk about, since it goes against the usual narrative.
Also if you look at the repo, only 3% of the codebase is in Assembly. IMO if >95% project is in Rust, you can definitely claim it's a Rust project.
Even though, from personal experience, at scale it still falls apart
Also it's a little strange to ask for a passport photo, first time I've seen that.
Umm...no? V8 specifically compiles it into machine code directly.
There used to be a pseudo-translation layer in the CrankShaftScript days, but that hasn't been true in almost a decade.
> I can decompile the binary and still see the type information.
Also no. The de-compiler can _infer_ the types, much like how V8 tries to infer the type. But the actual type information is gone.
Even in languages like Java where most of the type information is preserved, some things are still lost (e.g. generic methods with dynamicinvoke)
Interesting that you say it's more about providing "bindings", and not really "using". Much of the types in the svelte codebase are never exported outside of svelte, and they are only consumed internally.
The problem they were having was with transpilation, since the browser doesn't run JS.
From Rich Harris (months after svelte switched to JSDoc) [1]:
> removing types from your own code is clownish, epically misguided behaviour, but whatever — to each their own
I would suggest going through the issues and PRs in the codebase to see how invested the Svelte team is in typescript.
> TypeScript is not "real" static typing in the same sense as Go, Rust, C#.
That is true for Go, Rust, C#. But the same thing is also true for languages like C, and Generics in Java. I'm sure both of those languages have weak type systems, but are definitely statically typed.
I think the fact that type information is lost after being compiled isn't really a classifier for typed/non-typed. Ultimately it all comes down to machine code, and that certainly isn't typed either.
But if you wanted web standards + web component, Lit already fills that space. If you want untyped JS or little/no JS at all, there's HTMX. Or if you're just tired of React, and want something faster + simpler, there's Svelte/Solid.
I'm not sure what problem Nue is uniquely solving.
> If you're rabidly anti-TypeScript and think that us doing this vindicates your position, I'm about to disappoint you.
Rich and the rest of the Svelte team are still using typscript, just through JSDoc + type definition files.
In contrast the Nue team seems to want to keep the view layer untyped.
From the parent comment
> real static typing (like Rust or Go) shines in business logic where it counts
it seems they don't consider typescript to be "real" static typing.
> set PATH $PATH ~/.npm-global/bin
Fish has some nice utilities for these type of set calls
set --append PATH ~/.npm-global/bin
That's a pretty interesting pricing strategy. I think REHL is the only other project I saw with this type of pricing.
Is there any way to see the top posts? It's really helpful when I'm trying to catch up on things. I know HN doesn't, but I can usually use hn.algolia.com to find the top posts.
It's supposed to be a bit easier for developers to pick up, but you should be able to achieve the same thing with Pulumi AFAIU
You can use d8 to check what the class structure ends up looking like [2]
---
For example,
1. field declarations [1] make sure that the fields are always initialized in the same order. That way most of your functions end up monomorphic, instead of being polymorphic [2]
2. Method declarations are also (almost) free, since you only pay for them once, during class initialization.
You also get a few other niceties such as private properties. You can emulate private properties with closures in factory functions but V8 has a hard time optimizing, unfortunately.
---
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...