What are you talking about. A. those systems don't make sure you partake responsibly, you even admit it yourself with the claim that legalization reduced popularity. and B. it's like so so so much better than alcohol or tobacco. Are you seriously suggesting that's where the bar should be for government regulation?
All drugs should be legal and we should have good programs to take care of you if you fuck up their use, it would be vastly cheaper and better for society than criminalization, especially if your claims about legalization reducing use are true.
Speaking of, LTT posted a video about DDR pad, which triggered the sleeper cell programming of my youth and I opened up StepMania to play a few rounds. I was shutting down the program and I noticed the build info in the corner.
6-19-2005
My copy of StepMania is turning old enough to drink in like a month and it's still fantastic, software updates are (mostly) a scam.
Why people use Deno and Bun over Node? I think it's neat that there are competitors for JS runtimes, but I really don't understand what advantages I'd get by swapping to one of these over Node. Bun has no REPL and worse JS engine, Deno is just Node with a restrictive, annoying permission system and no sqlite. Both claim better performance, but that only seems true in cherrypicked benchmarks, and in my tests (granted about a year ago at this point) both alternatives under-performed Node in my workloads. What am I missing?
EDIT: Actually I just remembered I delivered a small ERP tool to a business a while back and I did opt to use I think Bun for that because it had the most robust tools to wrap a project into an `*.exe`, that was definitely a better experience than Node. Though since that was dependency-less JS I did the whole thing using Node and then just shipped it with Bun.
I switched to Deno because it is the only option out of the 3 that allow monorepo workflow without building .d.ts files. Bun and Node both do type stripping or compiling of TS, but it only works for the entry package of the running script, not any of the linked dependencies from the same repo.
There are still things I dislike about Deno, but it really does make package development a lot simpler. JSR is a great upgrade from NPM, and Deno makes it so simple to publish to both NPM and JSR. Strict IO permission system and WebGPU support are also nice to have.
> wrap a project into an `*.exe`
Deno makes this simple too. Though that's where it's bundling features stop. Honestly I am okay with that, I'd rather use Rolldown or Vite for web or library bundling.
Deno has been great for wrapping the dozens of REST API's I need to use in the world in MCP. The no compilation thing means that I can push and it's literally deployed in seconds. I run several dozen of the little servers for various use cases, it's a very cheap way to build an automatable life
> Both claim better performance, but that only seems true in cherrypicked benchmarks, and in my tests (granted about a year ago at this point) both alternatives under-performed Node in my workloads.
1) You need to retest again, mainly because Bun's own native tools should be faster than Node's.
2) My experience is the opposite: For the niche uses I'm on, the rendering process is done 2-3x faster with only a few changes to use Bun's tools.
In what particular way? I've been using Typescript a lot more recently (unfortunately XD) and I've found the native experience in Node to be totally fine.
Node's built-in profiler doesn't work with Typescript, which is one part of Node not natively supporting TS. Idk how it is in Bun, cause that made me abandon TS rather than abandoning Node.
> To use TypeScript with full support for all TypeScript features, including tsconfig.json, you can use a third-party package. These instructions use tsx as an example but there are many other similar libraries available.
> Deno is just Node with a restrictive, annoying permission system
I find Deno's permission system amazing! (although I didn't stick with it until v2)
Everything is closed by default but you're able to write code like normal.
Whenever it needs a permission the code pauses (like `debugger;`) and the terminal asks you "hey, should this script have access to this file/folder"?
- You say yes and the code continues (no need for exceptions).
- You say no and the code stops.
Then after your program has run, you put only the answers you said yes to in a deno.json file and it never has to ask again.
---------------------------------------
I'm currently working on a project that takes in heap of files from one one set of devs, processes them with a heap of files from another set of devs, then compiles and outputs the final product.
The file structure goes like this:
1. Group one devs
2. Group two devs
3. Build output
4. Compiler
So group one only works in their folder, and group two only works in their folder, but needs to see group one's folder.
With Deno it's stupidly easy to do stuff like:
- Scripts in group one only have file read access to group one.
- Scripts in group two only have file read access to group one and two.
- Scripts in the compiler only have file read access to group one and two's folders, only have file write access to build-output folder, and can read the env file in the project's root directory.
- One specific file is only allowed to access a specific URL and port
- Another specific file is only allowed to use the FFI to access a specific shared object.
I don't need to worry about a dev's script accidentally using the wrong file because they messed up the path.
I don't need to worry about a dev accidentally overwriting a file and losing data.
I don't need to worry about a dev blindly going down the wrong road because an LLM convinced them to.
I don't need to worry about a dev using LLMs agents that are trying to make the project do something it's not supposed to do.
I don't need to worry about a dev including a dependency that's doing what it shouldn't be doing.
I don't need to worry about the equivalent of `rm -rf ./$BUILD-OUTPUT` but the env file wasn't set up correctly and $BUILD-OUTPUT is empty/undefined evaluating to `rm -rf ./` and nuking the project's root.
I don't need to worry about supply-chain attacks.
I don't need to worry about namesquatting attacks.
There's so many things I don't need to worry about.
It's such a breath of fresh air.
It's just: you guys read from here, other guys read from here, the compiler writes to here.
Whenever something doesn't fit, the program stops and tells you what file is trying to access what permission.
---------------------------------------
aside: Node added a permission system but it's completely broken by design. Everything's open and you have to manually close each permission yourself. Oh, you don't want this project to have file write permissions? Lets just turn off the file write permissions (and forget to also turn off the subprocess permissions to spawn a shell which rm -rf's the wrong folder).
otherwise, bun has a big "batteries included" thing going on.
For instance,
- Bun.$ to run shell commands
- an entire redis client at Bun.redis
There are dozens of other examples like this
For rapid prototyping, complex glue scripts, etc. it's an absolute joy to work with. There is often no reason to pull in any dependencies to accomplish what you want.
Is this just urbit all over again? Making up a bunch of terms and abstractions to make a mundane thing seem novel? At least in this case it seems more like psychosis than grift. In any case, I will be interested to see if this tooling yields any actual results, doesn't seem like it so far (except maybe more tooling lol).
My bestie works at this company and looking from the outside they have a good engineering culture. I do think Haskell is the right tool for the job, and they are playing to it's strengths, but part of me wonders if a lot of their success is attributable to the place just being well run in general.
That would not run counter to the popular (whether true or not) idea that by using functional programming languages you filter for a higher quality labor pool / applicant pool.
That wouldn't apply here, since as the article says they hire "generalists, and most of them have never written a line of Haskell before joining."
In any case, I think the "Haskell tax" concept (where you can pay well-paid programmers less if you have a Haskell shop) is stale by now. Rust attracted away a lot of FP-ers, plus mainstream langs like C++, Java and even Typescript got smarter. Haskell's biggest problem by far is the tiny labor pool, which Mercury seems to wisely avoid.
The version I've always heard is just well designed but less popular languages, but the ones I can think of were all functional (Haskell/F#/OCaml/Clojure/Elm/Erlang)
False, if you're printing PLA or something sure, but you can print all sorts of exotic fiber reinforced materials, and maybe if you're clever enough you can even use the anisotropy of the print to give you extra strength in the relevant directions. I'm not claiming that it's possible to 3D print noctua quality fans, especially on consumer FDM machines, but I think "inability to find a rigid enough material" is not going to be the failure mode, at least not on it's own. I could believe "inability to find a rigid enough material that can also get the required surface quality".
Abliteration can't teach the model something that wasn't in pre-training, it's just fixing refusals from post-training. I don't find the delta to be that big in practice and it really depends on what you're doing with the models anyway. If your primary usecase is sexy roleplay I think the loss of absolute capability is probably worth the abliteration, for malware research it's probably better to just jailbreak.
I've mostly found that finetunes and abliterations are of limited use but that's recently changed for me. My default model for the past week or so has been a Qwen 3.6 tuned on Opus 4.7, it's definitely a bit worse than the base Qwen in terms of precision and "intelligence", but it MORE than makes up for it in response style. Way easier to get it to write things that I want to read, it's way more terse, way fewer emoji. Best local rubber duck by far.
You can disable your watch history and then you only get related videos to the current video as far as I can tell. It does remove all of the videos from the home page, but I've been using youtube like this for 6 years and I don't mind it one bit. I have an alternate account with watch history enabled and I look at the home page every once in a while (obviously my history is very stale), it doesn't seem like anything of value was lost and I definitely never have to see a Mr. Beast thumbnail on my normal account.
A highly beneficial side effect is that it disables the main YouTube shorts stream. You still get some shorts for your subs and such, but the bottomless heroin feed if Shorts is gone, and good riddance.
You can remove shorts under YouTube’s time management settings > daily limits > shorts feed limit, you can set the max allowed time to 0 min and the effect is they all disappear.
Oh interesting, I just have a userscript that completely excises shorts from youtube, seems like a neat side effect though. Always a jumpscare to use youtube on someone elses computer and see all the shorts, ads, and sponsored segments. We had TiVo like 30 years ago, this is a solved problem.
All drugs should be legal and we should have good programs to take care of you if you fuck up their use, it would be vastly cheaper and better for society than criminalization, especially if your claims about legalization reducing use are true.
reply