I've been using TrueNAS for six years already. I've built a custom server
- Intel dual core Atom CPU
- Passive cooling for the CPU, two fans for the HDDs
- A small Supermicro motherboard with IPMI and six SATA connectors
- 16 gigabytes of ECC RAM
- Six 14 terabyte hard disks
- Fractal Design Node case
- ZFS with RAIDz2
But this setup is getting old, I've had a few errors already from the CPU. My plan next year is to build a rack server with a modern AMD Ryzen CPU, 64 GB of RAM, Proxmox with TrueNAS scale in a virtual machine and re-use the disks I have in the current setup.
Proxmox is much nicer for virtual machines and LXC, and if you need Docker, you can run them in the TrueNAS Scale VM.
Hardware wise I bought a TerraMaster F4-423 used last year for about 300€. It's a great device.
Software wise, I use Fedora Server, although if I had to reinstall now I would use AlmaLinux because I don't need the new stuff coming with Fedora Server on my NAS.
It's getting forked. It's not that SerenityOS is losing anything it already has. Sure, the Ladybird project moving forward is choosing to use different rules/philosophy about using 3rd party code/libraries - but I find it hard to agree with your assertion that this is a negative move.
Yeah. I see a lot of "typescript is more readable" arguments out there, but I find this code dense and verbose. The more words you use to explain something the more likely you are to be misunderstood. What we're looking at here is basically a restricted wrapper for console.log and a regex implementation meant to simulate a logger in another language. Why not just write a cross-compiler for that language? There's no learning curve for the syntax then, only the target platform.
<rant>The invention, support and defense of Typescript baffles me. It feels like an intensely wasteful work-around for poorly written interpreter error messages concocted by comp-sci grads who think compiled languages are superior to interpreted ones in all situations and they want to bring this wisdom to developers of loosely typed languages. </rant>
This isn't typical application code, but either proof-of-concept or library code. What you'd instead get is the type error, which in turn would explain itself well enough- that it expected a certain type, and got a different type.
The reason you wouldn't want a cross-compiler for that other language is that there are true semantic differences between languages, and many languages simply cannot fully support the JS runtime- and if your primary application is still in Typescript, trying to cross-compile for a single feature is downright ridiculous.
> The invention, support and defense of Typescript baffles me. It feels like an intensely wasteful work-around for poorly written interpreter error messages concocted by comp-sci grads who think compiled languages are superior to interpreted ones in all situations and they want to bring this wisdom to developers of loosely typed languages.
I sincerely don't think statically typed languages are superior, but I'd argue a large part of the increase in quality over the last few years of the ecosystem is due in large part to Typescript.
Is it going to fix all, or even a majority of the issues? Probably not. But if it can improve upon the situation I don't see why we'd make perfect the enemy of good.
Hmm, let me try to defend TypeScript, then. I think it’s a terrific language, and more importantly manages to salvage JavaScript into a very decent language.
Coming from a mostly C/C++ background, I had been very skeptical of “gradually typed” languages like Dart (and now Python), but I’ve come around to the view that for many purposes it’s better than a completely statically typed compiled language.
You don’t need to compile TS at all, just bundle it, which is lightning fast in current tools, so it feels almost as nimble as pure JS. But you have almost-instant type checking in tooltips and code completions, and you can run a full project check whenever you want (that’s slow, but still way faster than compiling Rust).
The type system isn’t perfect but it’s incredibly expressive. Almost anything you could imagine doing in straightforward JS can be typed (admittedly sometimes with a lot of effort and head-scratching) and once typed it’s generally easy to use with confidence that most runtime errors will be avoided.
The fact that JS and TS are separate languages is a bonus -- it keeps TS honest, and the competition between JS engines means runtime performance is great. If you were designing TS from scratch, I think you’d be tempted to add some kind of runtime type reification, but TS is better off without that. Completely erasing types means compilation will always be fast, and in my experience RTTI causes more architectural problems than it solves.
> Hmm, let me try to defend TypeScript, then. I think it’s a terrific language, and more importantly manages to salvage JavaScript into a very decent language
Counterpoint: It's a desperate attempt to make Javascript useable and nearly does so, but ends up being weird in itself to get around the limitations of the underlying language.
I use Typescript most days and I hate it. Part of that is that npm is a dumpster fire but a lot of it is that Typescript is a rubbish version of much better languages and it hurts to use it. I am so desperate to get back to something sane like C# that I will quit this job for less money.
I'm sure we'll never fully agree, but I am surprised that you think TypeScript "ends up being weird in itself". To the contrary, I think the type system feels very natural; what feels weird is when you switch to another language and realise it doesn't have e.g. sum types.
One big problem I do bump into with TS is that the tooling of TS itself is pretty bad -- the way it manages compiler options, import paths, etc. Luckily you don't need to use TSC very much in practice, and other TS-aware tools like esbuild and Bun are vastly better.
(Likewise, I find myself much happier with NPM than with other package managers like Maven or PyPI, at least when you switch the NPM tool itself for a better drop-in replacement like PNPM.)
Anyway, each to their own! I hope you're able to find a good C# gig or similar.
This is such a cynical take. The point is to model what types exist at runtime in the type system, so that you can reason about those same runtime types statically. They’re only “fictitious” if they’re defined incorrectly, or if the type system can’t sufficiently express certain of their nuances. The former is usually only the case when developers intentionally work around the safety provided by the type system; the latter is possible, but at this point it’s usually only ever the case for patterns that are hard to reason about regardless of the type system or even the presence of types at all.
I find myself inclined to the opinion you're disagreeing with in all honesty.
When defining types in other languages, the task is prescriptive (you specify what fields there are in a type and the runtime accepts this as law), but in Typesxript the task is meant to be descriptive (as you say, one models the types that exist at runtime which is the inverse).
I was excited about Typescript when I learned it, but found myself disillusioned by actual experience when using it (of course others love it and have good reason to). Had defined classes in Typescript so I can have some of my types reflected at runtime.
Curious what your issue was with duck-typing. Were you effectively looking to create ADTs that are required to go through a specific step-by-step process, not simply 'look like' the thing that was expected?
I mean, all types are "entirely fictitious" as far as the computer is concerned. Yeah they usually have fewer layers than JS does, but that's a pretty arbitrary line to draw.
This problem is very old at this point. I'm doubtful that Bun has "solved it" any more than other tools. They've just selected a different set of trade-offs that will result in a different set of packages not working. Is there a reason to think they've cracked some code that other tools were unable to?
In Bun, you can use import and require in the same file. There's three steps for what makes this work:
1) We patched JavaScriptCore to load ES Modules synchronously when they don't use top-level await. The main tradeoff here is that requiring an ES Module which uses top-level await is unsupported (Bun throws an exception when you try to do this)
2) To support require() inside ES Modules, we add `import.meta.require` and have a transpiler integration to convert calls to module.require() or require() into import.meta.require(). This either loads the file as an ES Module or as a CommonJS module, depending on what the transpiler says it is
3) We rely on certain heuristics to decide whether a script is an ES Module or a CommonJS module. If they use certain sloppy mode or CommonJS-only features, it becomes CommonJS. If they use ESM features or it's somewhat ambiguous, it becomes an ES Module.
While I appreciate the convenience that will result from this excellent engineering, I'm concerned that this could result in a lot of mixed module files that now can only work with Bun.
Is there an option to require each file to use either CJS or ESM features, but not both? If not, may I suggest adding that option?
Seems like a case for ESLint and I agree with you.
Mixed require and import (the latter in both its static and dynamic variants) is already possible with Webpack and Vite.
I hate it and would complain about any code introducing this in any kind of review.
It's great for integration, full stop.
This is an inconvenience where tradeoffs really show and demand to study the behavioral/semantic differences.
Funnily enough, I still find Bun interesting.
Regarding import.meta., I already love Vite's dynamic import transpilation features.
They aim to work almost transparently and often do (I am not even talking about the glob feature here).
That being said, I'm unsure if Bun's way of bridging the module ecosystem gap using import.meta will be as useful.
If you ask me, frontend code should ban Node/CJS/require entirely or transpile it into static or dynamic ESM imports; respectively.
Any case where this is not possible unambiguously is a case for human intervention and code rewrite/conversion.
It's a legacy module system with a lot of code written in it. Without mixed support, you can't rewrite code incrementally to use the ES modules. As a consequence, many projects still stay with CommonJS, since the migrating everythin in one go is a big hurdle.
That throws since we cannot make it synchronous. It works by reading the internal state of the Promise and getting the value out of it if the Promise is fulfilled.
No, it's a problem because the formats are fundamentally incompatible and it's impossible to infer the author's intent. A package with no imports/exports or requires could be either ESM or CJS and no heuristic can solve for that reality.
How common are packages with no imports, exports, requires, or "module.exports="?
I imagine that's quite rare, because such a package would only be imported or required for its side effects; and because that package cannot import or require any others, could you safely just assume that if it was `require()`ed use CJS, and if it was `import`ed, use ESM?
Rare things still happen a lot at the scale of npm. And due to transitive dependencies it winds up affecting a lot of actual users. And this is just one example of an incompatibility, there are many more. Bun didn't discover a silver bullet here that dozens of other tools in the past missed on.
Do you have an empirical basis for that? I'm curious because on one hand, Bun is advertising they are solving a major challenge for library authors, really betting quite heavily on that being persuasive for adoption.
The risk for Bun's adoption is that they're wrong, of course.
The risk for Node's usage is that they're right, and library authors begin urging users to use Bun because it's 100x easier than making a useful library with Node. (This will happen very slowly, but things that happen very slowly can start happening all at once very quickly.)
Yeah, I don't believe GP. Their assertions that Bun hasn't solved this (or that the heuristic used is inadequate) are basically based on speculation without any evidence.
Assuming it has no imports or requires, and no references to meta, it’s a bare JavaScript file, and whether you treat it as esm or cjs shouldn’t matter, no?
JS has two top level grammars, one defaults to loose mode and the other defaults to strict mode, among other nuances.
Possibly the most devious nuance is whether the spec's appendix B applies, which affects whether html comment syntax is valid (yes, this is a thing). The html comment token can therefore be parsed either as a comment or as a series of operators depending on the grammar being used.
Effectively, this means it's possible to craft a program that does different things in CJS vs ESM mode.
Yeah, definitely recommend you try it before discounting... I too have been super jaded with the current Node import ecosystem (esp. as an author), but Bun has basically become something of a silver bullet, with some small exceptions.
If I want, I can literally run a TS file directly with mixed import/require (not that you would ever) directly, without a package.json, tsconfig, dependencies, etc.
In my experience, it's basically Node, minus all the setup/config/build headaches.
Excess energy wasted = Unnecessary cognitive load * number of affected (readers + writers) * lifetime of Moonbit code * Calories per thought
Tongue in cheek, yes, but I’m sure that if we can make this about contributing to climate change via energy consumption then there will be a sufficient group of folks ready to label it evil.
