sizediterable

Any plans to make it possible to run shellcheck on the embedded scripts?

I'm wondering if the OP meant to share https://www.perplexity.ai/hub/blog/introducing-comet-plus (2025)

Need it be said https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-va...

Highly recommend the Dr. Stone anime if you're interested in a story with the premise of starting civilization from scratch but armed with the sum total of modern human knowledge about science and engineering.

I also wrote my solution in Rust. I was pleased that my approach gave me an opportunity to write a linked list and get the chance to apply some rarely used learning[0].

My solution doesn't use SIMD, but is actually takes about the same amount of time as the the solution in the article, given the same number of cores, though an glaring weakness of my approach is that it can only scale up to 7 cores as written.

Rough outline of how mine works:

- Set current best GCD to 1.

- Search through all valid board configurations.

- Bail out from the search early if the current partially generated board couldn't have a GCD greater than the current maximum found, e.g. if we've only generated two rows of the board, and the GCD of those two rows are already less than the max.

- Update the current best GCD as you find higher ones.

- Share the current best GCD value across multiple threads. That way the longer the program runs, the earlier and earlier the searches will start bailing out.

- Don't always read from the shared variable to avoid contention. Instead, each thread has its own copy of the last value it read which we compare with first before copying and caching the shared value.

- Another interesting property of this approach is that it can be used to validate the correct solution even faster than it takes to find it. Instead of initially setting the max GCD to 1, set it to `solution - 1`. That way branches in our search will bail even sooner from the beginning. This leads to the program running about 20% more quickly.

Source: https://gist.github.com/lazytype/35b45f3ea81b5c1c5555546fe6f...

[0] https://rust-unofficial.github.io/too-many-lists/

Out of Dropbox's long history of acquisitions, very few of the products from said acquisitions have survived. Did this factor into your decision to join Dropbox and if so how did you weigh that risk?

I was recently trying out Node's newish test runner [1] but wanted better error reporting and was grateful that Node provided an API that let me use any TAP-compatible error reporter. I did find unfortunately that most error reporters I tried seemed to have problems, the most common one was not reporting whether or not a test was skipped, which was a deal-breaker. In the end I settled for tap-mocha-reporter [2] since it worked well enough. I did have to end up patching it to not print extraneous new lines, I suspect an artifact of it using YAML for its internal representation. I do wish there was an error reporter that mimicked exactly the format of Jest, as it's what I'm most used to.

[1] https://nodejs.org/api/test.html

[2] https://github.com/tapjs/tap-mocha-reporter

I don't know if its aim is necessarily to model anything you can do in JS. At the moment, TypeScript has zero understanding of prototypal inheritance and there hasn't been any visible progress in that direction.

These are the usual questions I seek answers to first when seeing a new programming language:

  - What does writing asynchronous code look like
  - Will it have any novel or less mainstream features, e.g.
    - Algebraic effects [1]
    - Contexts/Capabilities [2]
    - Linear types [3]
  - Is the type system sound and does it support/need type casts
  - Does the language support interfaces/traits/protocols
  - How rich are generics, e.g.
    - Explicit variance annotations on type parameters
    - Lower or upper bound constraints on type parameters
    - Higher-kinded types
  - Is structural vs nominal subtyping more prevalent
  - Does it have algebraic data types? Generalized algebraic data types?

[2] https://docs.hhvm.com/hack/contexts-and-capabilities/introdu...

[3] https://austral-lang.org/linear-types

How about making Github-Current actually have a good code review UX?

Thanks. I think by default, "do what you want" also includes the ability to redistribute the source code with a different license, so would probably need a clause to cover that at least.

From https://fig.io/privacy:

Inevitably, there will be users who, for whatever reason, don't want their usage of Fig to be personally tracked. Of course. It's your data and software on your device. You shouldn't even need a reason. We want to cater to these users. And we will. But unfortunately, we are so early on in the process of building Fig that we need to be able to speak to our users. De-anonymising telemetry for the time being while minimisng the events tracked enables us to do this in a non intrusive way. But it is of course not for everyone. Therefore, once we reach a critical mass of usage in the coming months, we will then anonymise all telemetry, making Fig more accessible.

It has been several months since this was written. Are they still collecting de-anonymized user data?

The title should be changed. Chris never says that the core team, i.e. the people on the team, is toxic. He said that the environment is toxic which leads to behavior such as getting yelled at.

But what if your services are written in different languages from each other and they need to perform similar authz checks? Sure, each service might need be responsible for its own data fetching, but the actual logic over the data can be written in one common language (Rego) and have one single source of truth.

Congrats Sully and thanks for your work on mypy!

I remember there being a section demonstrating this in the manual for my TI-83 calculator [0]

It prompted me to learn a bit more about IFS and discover one of my favorite fractals ever. The word "chaos" where each stroke is made up of the word "chaos" [1]. I spent a bunch of time coding up the fractals on that site [2] on my calculator

[0] http://manualsdump.com/en/manuals/texas_instruments-ti-83/13...

[1] http://paulbourke.net/fractals/ifs/chaos_1.gif

[2] http://paulbourke.net/fractals/ifs/

