scc VS Seaweed File System

View on GitHub

Going to say my own https://github.com/boyter/scc/ which I have used to turn down projects of "Oh we just need to do X"

It allows me to evaluate the code-base quickly and see where potential issues are, and find hidden complexity in the code. I have said no a lot due to it. The only reason it exists was because I got caught out from another project, which wasted months of my time.

Otherwise IntelliJ and the JetBrains IDE's in general.

Very cool to see this here, Ben! It was fun beating the ins and outs of your work on this in the TZ discord.

Also, off-topic but as you know, I recently tried out your scc tool and am eagerly awaiting its support for Elixir templates (.eex, .heex)!

https://github.com/boyter/scc

I believe tokei is the best rust option as of now, but despite my burning passion for rust I've switched to using scc instead as I find it faster and more convenient. Not really an option for you if you're trying to bake line counting into the binary, obviously.

I've seen some real world example where Go was as fast or faster than Rust for CPU / io intensive task.

Go is a fast language even with a GC.

https://github.com/boyter/scc/#performance

I don't trust your qualitative "LARGE" for the project. I would recommend you pass your project through something like a software metrics tool https://github.com/boyter/scc to better measure what you're up against in terms of Flutter/Dart AND Rust code base.

SCC has a complexity score

FYI: Planning to move from github.com/chrislusf/seaweedfs to github.com/seaweedfs/seaweedfs in the coming days. It may cause some problem for package reference, building, documents, and links. Sorry for the change!

Besides storage itself, S3 API access cost can be high if frequently accessed. And latency is unpredicatble.

You can use SeaweedFS Remote Object Store Gateway to cache S3 (or any S3 API compatible vendors) to local servers, and access them at local network speed, and asynchronously sync back to S3.

https://github.com/chrislusf/seaweedfs/wiki/Gateway-to-Remot...

SeaweedFS: https://github.com/chrislusf/seaweedfs

I don't know if it fits all of your requests, but you can take a look at seaweedfs, which is pretty good

Seaweedfs deserves a mention here for comparison as well.

If you're still talking about SeaweedFS, the answer seems to simply be that it's not a "raft-based object store" as the parent described. That 'proxy' node you mention is a volume server itself, and replicates it's whole volume on another server. Upon replication failures, the data becomes read-only [1]. Raft is not used for the writes.

[1] https://github.com/chrislusf/seaweedfs/wiki/Replication

For computers, batch IO operations are much faster than random IO and can easily saturate the network.

This benchmark uses large batch size, 64MB, to test. There is nothing new here. Most common file systems can easily do the same.

The difficult task is to read and write lots of small files. There is a term for it, LOSF. I work on SeaweedFS, https://github.com/chrislusf/seaweedfs , which is designed to handle LOSF. And of course, no problem with large files at all.

This is a fair complaint. :)

For filer metadata, you should just pick the one you are most familiar with.

There is a wiki page for production setup. https://github.com/chrislusf/seaweedfs/wiki/Production-Setup