RX14

online.net themselves (proper dedicated servers) are fine, and their network is reliable, fast and they have good uptime.

Scaleway's hardware and software is a huge problem, it's unreliable to the point of being unusable. I'd only use it for cheap hosting of build server workers. Their disks for example have no RAID, you're expected to mount multiple volumes and perform software raid yourself, except that there's no easy way to do that and also you often run into limits for how many disks you can attach to a VM!

Using systemd automount and NFS you can easily get pid1 unresponsive, hung in uninteruptible sleep forever.

A really good reason to use encryption at the filesystem level is that you can use stream ciphers instead of block ciphers (because you have a place to store nonces). The current disk encryption is based on XTS, which has a section in wikipedia on it's weaknesses [1].

[1] https://en.wikipedia.org/wiki/Disk_encryption_theory#XTS

Kent's a really capable and experienced guy, he has a design in mind and I have every confidence he'll get snapshots working and fast.

But even if that's not true, bcachefs still has an excellent feature set already with great performance, especially in long-tail latency.

It's fast as C in the same way Java and Go are as fast as C. To put it in more concrete terms, it's worst cases on the same order of magnitude as C at least for non-specialized usecases. Whereas dynamic languages are usually many orders of magnitude slower. Comparing "the speed of languages" is largely bullshit and you need to be comparing a specific problem.

Crystal certainly has the genes required to be as fast as Go, and I think very few people are unhappy with Go's performance. Currently the major difference between Crystal and Go's single-threaded performance is the GC and thats not too bad. Parallelism is coming soon.

You could say that Crystal and Go (by default) is faster than C (by default) for IO bound workflows because of how IO is handled in Crystal and Go. But most people look at micro-benchmarks which don't reflect the difficulty of achieving C's performance in C.

Simpler code. This style of code was accepted by the parser but not the automated code formatter. We decided it was easier to disallow it, as the style was uncommon (especially so as ruby doesn't accept that style either, and a lot of crystal's style guidelines are based off ruby's)

No country in the world gives you right of free speech on someone else's platform.

Diaspora is also federated.

This is untrue, Actors have a keypair and inbox POSTs are signed with that key to ensure authenticity. For boosts (Announce), mastodon uses a complex signing algorithm based on JSON-LD, and pleroma just re-requests the post from the original instance and uses that, discarding the relayed object.

What a lot of people are missing is that flatpaks put the flatpak author responsible for the security of every package inside the flatpak. If you use a package from an unofficial rpm or deb repo, they're nearly always still dynamically linked, so security updates for things like openssl still apply.

The beauty of magit is that the ui is just text, so you can navigate through the entire interface using just your keyboard without "shortcuts". Selecting lines to stage is just selecting lines in the diff like you'd select lines in the editing buffer. Its really nice and caters to power users, I don't know of anything else like it.

rare? GCC supports far more architectures than LLVM

The only thing that creates an instance's community is the local time line. Everything else is federated. So what you're really asking for is to be able to easily view another instance's local timeline I guess. There's some work being done in that area, currently focused on merging multiple instances local timelines, but the same technical infrastructure could easily be used to be able to show another instances local time line in the frontend.

CNAME records are dereferenced by the recursive resolver, not the client software, so querying for TXT records will work

You can see the list of favourites just like you can on twitter

I much prefer the https://tools.ietf.org/html/rfc3986 interface, I think it's pretty much perfect.

If they considered it for long enough to put in the article then its clear they are amateurs in electronics.

I rarely notice the difference between release and debug executables unless i'm benchmarking or doing something super CPU heavy. I've so far deployed most of my crystal apps in debug mode because it makes the stack traces nicer because of the lack of aggressive inlining.

glibc has some plugins which make it not easy to statically link. Musl doesn't have that. And alpine compiles openssl etc. with a config amenable to static linking. It's all about distro choices.

Yeah, that makes a lot of sense too. For example a database might want to provide a REST api for management, which would make sense to write in rust if the DB was written in rust.

On the language level, Julia isn't statically typed, and it doesn't have ruby syntax.

On a tooling level, binaries are easier to deploy than the whole julia JIT and your whole source code.

And crystal has dynamic multiple dispatch. It's used a lot, it's great.

Crystal's definitely up there, faster than java at least for most workloads. That can be improved much further by innovating on the GC.

Exhaustive matching is on the cards, parallelism is coming, and any type system changes in the future will be minimal.

And yes, crystal isn't trying to be C, but you can still do many of the low-level things that you can do in C. It'd be nice to know what exactly you were missing from Crystal.

Crystal supports static linking with `--static`, unfortunately glibc and openssl don't like static linking, so it turns out to be easier to do in an alpine linux chroot/container/etc which uses musl instead of glibc. Crystal is in the alpine linux repositories as of 3.8, so this should be now a lot easier.

If someone wants to generate some good tooling around this workflow, it'd be greatly appreciated.

What other people subject themselves to is none of my business :)

And there is need for HTTP frameworks in Rust, for example embedded stuff often hosts HTTP servers. However, just like C we frameworks, it's my opinion they're not for the average use case.

Exactly. I wouldn't write a kernel or shared library in Crystal and I wouldn't write a webapp in Rust.

I can attest to this, the amount of times I've had a look and used go's stdlib as a reference for what to do when implementing something in the std for crystal is too many to count!

Unfortunately, transpiling has a huge bunch of problems, which you can see in for example how quickly nim vs crystal compiler matured - even though the crystal compiler is more complex. I'd be interested in seeing go's stdlib, ssa backend, and toolchain turned into a robust library. Like LLVM but including a GC, a stdlib with a CSP implementation, and a complete toolchain for static compilation.

I don't think any language feels as close as crystal does to dynamic languages while being completely type safe with strong types. I think thats why so many people choose to use it so early. It truly doesn't feel like any other language out there.

If your few hundred lines of code takes 30 seconds to compile, then either it's a crazy macro that expands to hundreds of thousands of lines of code, or I suggest you report it on github.

Crystal - because it uses LLVM's optimizer - is probably better optimized at the codegen level than go. We still have a long way to go to get an optimized GC and similar though. Luckilly, bdwgc isn't too terrible.