As the CEO of a company that offers authz as a service it's a bad look to start a list containing your own articles and none of your competitors' instead of contributing to an existing resource like https://github.com/casbin/awesome-auth

Always happy to see companies thinking about typing

I wrote-up a high-level comparison between the type systems of TypeScript and mypy here that might be of interest to type enthusiasts

https://news.ycombinator.com/item?id=29249328

There’s a Scrabble version of this that’s free to play

https://spellingquest.online

If you prefer playing as an app over in a browser

https://store.steampowered.com/app/1086630/Spelling_Quest_On...

If you didn't already notice, this is what Excalidraw uses to get its distinct style

The UI certainly reminds me of Scuba. Is a comparison to Honeycomb available? The founders are both ex-FB people also offering Scuba-like observability as a service.

Why would anyone want to have their metadata be in a blockchain where they can't have it be deleted? If we never get stricter GDPR laws + enforcement the next best thing for me would be to be able to pay a service to delete all existing metadata on me out there + subscribe to preventing it from being recorded it the first place.

Just now learned what Jamie Tartt's theme song in Ted Lasso is based on having never listened to Baby Shark before.

In my experience, porting code more or less directly from one language to another is faster and easier than people assume

Converting code to Rust while keeping the logic one-to-one wouldn't work. Rust isn't ensuring memory safety by just adding some runtime checks where C/C++ aren't. It (the borrow checker) relies on static analysis that effectively tells you that the way you wrote the code is unsound and needs to be redesigned.

For implementing things like programming languages, I think parser combinators also allow you write better and more specific error messages than something like a parser generator. Though I think most programming language authors optimizing for error messages tend to go with a bespoke approach.

Most of my experience is with mypy and TypeScript.

If your Python code relies a lot on dynamic dict objects instead of classes you'll have a rougher time. You have to use `TypedDict` which is not very expressive and syntactically verbose. This could be considered a good thing since you'll be pushed to use things like `NamedTuple`, `dataclass`es, or (a third-party extension) `attrs`. Most JS/TS code is probably using plain objects rather than `Map`s. The TypeScript syntax for expressing object types is extremely expressive, though annoyingly `Object.keys` and `Object.entries` are not precisely typed (For legitimate soundness reasons. Object types are "inexact", whereas in Flow you can express both "exact" and "inexact".)

mypy supports union types, but not intersection types, unlike TypeScript. The closest you can get is creating a `Protocol` (i.e. interface) that extends multiple `Protocol`s, but this can be cumbersome.

mypy's generics are strictly worse, both syntactically and expressively. In mypy you can express both co/contra-variance explicitly, whereas in TypeScript variance is implied by the readonly-ness of an object's properties and variance of its methods.

Both mypy and TypeScript have `Any`/`any` types, but only TypeScript has the safer `unknown` type. You can kind of use `object` in mypy for this purpose.

Both have a "bottom" type, "NoReturn" and "never", respectively.

mypy has decent support for classes and subclass type-checking. TypeScript doesn't truly understand sub-class relationships nor even prototypal inheritance.

Both are very configurable in terms of the strictness checks, but mypy's flags are more poorly documented and it requires more work to increase the level of strictness. Enabling "strict" in TypeScript enables most of what one would want.

Anecdotally, I would say TypeScript has better control flow analysis. With mypy you have to cast a lot more often.

The TypeScript ecosystem is much stronger. Most new packages have types as do major packages (located in DefinitelyTyped repo). Python's typing ecosystem is fairly poor. There are barely any packages in Typeshed and a lot of new packages are still untyped.

TypeScript has a dedicated team at Microsoft working on it with a public roadmap and milestones, though big features only come around one or twice a year. Python's type ecosystem is more design by committee. A lot of conversation happens over mailing lists, monthly video calls, and a yearly conference. Since there are multiple Python type checker implementations, there isn't a single unifying vision. The core mypy team is employed by Dropbox, who has them spending most of the time migrating the giant monorepo from Python 2 to Python 3.

The TypeScript team is fairly decent at fixing true bugs between releases, but a lot of "bugs" are really feature requests that tend to become long-standing Github issues. On the other hand, last I checked, there are still some long-standing bugs in mypy that haven't been fixed (as not to spread FUD, I will say that they tend to be very edge-casey and more for power users).

Note that there are multiple type checkers for Python at this point with varying capabilities, but they share the same syntax and basic types since they're built into the language runtime. I expect Pyright (also from Microsoft) to come out ahead as more people start using the Pylance VSCode extension. mypy's editor/IDE support is not great, based on my VSCode experience. I haven't tried it with PyCharm.

Python is experimenting with a novel approach where objects have two reference counts, one exclusively for the owning thread and another for all other threads, improving performance when most of the increments/decrements are done by the owning thread.

https://lwn.net/Articles/872869/

ah, makes sense!

People like to bring up reference cycles a lot as if it's always a deal-breaker, but for short-lived processes it kind of seems like a non-issue. Anecdotally, we've seen Instagram get overall gains by disabling GC in Python (which will still do reference counted cleanup).

A Rust team alum has actually written a bit about the topic:

https://without.boats/blog/notes-on-a-smaller-rust

https://without.boats/blog/revisiting-a-smaller-rust