Game_Ender

It's interesting to see code bases like this. It does sort of have it all, custom build system, IDL, implementations of things like XML and JPEG. Very symptomatic of the need slowly being filled in the C++ community for a popular build system and package manager.

I hope the author reconsiders their custom license that prevents any public forks of the code base. It's already very hard to get anything out of non-standard monoliths like this, with a custom license that chance drops close to zero.

I have some experience with Bazel, the open source version of Blaze, and I noticed that it's build graph implementation appears to be very memory hungry as well. Such that a few million lines of code already use 10-30GB of memory. Like you mentioned it requires the entire build graph to fit in memory on one machine.

Do you know what sort of graph solution Blaze uses to handle 2 orders of magnitude more code, ie. manage 100's of millions of lines of code? I always assumed it was a distributed graph database, but your article seems to indicate something else.

Chris Latner is the driving technical force behind the project and he wrote Swift. So they were able to fix any issues with Swift so the trade study was “unfair” in that regards.

That is sort of underselling it, Differential has the following features in common with CodeFlow:

- Easy to see the changes an author makes over time to a review

- Integrates with the Package and Ownership system to automatically assign reviewers

- Easy work on changes that touch many files

- Inline lint and code coverage results

- Built in display of unit test and CI results and overall coverage %

- Draft mode to delay review until tests & lint are clean

- Comments move properly as you make changes

- Easy to mark comments as done and find outstanding ones

- Comment on multiple lines instead of a single one

Things that are missing:

- No ability to comment on single characters

- Cannot mark certain files as important

- No way to explicitly mark a change as "simple" (like a rename)

- No web UI to make quick fixes (compared to GitHub is what is most missed)

This sounds like fine model to me, pay more, get faster service. The key should be transparency and a minimum service level, ie. they should lay enough by default that every order will get picked up.

What kind of performance did you get client side? A problem I see in the web space is that fastest encoder you can get is locked inside the browser so you need something in JS or WebAssembly.

What if Google or Facebook offer you $300k no risk, with a relatively standard work life balance. Then you have to really carefully weigh the startup equity package and how much you enjoy the respective work environments.

I have looked at your stack and it’s very cool. One thing I was most curious about is the long term plan for your docker fork. Are you going to upstream changes or APIs so you don’t have to maintain the fork?

The other question I have is about the stability of docker itself at scale. I worry about the reliability of essentially developer/server tooling in an embedded space where there is no ops team to help it along. Have you had any issues?

Is the GRPC API less pleasant because you have to handle those details? Or could it be evolved to be more user friendly?

That is pretty shitty. It use to be that drivers had to return stuff on their own dime, I think the fee is supposed to pay them for that time.

Do you have a citation on humans having from birth classifieds for things like cats?

Statistically if you can get into a tier 1 company you’ll be better off. You get 10-20 years at $200-$400k by default, so $2-8 million. You have to weigh that against the exit success chance and size of a 5-10 year (as typical) startup run to an exit.

It’s not all about money of course, and if you can run your own place you can probably get into into a tier 1 tech company.

64 bit addressed cannot come soon enough. In certain domains the entire data set you want to work with is many times the 4GB limit, and JS has no such restriction so it’s a PITA that WASM does.

Have you done any speed comparisons to other libraries? Since there are so many of these libraries that is a big deciding point, especially in C++.

I feel sad for all the Github users who will have to suffer the awful JIRA UX. It’s a tool that tries to be everything to everyone with a decade of legacy cruft attached. The result is something that is slow, confusing, and incoherent. If you have an expert and sink a lot of time into, you can a few decent workflows, but it’s just not worth it.

In the end though, don’t worry the managers will get their reports and everyone will at least have there feature box checked (assume you don’t care about Markdown).

How does HopsFS compare to Lustre?

It's "aggregate initialization" [0]

  struct S {
      int x;
      struct Foo {
          int i;
          int j;
          int a[3];
      } b;
  };
  S s1 = { 1, { 2, 3, {4, 5, 6} } };

0 - https://en.cppreference.com/w/cpp/language/aggregate_initial...

It has very limited support for H264 advanced profiles that are usually used, which is a down side. I was honestly surprised about the lack of a good decode library.

Anything you can share code wise, curious to learn more.

They are quite different, speaking of Bazel it’s designed to be an all inclusive build system for any language at essentially infinite scale. Which means it:

- Has nice Python based DSL

- Strongly encourages 100% explicit dependency specification

- Has built in caching (local and remote)

- Built in test result caching

- a fully featured build graph query language

- Built in distributed execution support (for any build step)

- All work scales by part of tree you are building not it’s absolute size

- Support for fetching external source code and binary deps

- Has first class support for executing and testing containers

- Has first class support for code gen (ie you can build a compiler use it to generate code, then build its output,and everything works, no hacks in one build system)

The downsides:

- Works best if you all your code is built with Bazel, which makes deps hard

- Support for Python is weak, Ruby non existent, and Node is beta quality

- Has essentially zero convention, everything must be explicitly configured (ie explicitly describing go deps)

- Has a memory hungry local java daemon

- Has a more overhead than ninja (but is more accurate because of hashing and isolation)

Google does not use gRPC internally it, like k8s, it is an open re-implementation of an internal google technology. Also, like k8s & Bazel, it is less advanced and lower performance than their internal technology.

At a high level Google is open sourcing things that have genuine value, but also make integration with their money making services easier.

This does not work because amazon commingles inventory. So anyone who ships that item into your warehouse could end up providing the actual good your are sold even if the “Seller” is amazon.

I am curious to know if this also makes calls from WASM into JS faster. One of the issues with WASM is that you need the JS DOM API, it is essentially your OS abstraction layer, so faster that is, the better WASM will be.

We soon filled the collaboration spaces with desks. The large isles though help put people farther apart so it’s slightly harder to here conversations of people nearby.

Have you tried Phabricator? It tracks completion status of comments on a review. Letting you easily find the un-finished ones. Comments can also apply to single or multi-line sections of the file, and they stay present even as the patch itself is updated in response to comments.

On angle on that is we have societies have created the concept of an entity that is not a person who can assume debt, and has certain speech rights. So that entity is supposed to advance society more than alternative, which would be something like owners being personally liable for its debts and faults.

This a matter of debate in the C++ community. The “almost always auto” camp has the position that it makes the code more flexible and easier to refactor. The fewer times you write a type name the easier it is to change. It also has its uses in template heavy code which is popular on modern C++.

There is a group such as your self that value the extra context the type provides. I think the counter to is that modern tooling can provide this information to you. To split the difference you can use auto just where the type is redundant, like with make_shared, or verbose and unneeded, like with iterators.

Because sick people are desperate we actually make it quite hard for them to volunteer for things like risky medical tests. Requiring more animal or smaller pilot studies first. I don't know the numbers well enough to know whether this is a net win for humanity, but just like any technology development project, the longer your dev cycles the slower things go.

We have an in house "go links" [0, 1] tool, which I update heavily as I work, so everything is always a few key strokes away. So if you want to access "foo", you just type "go/foo". If you want to access to the dev version "go/foo-dev". If the link does not exist you are automatically put into a UI to make the link then and there.

If you have an issue tracking or code review system you customize it so you can do "go/T123" and go to issue "T123". Or for common apps you can put in place simple patterns like "go/foo/id" and it opens that application to looking at that id.

0 - https://github.com/kellegous/go

1 - https://www.golinks.io

Who is Alex Wakefield?