If things keep going this direction my job title is just going to be "tool call".
I'm a bit intrigued that he ended up happier now that Claude's in the driver's seat and he's playing a supporting role. Maybe I'm ngmi but I'm not sure I'd be happier.
This is a cool approach. Definitely better than an all-at-once cutover!
If only Ruby had better support for static typing though. Clearly infinite dynamism works for some folks and a lot of successful businesses, but I couldn't live without a type checker pointing me towards all of the places that need fixing. Kind of forces you to have comprehensive test coverage or you're screwed, which maybe isn't a bad thing.
I’m working on eslint-plugin-solid for this reason, and while I haven’t implemented this yet (it’s complicated), it will eventually warn when something is wrong with reactivity in general.
Nit: to me at least, "Never deal with another freelancer" comes off as unnecessarily harsh (even if it resonates with some). I understand the product is targeted to early-stage startups without the budget to hire someone, but it sounds like it's putting down the idea of working with a designer altogether (see "no need to hire a designer"), when you could poise it as complementary to working with a designer eventually if we choose to do so.
We've suffered under "bad parts" in JavaScript before, and the solution was not to use them, which works out fine for the most part. But I tend to agree, adding a functional language feature built in a way that conflicts with Ramda and nearly all existing FP libraries is no better than simply using R.pipe.
In response to people repeatedly advocating for F# + partial application over Hack, TC39 responds with what is essentially a threat:
> To emphasize, it is likely that an attempt to switch from Hack pipes back to F# pipes will result in TC39 never agreeing to any pipes at all. PFA syntax is similarly facing an uphill battle in TC39 (see HISTORY.md).
While I can respect differences in opinion, this feels heavy handed.
Here’s the relevant section:
> In most cases, React Native will use JavaScriptCore, the JavaScript engine that powers Safari. Note that on iOS, JavaScriptCore does not use JIT due to the absence of writable executable memory in iOS apps.
I think React hooks would fit nicely anywhere you need incremental computation, and a compiler is the first thing that comes to mind. They’re made for efficiently updating the output (DOM) in response to small changes in the input (sum of past user actions). If you can format your problem like that, based on a component structure, a similar API might be a good fit.
Esbuild does have a JS transform API, so you could write a command line tool that walks the file system (Babel, ESLint, Prettier, etc. all do this so you have examples), transforms each file, and writes the code back out. Snowpack's build command also does this.
I’d push it one step further and include “unskilled” labor too. The value added to society is measurably positive no matter the skill level of the immigrant.
Back in college, I had a summer research internship where the previous year, the interns tried to migrate a large Java code base to Gradle and left it in a broken state. Knowing little more than the Java language at the time, I spent about a month getting Gradle to build it correctly. It was incredibly frustrating not to be able to understand what Gradle was actually doing, instead only copying random lines from example configurations. Almost every time I would fix some errors, new ones would appear with no way to know how close I was to the end.
It’s nice to know that I wasn’t the only one who struggled!
Good point about conditional compilation. It’s a trade off I’ll leave for language implementors to make. I tend to think that easily preventing a malicious package from sending your file system contents to some server is usually worth 10-20% perf loss, and that might even be made up by Wasm SIMD and other proposals.
I would agree with you, except that LLVM IR isn’t platform independent. For all of Wasm’s warts it’s the best supported low level cross platform IR we have.
I think Wasm outside the browser could benefit package managers. As far as I know, Rust and some other compiled languages distribute their crates/packages in source code form, which then have to be compiled before use. If packages were distributed in Wasm (plus headers/type declarations), you could JIT or quickly AOT compile them. Plus, you’d get safety guarantees to make sure a package isn’t doing anything it hasn’t been permitted to do.
I'm a bit intrigued that he ended up happier now that Claude's in the driver's seat and he's playing a supporting role. Maybe I'm ngmi but I'm not sure I'd be happier.