sciyoshi

Thanks for posting! I don't see any mention of beads, which can also store the database in Git (via Dolt). How does this compare to it?

It's the same reason I was nervous moving our company domain to a .ai TLD; your entire presence, identity and trust is now beholden to the whims and political winds of a Caribbean island smaller than Topeka.

Is this not what programming alongside or with an AI agent is these days? Brainstorming, reviewing, debugging. The only difference is there's no second human building a working knowledge of the code being written.

Indeed. I was mainly responding to the comment about waiting for "independent seasoned mathematicians to verify", whereas in this case it is easy enough to convince oneself of the counterexample's correctness.

Looks like this has already been formalized: https://github.com/deancureton/jacobian

A docker-compose equivalent for running native processes: https://github.com/sciyoshi/decompose

Similar to another tool called process-compose but with a CLI that mimics the docker one more closely and doesn't start a TUI by default.

Useful if your team's on nix and doesn't need containers.

This is essentially what Shopify did with River (https://shopify.engineering/under-the-river), and we built out something similar at our company.

I'm sure the labs are working on this sort of thing - Managed Agents are probably the closest?

Because I was curious about this: the use of "categorically" in the phrase "categorically false" doesn't directly relate to the concept of "categories" as groups or classes of things. Turns out it's actually related to the philosophical use of the term which originated with Aristotle and was further developed by Kant (see "categorical imperative" on Wikipedia).

"categorically" in this situation is used to emphasize the absolute, unambiguous, and unconditional nature of the falseness.

Congrats to the black team on this release, and thank you scrollaway for your fork. We are in a similar position where we are (for various reasons) stuck on using tabs for an existing project. Luckily it seems like there might be some movement on this front where the maintainer team is at least more receptive to reopening this conversation:

https://github.com/psf/black/issues/2798

There's definitely a segment of people for which GSuite access and cloud storage of notes is a non-starter, but in many cases those can be mitigated even when it comes to early adopters in larger enterprise companies (eg SOC-2 compliance). On top of that, you get a lot of the usual benefits when using a collaborative tool: others can help take notes for your meetings so that effort is shared, agendas can be prepared beforehand, contributed to by all the meeting attendees, and easily accessed via your meeting invite.

You're right that one of the biggest reasons to switch is that everyone else has switched (which is a bit sad to me since I think Coffeescript had some good features to offer), and community support + developer tooling are always important factors to consider. We were on Coffeescript 2 which had niceties like JSX syntax support, but even then our team had issues with the lack of IDE support for it. We were using it with GraphQL/Relay which also meant we needed to maintain our own compilation toolchain.

In the end, the benefits of having types and first-class editor integration convinced us to switch fully which we did over the course of a few months towards the end of 2019. One of our team members even wrote a blog post about how we did it:

https://dev.to/alexandras_dev/decaffeinating-2020-migrating-...

More power to you if you keep on using it, but maybe this can help explain the reasoning behind why we made the decision to switch.

I really respect companies that have well-written engineering blogs that go in-depth into their technical problems - Figma comes to mind here, for example.

For a small team/company, what are some good tips or resources on how to start an engineering blog? We've worked on many interesting challenges and I know the team would have a lot of insights to share, but it can be difficult to find and justify the time that writing a good article takes, and it's not something that everyone is necessarily interested in doing either.

I'm curious about the mention of Cloudflare's culture of "internal blogging". That seems to me like it could be a first step in that direction.

There's always more than one way to do things, and it's good to be aware of the trade-offs that different solutions provide. I've worked with systems like you describe in the past, and in my experience you always end up needing more complexity than you might think. First you need to learn Packer, or Terraform, or Salt, or Ansible - how do you pick one? How do you track changes to server configurations and manage server access? How do you do a rolling deploy of a new version - custom SSH scripts, or Fabric/Capistrano, or...? What about rolling back, or doing canary deployments, or...? How do you ensure that dev and CI environments are similar to production so that you don't run into errors from missing/incompatible C dependencies when you deploy? And so on.

K8s for us provides a nice, well-documented abstraction over these problems. For sure, there was definitely a learning curve and non-trivial setup time. Could we have done everything without it? Perhaps. But it has had its benefits - for example, being able to spin up new isolated testing environments within a few minutes with just a few lines of code.

We've been running our own cluster on EC2 nodes built with kops and it's worked well so far. As for logging, which part of ELK is heavy? You can use the cloud operator to run it from within your cluster (https://www.elastic.co/elastic-cloud-kubernetes). We've also switched to https://vector.dev as a more lightweight alternative to filebeat/logstash.

I would highly recommend getting to know https://github.com/ovalhub/pyicu, which in addition to counting grapheme clusters with BreakIterator can also do things like normalisation, transliteration, and anything else you might need to do relating to Unicode.

Seems really interesting after a quick read-through. Specs that allow range-based validation look useful, and the structural declarations also feel like they'll help reduce a lot of boilerplate and repetition. I wonder how this compares with Dhall and Jsonnet, both of which I've been looking into as a safer alternative to templated YAML. With Google putting its weight behind this I'm curious if it'll start finding its way into K8s.

I've had a good experience with pip-tools (https://github.com/jazzband/pip-tools/) which takes a requirements.in with loosely-pinned dependencies and writes your requirements.txt with the exact versions including transitive dependencies.

Funny, because I think the Wolfram language (also as a long-time user) is actually really well-designed and consistent, and has stood the test of time. Even ignoring the standard library, it has a really expressive syntax for pattern matching and functional programming, and I find that you can often do very complex things with very little code. For doing any kind of symbolic manipulation or lazy evaluation, it's pretty hard to beat.

On the other hand, I feel that his theory of cellular automata as some fundamental underpinning to mathematics is misguided.

Agreed on avoiding yaml templating at all costs, but I've also found that you don't normally need a full programming language for these types of config files - if you do find yourself reaching for those tools you might be better served by something like Dhall https://github.com/dhall-lang/dhall-lang (which has its own K8s bindings as well)

I would agree with that. If you take a look at the exhibition match replay, there's some cases where it makes objectively suboptimal decisions. We couldn't see this during the live stream, but the double immortal warp prism caused AlphaStar to bring back its entire army from across the map, when a few units at home would have been enough to defend. It even kept trying to blink its stalkers to a place where the warp prism couldn't be reached. Perhaps this version with the limited viewpoint hadn't been trained with enough games?

That idea of having quorums voting to establish consistency is essentially what Stellar does in their consensus protocol: https://www.stellar.org/developers/guides/concepts/scp.html

I think GP meant to say that Sweden is buying other countries' trash: https://www.independent.co.uk/environment/sweden-s-recycling...

Nice to see that we'll be getting a more flexible design system to work with - one that will hopefully reduce a bit of the homogeneity of the current generation of Material-based apps while still keeping some consistency.

Has anyone used the MDC Web toolkit? Does it play nicely with React and Vue?

I'd also be interested in some performance comparisons with a library like CrossFilter [1]. Does the improvement outweigh the penalties of crossing the JS/WebASM boundary?

[1] http://square.github.io/crossfilter/

> They're literally making up money as they see fit.

I'm playing devil's advocate here (I agree that the whole Tether situation is concerning), but also genuinely curious - is this any different than what banks have been doing for forever with fractional reserve? Even if Bitfinex is overcommitted and there's more USDT in circulation than they have in USD reserves, is there a problem unless a lot of people try to convert at once?

Not quite. A sha256 preimage attack would possibly let one mine blocks more quickly, but would be significantly more difficult than a collision attack, which won't help you in this case. On the other hand, finding private keys for a given account would require solving elliptic curve discrete logarithms, and only then for bitcoin addresses which have been used as inputs to transactions. (This is one reason why change addresses are a good idea).

There's been a number of attempts at least, see Ouroboros: https://eprint.iacr.org/2016/889.pdf

I'm still on the fence about the viability of PoS from the perspective that PoW at least means you have a chance of reward from using mining hardware that you probably already own, whereas PoS increases that barrier of adoption.

See also discussion at https://news.ycombinator.com/item?id=15642856

For something as important as contract code, there should still have been more failsafes. Even just having a kill() on the main contract that doesn't delegate out to the library would have protected against this.

There's also Simplicity, which is not Turing complete and includes formal verification with Coq https://news.ycombinator.com/item?id=15588380