ripley12

Take a look at the Debian/Ubuntu install instructions. “Installing this package automatically starts and runs Caddy as a systemd service” https://caddyserver.com/docs/install#debian-ubuntu-raspbian

> VB(.NET) is terrible for large or complex systems.

This doesn't make sense to me. I worked in a 50/50 VB.NET/C# codebase for years and while I don't love the VB syntax, the two languages were 99% interchangeable. Nearly anything you can do in C# you can do in VB.NET, and vice versa.

Yes, I think you're generally right. I'm a big fan of this blog post: https://eli.thegreenplace.net/2018/measuring-context-switchi...

> The numbers reported here paint an interesting picture on the state of Linux multi-threaded performance in 2018. I would say that the limits still exist - running a million threads is probably not going to make sense; however, the limits have definitely shifted since the past, and a lot of folklore from the early 2000s doesn't apply today. On a beefy multi-core machine with lots of RAM we can easily run 10,000 threads in a single process today, in production. As I've mentioned above, it's highly recommended to watch Google's talk on fibers; through careful tuning of the kernel (and setting smaller default stacks) Google is able to run an order of magnitude more threads in parallel.

> Nushell is building an entirely separate monolithic ecosystem, which goes against the open ideology of Unix

I wouldn't entirely agree with that (but I am biased, I work on Nu). One of the nice things about Nu is that it's trivial to bring in data from elsewhere; if other tools speak JSON, XML, TOML, CSV, etc. it's easy to bring that into a Nu pipeline.

If you want to use grep in Nushell, you can use grep and pipe the output to `lines` to split the raw output by line.

The app store / Office admin stuff. When I was dealing with this stuff 2 years ago, it was insanely difficult to deploy a web add-in internally (something involving the "Microsoft 365 admin center"), let alone deploy it to customers (gotta get approval to deploy it in the special Office app store, and hope+pray that your customers' IT departments don't block that).

Compare to VSTO, where IIRC installation just involves editing a registry value to let Office know where your add-in can be found on disk.

> The problem with Office.js is that it’s just simply too hard to get started with all the npm bloat for the average Excel user (even more professional devs struggle)

IMO deployment is an even harder problem. The Office team makes it incredibly difficult to deploy web add-ins (presumably for business reasons) and accordingly most companies I'm familiar with are still using the ancient, barely-supported COM+VSTO add-in models.

That's 15 lines of configuration and 3 CLI commands to install a service. I have done this hundreds of times but I still need to keep a template around for unit files, I often forget to run `daemon-reload`, etc.

I like systemd but I can see a lot of value in friendlier tools like this. What I really want is a TUI tool like Lazydocker for managing systemd services.

This is a really good answer, thank you.

That makes a lot of sense to me. I find it useful to keep the two separate; I think most of my confusion stems from people trying hard to use 1 tool to do both.

> the main benefit is that it keeps your tools/libs updated with the latest.

For tools you want to be on the latest version of, why not use a package manager like homebrew that isn't tied to your distro?

I've never understood the Linux culture of tightly coupling OS and package management (and so I use brew even on Linux), but I seem to be in the minority.

I love Homebrew. I find it especially useful on Linux, where it lets me avoid all the pain of distro-specific packaging.

I just bought a 13th gen Framework and it shipped in 3 days. I think it’s only the AMD models that have the really long waits.

Why is that the case? SQLite isn't inherently slower than MySQL for these kinds of read-heavy uses (it's often faster!).

This isn't the whole story, but linking is CPU-intensive and older linkers are mostly single-threaded. A lot of the performance gains come from doing work in parallel, which makes for a big improvement on beefy modern multicore CPUs.

Rui's given some good talks about Mold if you want more info: https://www.youtube.com/watch?v=hAt3kCalE0Y

About a year ago, I was seeing incremental builds go from ~8s to ~2.7s with Mold. Huge quality of life improvement.

(fairly large Rust project, 24-core machine, Linux)

It depends a lot on the project and your CPU. Incremental build (build, change 1 thing, rebuild) times are affected more than clean build times, because linking is a larger % of an incremental build.

When I benchmarked it about a year ago (with a fairly large Rust project on a 24-core machine), incremental builds went from ~8s to ~2.7s.

You don't necessarily need to trust them for them to be useful.

I can often evaluate a Copilot autocompletion (check that code looks right at first glance, check that it compiles, hover over method+type signatures to see their docs, run the code) in less time than it would take me to find+read a Stack Overflow answer.

I'm about 2 years into primarily writing Rust (after a long time in the .NET world).

The borrow checker slowed me down a lot at the start but these days it's not a big deal. Eventually you internalize the easiest ways to make it happy (clone and pass references as needed) and can reserve tricky optimizations for hot paths where they actually matter.

I would say that today, most of the times I sit down to write some Rust I'm nearly as productive as in higher-level languages... but then ~20% of the time I get bogged down in complicated type signature stuff (especially with async code, ugh) and it's a time suck.

I found that Tailwind helped me get more comfortable with CSS. If you put the mechanics of using classes aside, it’s essentially just a well-curated subset of CSS with great documentation. Way more approachable than the sprawl of CSS itself.

The MSIX/AppContainer story is... long, sigh. IMO developers mostly rejected those technologies for reasons unrelated to permissions+capabilities:

- MS tried to use it to force developers to distribute their apps through the Store

- Eventually they gave up and let people use it outside the Store, but didn't invest enough in bug fixes and backporting the fixes, so it's impractical to use outside the Store

- It requires code signing outside the Store which is a huge pain

> If you don't care about allocations why are you using Rust in the first place?

Because Rust excels on a lot of dimensions other than "systems programming"; Cargo is fantastic, the ecosystem of packages is great, it's one of the only languages that takes cross-platform support (including Windows) seriously, and it's got sum types.

Or, as withoutboats put it: https://twitter.com/withoutboats/status/1658536526043570179

He has publicly lamented the lack of funding for long-term research many times, yes.

Not sure exactly where the data comes from, but the game uses an API at https://neal.fun/api/password-game/wordle?date=2023-06-15

Seems like it has answers up to July 30, so he's either a time traveller or it's possible to get future answers by looking at the Wordle source.

Because it changes the kinds of things you can build: https://www.sqlite.org/np1queryprob.html

With SQLite, it's often practical to issue several queries in situations where that would be too slow for a traditional client-server database.

Not a ton of detail, but Tailscale uses it: https://tailscale.com/blog/database-for-2022/

From the website: "Vals are small JavaScript or TypeScript snippets of code, written in the browser and run in our servers. Create scheduled functions, email yourself, and persist small pieces of data — all from the browser."

Not really. It’s nice to have it built-in with a very polished UX, but FancyZones is more powerful.

The new Snap Layouts feature is quite good. One of the best recent features IMO, just very simple+functional window management.

I believe this got fixed in .NET 5; now only native libraries need to be extracted and stored elsewhere on disk, and many applications can get by without native dependencies.

> When the app starts, the managed DLLs are extracted and loaded in memory, avoiding the extraction to a folder.

https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...