It's fully functional now, but 2x slower than the original tsc and 10x slower than tsgo. But hopefully in a month or so, we'll get to C# and Rust targets and it should be able to compile itself to become nearly as fast as tsgo.
They're everywhere. But if you're short on time, buying the postcard is often easier than getting stamps and dropping it in a postbox.
One petty complaint - generally across the world, stamp design has nosedived. Compared to old postage stamps, they have terrible typography and gaudy colours. I've generally been disappointed when buying stamps to put on postcards. Old stamps were truly works of art.
I looked at his YouTube, and found a stream of industry gossip and beginner content like "web dev tutorials". I have nothing against such content and it may be useful and good fun to watch.
But does that say anything about this particular model? People have been using models effectively for web code since Gpt 3.x.
I would not trust AI on images. But I once had ChatGPT tell me that an MRI report was very likely to be incorrect based on the text, and offered a different diagnosis. Since it was semi insisting, I visited another doctor who made me do a retest. Long story short, ChatGPT was correct.
Again, this is just one single person's experience. So not worth much.
I was an avid reader during the web 2.0 days. Quite sad that his kind of tech journalism vanished; one could feel the decline of independent blogs month over month, while Facebook and Google were taking over the entirety of the web's traffic control.
At thousands of tokens per second, LLMs (harnesses) can start to do a broader tree search of possibilities even in inefficient token space. This unlocks capabilities outside programming.
Would prefer not to offend the author, but I do believe this article has very little for the HN audience. No new insight, and no numbers or new information.
Unrelated to the particular code above. There's a difference between writing code about or adjacent to a proven idea vs writing code in uncharted territory. I suspect that is what happened here. It's the same thing with say music and art. A lot of people today can play Chuck Berry.
Not the same. HttpOnly/Secure cookies were added much later and was not the default. They should have been inaccessible to JS by default from the beginning, and this policy has been a source of countless attacks.
> utility is of a standard that creates affordances for the insecure defaults
You could make the same argument about Cookies.
> as opposed to just designing it right from the beginning
And generally, it's quite difficult to design it right from the beginning because one would often start with the wrong assumptions. Most standards evolve, and it should be acceptable.
Lenses are only tested on bodies which are available at the time of manufacture. They might focus hunt on newer bodies, because of tweaks to AF algorithms (for example, the speed at which instructions are transmitted). Sometimes in ways that can potentially cause damage long term.
> at this point a lens for a mirrorless camera will have a USB-C port
Ideally, camera bodies should support firmware updates via the body in a non-discriminatory way, but until then I wish manufacturers support firmware updates via USB-C.
Looking at you Samyang Lens Station. I think users have been sufficiently upset, and they're adding USB-C to newer lenses.
Agree that the intermediary is not very useful when you can just use a directory watcher, but driving Claude via another app incurs api level costs starting this month, according to the new ToS.
> I’m always amazed by human’s capacity to devalue conscious in things they don’t fully understand
What?
We devalue things we fully understand too. For example, veal = take a baby cow away from the mother, and fry it into cutlets. Or turn the mother into steak. We are well aware that animals have emotions; happiness, sadness and the full range.
tsonic uses NativeAOT by default, and DLR/System.Dynamic isn't supported in NativeAOT. There are switches in tsonic to give you MSIL, but that's used mostly for testing or for compat reasons.
I'll add that page, thanks. Today, almost all of idiomatic TS is supported including most of its utility classes. Dynamic JS-style code is not supported, for example adding a function or a field into an object, prototype-based class modifications etc. I'll compile a list, and include it along with the large docs cleanup planned before v1.
> Also, what's an "ambient surface" in this context?
The idea is that when JS gets transpiled into C# (or Rust, upcoming), JS globals and built-ins are invalid. The native "surface" is C#, meaning the string is .Net's string type and the methods that you expect on JS strings would be missing. But when you opt in to a surface, such as the "JS surface", the compiler applies surface defined translations such as substring becoming SubString, either directly or via a companion helper class. This allows you to write against standard JS and Node APIs, instead of relying on the stdlib/builtins of the target framework (currently CLR). And you get the JS "stdlib" - console, JSON, Date, Map, Set etc.
Projects I maintain:
https://tsonic.org/ - TypeScript to native code compiler.
https://webjsx.org - A library for creating Web Components with JSX
https://tinqerjs.org - Type-safe, composable SQL query builder for TypeScript
https://bashojs.org - Lazy JavaScript Evaluator for building Shell pipelines.
github: https://github.com/jeswin