groan

base64 is often even larger than an escaped JSON string. and not human-readable at all.

I'll take stringified json-in-json 90% of the time, thanks. if you're using JSON you're already choosing an inefficient, human-oriented language anyway, a small bit more overhead doesn't hurt.

(obviously neither of these are good options, just defer your parsing so you retain the exact byte sequences while checking, and then parse the substring. you shouldn't be parsing before checking anyway. but when you can't trust people to do that...)

The comment you replied to was posted in good faith AFAICT. Your “stop suggesting it” is unnecessarily antagonistic.

seems pretty bloated

https://github.com/voidDB/voidDB/blob/master/go.sum

A lot of it is indirect dependencies, and most of the direct dependencies in the go.mod are just for benchmarks, as far as I can tell.

That is correct. Remove directories "test/" and "cursor/test/", then run "go mod tidy"; you should see only one dependency in go.mod:

  require golang.org/x/sys v0.29.0

Could have used "syscall" in the standard library instead of "golang.org/x/sys/unix" if not for these: https://pkg.go.dev/golang.org/x/sys/unix#F_OFD_GETLK

... and this: https://go.googlesource.com/proposal/+/refs/heads/master/des...

Look ma, no more dependencies! https://github.com/voidDB/voidDB/blob/v0.1.4/go.sum

Only "x/sys/unix" outside of tests/benchmarks

      ~/go/src/github.com/voidDB/voidDB  git:(master)
      $ go run github.com/tailscale/depaware@latest
      github.com/voidDB/voidDB dependencies: (generated by github.com/tailscale/depaware)

            github.com/voidDB/voidDB/common                              from github.com/voidDB/voidDB+
            github.com/voidDB/voidDB/cursor                              from github.com/voidDB/voidDB
            github.com/voidDB/voidDB/free                                from github.com/voidDB/voidDB
            github.com/voidDB/voidDB/node                                from github.com/voidDB/voidDB+
            github.com/voidDB/voidDB/reader                              from github.com/voidDB/voidDB
            golang.org/x/sys/unix                                        from github.com/voidDB/voidDB+
            bytes                                                        from github.com/voidDB/voidDB+
            cmp                                                          from internal/fmtsort+
            encoding/binary                                              from github.com/voidDB/voidDB/common+
            errors                                                       from bytes+
      D    fmt                                                          from golang.org/x/sys/unix
            hash                                                         from github.com/voidDB/voidDB+
            hash/fnv                                                     from github.com/voidDB/voidDB
            io                                                           from bytes+
            io/fs                                                        from internal/filepathlite+
            iter                                                         from reflect+
            math                                                         from encoding/binary+
            math/bits                                                    from golang.org/x/sys/unix+
            os                                                           from fmt+
            path                                                         from io/fs
            reflect                                                      from encoding/binary+
            slices                                                       from encoding/binary+
      LD    sort                                                         from golang.org/x/sys/unix
            strconv                                                      from fmt+
      LD    strings                                                      from golang.org/x/sys/unix
            sync                                                         from encoding/binary+
            sync/atomic                                                  from internal/bisect+
            syscall                                                      from github.com/voidDB/voidDB/cursor+
            time                                                         from github.com/voidDB/voidDB+
            unicode                                                      from bytes+
      W    unicode/utf16                                                from internal/poll+
            unicode/utf8                                                 from bytes+

Thank you for showing substantive evidence in defence of voidDB; it is very vindicating.

It doesn't take much to split your go.mod file require blocks into needed dependencies, and test dependencies, with a few comments explaining the why of each dependency.

Go tooling will preserve your go.mod comments and structure.

You can also consider moving integration tests and benchmarks to another module in the same repo.

Great ideas. I have broken out the tests into their own modules within the same repository. Thanks!

A bit aggressive. No, wouldn't connecting to a slow 3g tower affect ping times to all global servers proportionately?

The proposal has other flaws, but phone to tower latency isn't one.

> No, wouldn't connecting to a slow 3g tower affect ping times to all global servers proportionately?

Yep. Per the article (last point under "How it works"):

> Users with a high latency to all servers can be excluded from polls, as this is a strong indicator of a VPN/proxy usage

Something seems off about how they're measuring latency (which seems to be "fetch various AWS Lambda endpoints"), since their system seems to think that I have hundreds of milliseconds of latency even to the nearest AWS region (even though in practice it should be an order of magnitude lower), and multiple seconds to the other side of the world.

edit: well, if the slowness is just on last-mile delivery, then it should be a fixed amount of overhead added to each connection (rather than a multiplier). For instance, I have about 8ms of latency added by my ISP just by the first hop into their network. But it's that same 8ms overhead whether I'm connecting to a server on the other side of town, or on the other side of the world.

If eliminating signal from malicious, remote actors is more valuable than preserving signal from rural areas, which may very well be the case depending on the application, then adopting this might solve a real problem for you.

I don't see anything terribly idiotic in that.

edit: to be clear I think this is likely one of those solutions that creates more problems than it solves. There's a gulf of sympathy separating that from "idiocy," however.

wrong. your definition essentially means "business friendly", the wiki is open source in every way that matters, except for "lets make money off this persons free work"

Where is the vertical scroll bar?

Ooh, what page? browser and OS please?

Scrollbars are completely disabled in Firefox on the front and docs page. In Chromium there's only horizontal scrollbars in the code snippets.

Looks intentional to me:

  html {
      overflow-y: scroll;
      scrollbar-width: none; /* Firefox */
  }
  
  html::-webkit-scrollbar {
      display: none; /* Chrome, Safari, and Edge */
  }

Fixed. Thank you. Previous incarnation/experiment leftover.

Hey, thank you, I like scrollbars. :)

Oh, and, nice project. Thoroughly agree with the sentiments expressed in the FAQ.

that's exactly why I stopped using C/C++. building is many times a nightmare, and the language teams seems to have no interest in improving the situation