thanatos_dem

Yeah, but CRDB’s logo is pretty stylized and simple/clean. The hand drawn style for the gopher just didn’t work for a lot of applications.

It was too detailed to use as an icon, and the lines were too thin to look good when printed.

I know folks love the gopher, but I’m a fan of this to be honest.

The hand drawn gopher just looked... childish? It definitely didn’t give me the impression of an efficient and well put together programming language.

I’m at one of the big 5, so everything goes through code review now, but since we’re a small team, we do monitoring ourselves, and as a result we have a lot of ways to bypass the process in case we need to get a high priority hot fix out.

When I was doing a small startup, we had a small phabricator installation which I loved using. It’s very engineer-focused in a lot of its tooling and features, but has an integrated task management systems and wikis, and tools for pre-commit reviews, or post commit reviews/audits, and I found it much easier to run and maintain than github enterprise or the Atlassian suite (and it’s free).

From OP's description

  > issues a write every time someone types into a text field

With more than a handful of people, this is getting into conflict territory pretty rapidly, especially if the document is structured as a single row (hopefully it's more granular than that). Time for some back of the envelope maths:

Assuming that an average person types at around 200 words per minute (number pulled from https://www.livechatinc.com/typing-speed-test/#/), that's a character every 300ms on average. With 10 people editing the document, that's a character every 30ms on average, which can easily lead to conflicts if they're all trying to update the same resource.

Lordy, relational databases are not the way to go for that problem... With a single shared resource (document), you're going to be encountering write conflicts left and right.

Have you explored implementing a CRDT based solution like WOOT instead?

7-8 seconds? Something definitely sounds misconfigured. I've been running a 1.1.x cluster for quite a while and I've never seen a single row transaction take that long. And even the slowest queries took at most ~500ms, and that was with:

  - Replication factor increased to 5x (rather than the 3x default)
  - 8 indexes on the table being modified which also needed to be updated
  - Nodes spread across North America, incurring higher RTT latency between nodes
  - Relatively high contention on the data triggering client-side retries
  - HDD's as the storage medium (RockDB is optimized for SSDs)

Site is down... that doesn’t exactly bode well for an article seemingly about programming.

Java also has a very different development structure. It's owned and build by Oracle (RIP Sun), who get final say in everything added to the language. This additional red tape, and a smaller dev team working on both bug fixes and new features naturally lead to a slower release cycle.

Compare that to Node, which, while organized by the Node.js foundation, makes it very easy for people to contribute bug fixes and ideas. The core node repo is nearing 2,000 contributors. Having people help out, even if it's just with bug fixes, allow core developers to focus on new features. I don't think iteration speed is a sign of instability. Node has a well established release cycle and LTS process.

It wouldn’t surprise me if they were dummy or dramatically simplified graphics just to make people more comfortable. Planet Money had a show on this topic a few years back - https://www.npr.org/templates/transcript/transcript.php?stor...

They drew a comparison to the early days of elevators, when everyone was terrified of them, especially after transitioning away from having a lift operator controlling it. The solution at the time was the big red emergency stop button.

Golly gee, I can barely hear you all the way up there on your pedestal.

I used linux for a good long while. Started with Ubuntu, then on to Mint, then Arch as I became more of a "power user". But you know what? Sometimes I don't want to put in manual effort to get things to work, even if that means I lose some customization. Over my years with linux, I've had driver issues with displays, with the network manager, with mounting remote drives... Basically any interaction with the hardware was a solid kick in the groin. Since switching to a Macbook, everything has been smooth sailing.

And especially nowadays with homebrew and docker, all the tools I need are available on a Mac, and it's a more integrated experience, and IMHO it looks better. But if you like linux and it works for you, that's also fine by me. To each their own.

No real benefits that I’m aware of, and until Google starts to care about privacy more I wouldn’t expect them to invest in developing a secure coprocessor like the Secure Enclave, so you’ll probably be limited to 3rd party alternatives such as yubikey for the foreseeable future.

This is really exciting to me.

I know a lot of folks will probably see this as an old company trying to catch a ride on the cryptocurrency hype train, but to me this has always been the dream of cryptocurrency; a new class of technology to help solve types of problems previously very difficult to address, and it's awesome to see a >125 year old company taking a shot at adopting it for a novel use case (licensing of and payment for photography).

I'd very much rather see more stories like this than more early stage ICOs from alt coins made by a handful of people with unknown/dubious intentions.

Unfortunately TermKit is effectively dead, with the last commit being almost 6 years ago - https://github.com/unconed/TermKit

For folks who prefer video to articles, Steve Mould released a video yesterday on the same topic - https://www.youtube.com/watch?v=fNzuzssl4eU

Cool to look at the original work on this from 1988, and see just how little it's changed in the nearly 3 decades since.

Go for instance makes use of Duff's devices generated for each architecture in its core runtime. You can see the code to generate the devices here - https://golang.org/src/runtime/mkduff.go

We can look at the ProduceRequest logic in their design doc - (https://docs.google.com/document/d/11Jqy_GjUGtdXJK94XGsEIK7C...)

  Check the sequence number map to determine if the PID is already present. 
    If it is not, check sequence number. 
      If it is 0, insert the PID, epoch, and sequence number into the PID mapping table and proceed to append the entries.
      If the sequence is not zero, return the InvalidSequenceNumber error code.
    If the PID is present in the mapping, check the epoch. 
      If the epoch is older than the current one, return InvalidProducerEpoch error code.
    If the epoch matches the current epoch, check the sequence number:
      If it matches the current sequence number, allow the append. 
      If the sequence number is older than the current sequence number, return DuplicateSequenceNumber. 
      If it is newer, return InvalidSequenceNumber.
    If the epoch is newer, check the sequence number.
      If it is 0, update the mapping and allow the append.
      If it is not 0, return InvalidSequenceNumber.

That's a pretty straightforward approach of enforcing idempotency; checking producer and sequence IDs and throwing them out if they aren't correctly ordered. The other big addition to the code base was cross-partition transactions, which, while pretty cool, is a far cry from "Exactly once delivery".

I think the term they meant to use was “idempotent”, but that doesn’t get attention the same way that claiming to violate the FLP result does.

My favorite question to ask is one I've iteratively improved on over the last 5 years or so.

To start, I always phrase the question as a real world example - "I have a server, and we currently have some functionality X. I want to augment it in way Y, and I want you to help me do that". I structure it like a real problem rather than a toy "write an algorithm that does this, and demonstrate that you know this one arbitrary data structure I have in mind" type of question. The end task is the same, but it gets the candidate in the mindset of doing actual work and thinking about the implications of their design decisions.

The question starts simply enough, with most candidates at the level I'm interviewing for able to complete it in ~10-15 minutes, focusing on basic language structure common to most languages, and simple DS/A.

Then we get to have a little fun. Based on the role that the candidate is being considered for, how they did on the first part, and the feedback on other interviewers on their strengths and weaknesses, I can steer the question in several directions:

  - Let's talk about concurrency (also plays nicely into the "this is in a server we have" setup, since thread safety is not just a nice-to-have, but a real requirement)
  - I'd like to augment it even further with new functionality (which involves much more deep knowledge of various data structures and their nuances)
  - I'd like to build this into a whole separate service to handle this functionality.  What would that look like?

I come with a laptop and some skeleton code in a handful of common languages, and give the candidate the choice of white boarding or typing, as well as allow them to make use of the internet, to look up libraries, APIs, etc. This all also plays into the general theme of "structure the interview like the work they'll actually be doing".

If the candidate is not doing terribly well, the question can also stop after the first part (which even the weakest candidates can generally get to a decent solution on after the length of a full interview). This avoids the candidate from feeling like they did terribly, and leaving the interview with a negative impression.