41–50 of 63 posts
> Upsert ( https://github.com/tc39/proposal-upsert ): [Weak]Map.prototype.getOrInsert(), [Weak]Map.prototype.getOrInsertComputed() Their usage of upsert appears different than I was used to: Me: Upsert = Update or Insert Them: Upsert = Get or Insert
`getOrInsert` here seems to be the Python "set_default" method on dicts, which is very useful at avoiding tedium in some basic data munging
> Upsert ( https://github.com/tc39/proposal-upsert ): [Weak]Map.prototype.getOrInsert(), [Weak]Map.prototype.getOrInsertComputed() Their usage of upsert appears different than I was used to: Me: Upsert = Update or Insert Them: Upsert = Get or Insert
I agree that their choice of labeling the proposal as "upsert" is less than ideal. However, this functionality is reminiscent of a very useful Perl capability known as autovivification[0] as described in the motivation section:
A common problem when using a Map or WeakMap is how to
handle doing an update when you're not sure if the key
already exists in the map.
> Upsert ( https://github.com/tc39/proposal-upsert ): [Weak]Map.prototype.getOrInsert(), [Weak]Map.prototype.getOrInsertComputed() Their usage of upsert appears different than I was used to: Me: Upsert = Update or Insert Them: Upsert = Get or Insert
what is the value of an "update or insert" call on `Map`? is that not just set? `getOrInsert` here seems to be the Python "set_default" method on dicts, which is very useful at avoiding tedium in some basic data munging
It gives a caller the option of alternate logic based on the existence, or lack thereof, of a value.
> is that not just set?
No. The semantics of a "set" operation would overwrite an existing entry (if one exists).
Earlier quoted context omitted.
The same as any other dev tool startup, once money gets tight they will monetize and users will rightfully revolt. Evan You won't break the cycle, tale as old as time.
After getting burned so many times on libraries, frameworks, services and platforms, even entire languages - one learns to be wary of critical dependencies. Every new project offers convenience in exchange for you giving up control of part of the software stack, and the power dynamic is often exploited sooner or later as revenue source. You can't trust anything that becomes irreplaceable, or that you can't write it (…
Earlier quoted context omitted.
That's on me - I saw v26 was released, but didn't realize they'd already done a point release in the ensuing 2-3 weeks!
https://nodejs.org/en/blog/release/v26.1.0 is particularly cool as it added initial FFI support.
Absolutely great idea to expose such "features" to the web dev world!
All the JS devs that are already struggling with mildly complicated language features will love the giant new field of bugs they only dreamed of.
The arrival of the first very hyped tool that will make activating FFI support a requirement will be a great moment in JS history. Happily an army of mildly educated web devs will activate a feature which potential risks they do not even understand.
Luckily nowadays supply chain attacks are a thing of the past in the JS world, oh, wait...
Also the release that drops typescript transforms: https://github.com/nodejs/typescript/issues/51 (I’m not disagreeing to remove it. It just took me a while to find out what happened to it)
Initially it didn't make sense to me... but it looks like type striping is really the way to go for future TS. There's the "types as comments" proposal[1] which could even land on browsers one day. I started using the erasableSyntaxOnly setting in my tsconfig to get ready for this. [1] https://tc39.es/proposal-type-annotations/
I thought this was the release where the built in sqlite got its experimental tag removed, but I don't see it in the release notes. THAT'S got me excited more than Temporal. A stable API, huge utility and one less dependency.
Release notes: https://nodejs.org/en/blog/release/v25.7.0
Node JS team should look into bun and make progress. They are somewhat stable, but bun have lot of features and is more performant than Node.
https://blog.platformatic.dev/bun-is-fast-until-latency-matt...
I'm really looking forward to the temporal api being universally available. Moment and Luxon are fairly good but sensible date/time handling is something that really ought to be baked into the platform ootb.
I always thought the old Date is kind of elegant... increment anything with an overflow and it all wraps around correctly, like `d.setDate(d.getDate() + 100)` to advance a date 100 days. "March 208th" is interpreted like you'd expect, as are the hours and minutes and such. Of course, complete lack of non-local non-GMT time zones is a huge downside.
It's so sad that node refuses to add websocket server support. Adding websocket would simplify stuff tremendously, as well as make deployments much, much more secure.
Why more secure? I see that Deno has WebSockets, but I've never used them: https://docs.deno.com/api/web/~/WebSocket
I (also) basically use only one package: ws.