HN user

simonz05

490 karma

Website: simonklee.dk E-mail: hello@simonklee.dk

Posts21
Comments85
View on HN
pedropark99.github.io 1y ago

An Introduction to Zig

simonz05
4pts0
www.nowpublishers.com 1y ago

More Modern B-Tree Techniques

simonz05
3pts0
cedardb.com 1y ago

Can You Do Both: Fast Scans and Fast Writes in a Single System?

simonz05
2pts0
encore.dev 2y ago

Encore AI API Creator

simonz05
1pts0
twitter.com 2y ago

Serverless Runtime / Database Co-Design with Asynchronous I/O

simonz05
2pts1
blog.felixge.de 2y ago

Debug Go Request Latency with Datadog's Profiling Timeline

simonz05
1pts0
mitchellh.com 2y ago

Ghostty Devlog 002

simonz05
1pts0
systemsdistributed.com 3y ago

Systems Distributed Conference

simonz05
3pts0
brooker.co.za 3y ago

Atomic Commitment: The Unscalability Protocol

simonz05
1pts0
tigerbeetle.com 3y ago

A programmer-friendly I/O abstraction over io_uring and kqueue

simonz05
127pts33
handmade-seattle.com 3y ago

Handmade Seattle 2022 (live conference)

simonz05
4pts0
www.usenix.org 3y ago

Can Applications Recover from Fsync Failures?

simonz05
59pts46
www.hytradboi.com 4y ago

Have you tried rubbing a database on it?

simonz05
2pts0
github.com 4y ago

Distributed Transactions

simonz05
2pts0
engineering.backtrace.io 4y ago

Verneuil: S3-backed asynchronous replication for SQLite

simonz05
7pts1
scattered-thoughts.net 4y ago

Why query planning for streaming systems is hard

simonz05
116pts10
blog.acolyer.org 5y ago

A client-centric specification of database isolation

simonz05
6pts0
github.com 6y ago

Go's updated generic proposal (Contracts)

simonz05
52pts61
twitter.com 9y ago

Elastic acquires application performance monitoring company Opbeat

simonz05
6pts1
pingcap.github.io 9y ago

Distributed SQL database (TiDB) source code explained

simonz05
102pts18
camlistore.org 13y ago

Camlistore (0.1 released) your personal storage system for life

simonz05
4pts1

This type of runtime type checking is quite common in Go. An example from bufio.Reader's WriteTo method:

  // WriteTo implements io.WriterTo.
  // This may make multiple calls to the [Reader.Read] method of the underlying [Reader].
  // If the underlying reader supports the [Reader.WriteTo] method,
  // this calls the underlying [Reader.WriteTo] without buffering.
  func (b *Reader) WriteTo(w io.Writer) (n int64, err error) {
   b.lastByte = -1
   b.lastRuneSize = -1
  
   n, err = b.writeBuf(w)
   if err != nil {
    return
   }
  
   if r, ok := b.rd.(io.WriterTo); ok {
    m, err := r.WriteTo(w)
    n += m
    return n, err
   }
  
   if w, ok := w.(io.ReaderFrom); ok {
    m, err := w.ReadFrom(b.rd)
    n += m
    return n, err
   }
  
   if b.w-b.r < len(b.buf) {
    b.fill() // buffer not full
   }
  
   for b.r < b.w {
    // b.r < b.w => buffer is not empty
    m, err := b.writeBuf(w)
    n += m
    if err != nil {
     return n, err
    }
    b.fill() // buffer is empty
   }
  
   if b.err == io.EOF {
    b.err = nil
   }
  
   return n, b.readErr()
  }

We recently went through a similar situation at a logistics company in Europe. We decided to bring software development in-house after facing similar frustrations with a third-party provider. It was a challenging process, especially in attracting talent, but ultimately, it allowed us to build a solution tailored to our needs.

I’ve been with the company for the past 4 years, working as a lead software engineer. If you’re interested, my contact details are in my profile, and I’m happy to setup a call

I understand and respect your perspective on Austin and Cherry’s involvement in the Go community. Their contributions may indeed be less visible but still impactful. However, the community’s perception of leadership is crucial, and visibility plays a big part in that. For instance your long form blog adds context to decisions you’ve taken in the past. I hope their active roles will become more apparent, fostering a stronger connection with the broader Go community.

I'd also like to see less google control of the project.

That doesn't look like is going to happen — the leadership change announced here seems to me to continue on the Google path. Both Austin and Cherry are relatively unknown outside Google and are to my knowledge not active in the community outside Google.

I cannot remember (or find) where I signed up for updates, but I get an email every 6 months (or so) from Lorenzo Stoakes personal email. Probably just send him an e-mail and he'll add you to his list.

See also The Linux Memory Manager: https://linuxmemory.org/chapters Last update the author sent out was in early July noting that the book is now in editing:

I am happy to report that I have completed the first draft of the book [...] I am now in an editing phase, which may well take some time. Sadly I can't give a reasonable estimate as this will be done in concert with my publisher.

Paul, impressive work on the rewrite.

Can you shed light on the biggest challenges and steps you (and the team) took to overcome them to succeed with the rewrite? We often hear about how major rewrites can fail or be massively delayed, but you seem to have succeeded.

The paper analyzes how file systems and PostgreSQL, LMDB, LevelDB, SQLite, and Redis react to fsync failures. It shows that although applications use many failure-handling strategies, none are sufficient: fsync failures can cause catastrophic outcomes such as data loss and corruption.

For people interested in this topic I can recommend "Can Applications Recover from fsync Failures?" by A. Rebello et al[1]. The paper analyzes how file systems and PostgreSQL, LMDB, LevelDB, SQLite, and Redis react to fsync failures. It shows that although applications use many failure-handling strategies, none are sufficient: fsync failures can cause catastrophic outcomes such as data loss and corruption.

- [1] https://www.usenix.org/conference/atc20/presentation/rebello

At first sight, Verneuil has very similar goals to Litestream, a daemon that ships SQLite WAL segments to S3. A key difference is that Litestream currently does not support read replicas, while Verneuil was designed to trivially offer (slightly stale) read snapshots.

Nice to see more tooling built for SQLite, and seems like a well thought out alternative to Ben's popular Litestream project.