The lack of a comprehensive standard library for JavaScript also results in projects pulling many more third party dependencies than you would with most other modern environments. It’s just a bigger attack surface. And if you can compromise a module used for basic functionality that you’d get out of the box elsewhere, the blast radius will be enormous.
Not to mention a culture of basically one-line packages ad infinitum. I downloaded a JS tool the other day to generate test reports and it had around 300 dependencies.
Needless to say I’m running all my JS tools in a Docker container these days.
So why hasn’t someone created a batteries include JS library? I don’t program in JS on the backend so I don’t know how feasible something like that is.
https://github.com/stdlib-js/stdlib was is one of several attempts at that, but yes the issue is that different people have very different views of what should be standard.
That doesn't seem like it should be an issue in practice? Rather than a single standard library endorsed by the language stewards if the community at large converges on a small handful of "standard" solutions that seems like it would satisfy the security aspect of things.
They’re definitely playing catch up, but the IDE integration makes interactive development really nice. Claude is good for one-shotting things, but I find JetBrains AI integration really useful for working with large codebases where I may be unfamiliar with things.
I think they’ve been caught in a bad spot. They’re a profitable company, but nowhere on the scale of Microsoft. And they don’t have billions of VC to effectively price dump. Other tools that can focus on one thing and burn cash are advancing quickly and some of them don’t really need an IDE at all.
The semi-recent introduction of ACP integration in the JetBrains IDEs has been a nice bridge. But now it’s confusing how everything comes together. I really hope they can survive.
Based on another reply I can’t tell if there’s a clever window-based pun that I’m missing. If not, I think you want “shudder” and not “shutter” here. I’m sorry if I just ruined the joke.
CheapCharts is really nice. I find discovery in the Apple TV store pretty bad otherwise. They earn their affiliate revenue.
I do wish we had DRM-free purchases like we have with MP3s. But this is a big step up over streaming services. The Movies Anywhere integration is handy as well.
After getting scammed on Facebook Marketplace, I look at the profiles of sellers, particularly if they don’t have much in way of reviews. That seems more prudent than creepy to me. I’m not stalking anyone and I’m not looking to be their friend.
Is there a better way to do seller verification? It does seem like an information leak to me. Craigslist and eBay don’t share my identification as a potential buyer. I don’t love the marketplace being tied to a social network, but it’s what many people are using these days.
sure, showing up on suggested friends is weird. the way linkedin does it makes more sense: "these people have viewed your profile". i was picking up on hiding it outright. while that may be justified in your case, it's also reasonable to let them know.
the only people i would really not want to find out that i look at their profile are spammers and scammers (oh, and stalkers).
so both sides have a fair reason. so guess, if you can, choose the social network that works the way you prefer.
In case anyone's wondering, the TruffleRuby project is still going strong. It undoubtedly would be going stronger were Chris still with us. But, some of us that worked with Chris in the early days of the project and others that joined later are still pushing the project forward.
If you're interested in the project, please give it a try. Or, if you just want to chat Ruby compilers, feel free to drop into one of our community channels (Slack or GitHub Discussions).
I'd imagine you don't want to look like you're self-promoting, but I'd really love to read more about the JPEG project. I think it could be quite good for the community. As a whole, I believe Rubyists need to stop reaching for native extensions so quickly. Whether on YJIT, ZJIT, JRuby, or TruffleRuby, all of them will benefit from having more code in Ruby. Incidentally, Chris's final conference talk¹ made the case for moving to a Ruby-based implementation for the Ruby core library.
For those cases where you're writing a native extension to primary bridge over to a native library, you may find either FFI or Fiddle handle your use case quite well.
It's at https://github.com/peterc/pure_jpeg .. and a lot of the recent speedups actually came from contributions by Ufuk/paracycle who, I'm guessing from your bio, you possibly work with? :-)
But yeah, I agree with your point about native extensions. Ruby has gotten so much faster in every form in the past couple of years that I think we could bring a lot more "in house". I think there have been some efforts with this regarding Psych in core as well?
Just in case you were unaware, there is and was a 100% open source variant of the GraalVM referred to as the "Community Edition (CE)"¹. RedHat built their own distribution based on that source tree called Mandrel². The closed source version is faster in many cases, but the CE release in very capable.
What makes plasma the obvious worse choice? I have a 50” plasma that still looks better than just about any non-OLED TV I’ve seen. I understand price was a concern, but OLED TVs sit in that price category now.
The only real downside with the TV is that uses more power than I’d like and, consequently, throws off more heat than I’d like. Otherwise, it’s been very reliable and looks fantastic. I’m curious what I’m missing.
As an apartment dweller, I’m glad I don’t need a heavy plasma anymore. Moving them was a bit of a chore. Also the burn-in issue for things like game overlays is less of a concern in OLEDs. Still happens, but much more slowly.
reply