emptysea

I'm curious why the IIFE is even necessary in this case. There is already a top level await in the `for await` right?

Looks fine IMHO once the IFFE is removed:

  for await (const conn of Deno.listen({ port: 4500 })) {
        for await (const { respondWith } of Deno.serveHttp(conn)) {
          respondWith(new Response("Hello World"));
        }
    }

Edit: Oh is it so it runs in concurrently and avoids the synchronous handling?

In V8 I believe it's limited by the stack size and when you get a stack overflow that gets converted to a RangeError in JS land.

OTOH, Webkit and Firefox have arbitrary limits 65537, and 500k args.

https://bugs.webkit.org/show_bug.cgi?id=80797 https://github.com/mozilla/gecko-dev/blob/1475b3b0cb274b2a71...

Got to be careful with the argument spread, since depending on the JS engine and how large the `list` is, you can end up with a RangeError

e.g.,

    Math.max(...Array(100_0000).fill(0))

results in:

    Uncaught RangeError: Maximum call stack size exceeded

Curious if there’s anything public about improving ruby performance from the I/O angle mentioned in the post.

Also interesting to see Mypyc, Pyre related AOT compiler (forget the name), and now this.

Great to see! We’d gladly compile our code in CI if it meant better perf (already do for the UI stuff)

Leetcode will teach you algorithms assuming your read the solutions and various tutorials on the site. You might have more breadth by taking a course though — there are only so many algorithms that fit into a LC style problem.

Never seen tiptip before, looks pretty slick.

At work we need only the most basic customization (some inline spans for template vars) and we've cobbled together a Draft.JS implementation that's pretty buggy and has random runtime errors (unhandled nulls internal to the Draft.JS code).

I'm curious how Slack does their e2e tests, are they spinning up every dependent service for each PR or are there some long running services shared among the PRs?

Related, are the databases and storage (e.g., s3) populated with fake data for the test runs before hand?

At my current place we have a couple separate services, but haven't built out e2e tests.

At $work we use Tray to sync salesforce and some other CRMs to our database.

Tray advertises a no-code solution and it has to be the most brittle part of our entire platform. It’s common for their API to time out for even the most basic things, like listing which integrations a customer has setup (which is never larger than a handful).

Excited to see this isn’t “no-code”

Design at my current place doesn't include loading and error states in their designs so we have to free hand those ourselves.

IMHO, loading states and error states are one of the more important parts of the design since they'll be seen often (for loading) and when the product isn't working for a user (error states).

One thing I miss when using VSCode is the lack of spell checking compared to Sublime or even Vim.

I think a CLI might be nice, but even then typos in code aren't such a big deal IMO. Sometimes they do come up with copy in UI code, but even then, NBD.

So for me, a spell checker in CI sounds like a nice to have, not a necessity.

Helpful explanation. I think a lot of the trouble for me in understanding GADTs is the Haskell syntax used in a lot of examples.

My static typing experience is limited to TypeScript and Rust, so I'm curious what a GADT would look like if they were added to those languages.

I wonder if that's a mypy issue or more that the typeshed types are bugged, since type shed versions also get shipped (used to?) with new type checker versions.

https://github.com/python/typeshed

I'm curious what you mean by "iterating variables have to be predeclared". In my experience mypy's type inference works with bog standard python constructs like a for loop that appends into a list that gets declared before the loop, aka:

  output = []
  for x in range(1):
      output.append(x)
      
  reveal_type(output)
  
  # note: Revealed type is 'builtins.list[builtins.int*]'

One thing I've encounter with pytest fixtures is they have a tendency to balloon in size.

We started out with like 50 fixtures, but now we have a conftest.py file that has `institution_1`, ..., `institution_10`.

My end conclusion is that fixtures are nice for some things, like managing mocks, and clearing the databases after tests, but for data it's better to write some functions to create stuff.

So instead of `def test_something(institution_with_some_flag_b)` you'd write in your test body:

    def test_something() -> None:
        institution = create_institution(some_flag="b")

Also another benefit is you can click into the function whereas fixtures you have to grep.

In my experience it’s been worth the trouble of writing partial type stubs for your project’s dependencies.

And by partial I mean only typing the stuff you end up using, so if you just use one function from some huge, untyped package, just type that one part for now.

The way I see it, you write the stub once, and then the API has less ambiguity and you get type checking.

I run tsc with noEmit passed as a flag. Esbuild is replaces my previous tsc, babel, uglify setup and is much faster.

A nice quality of the `guard` in swift is that you can chain multiple conditions, which is harder to do in rust (maybe with some macros a la if_chain?)

I think your example should instead be:

    someFunction.toString().charAt(10) == 'a'

so you're getting the function's string representation, not its return value

Also I've never even considered that minifiers can break your code.

To be safe it seems you either need to run minification during test & dev or setup some linting to ban features that could break during minification.

I think if you settle for the args being combined into a tuple you could essentially create a tagged union and the type checker should be able to refine off the comparison.

Type would be something like:

    Union[Tuple[Literal[“thing1”], TypeX], Tuple[Literal[“thing2”], TypeY]]

It's been a while since I last ventured into nix with python, but when I last tried it seemed way less user friendly compared to the current python solutions like poetry[1].

With poetry I can `poetry add foo` and `foo` will be added as a dependency and importantly all its dependencies will be locked in the `poetry.lock` file.

With Nix either you write all your definitions from scratch, which feels like maintaining a lock file by hand, or you specify a package like `numpy` in your dependencies that is defined in the nix packages and hope that the next time you update nix packages nothing breaks.

Also if you want a package that isn't in nix packages you have to write the definition yourself, which isn't a big deal if you start a project off with nix and gradually add dependencies as you need them, but if you are trying to migrate your project with 200+ dependencies it feels really tedious.

[1]: https://python-poetry.org/

A nice advantage of having a TextField with a check constraint, instead of a varchar, is that the locks required in Postgres to change the check constraint are less extreme than the ones required to change the length of varchar.

With a check constraint, we can use `NOT VALID` with a separate `VALIDATE` call, while a change to the varchar length requires an `ACCESS EXCLUSIVE` lock.

Alternatively a Protocol can be used instead of Callable

  from typing import Protocol

  class ErrorHandler(Protocol):
      def __call__(self, p0: int, p1: Exception) -> None: ...

  def handler(on_error: ErrorHandler): ...

Sounds like your describing what I like to call a fancy build system

Something like Bazel[0], Buck[1] Pants[2], etc. One of their main features is robust caching of build artifacts, which is helpful for larger projects. But they require some major investment compared to your typical `scripts/build.sh`.

[0]: https://bazel.build [1]: https://buck.build [2]: https://www.pantsbuild.org

Interesting to see more competitors to Heroku popup. Kind of amazing how the big cloud providers still haven't solved this problem.

Heroku still has one of the easiest setups of anyone on the market, and they've just been coasting in recent years. Poor container support, auto-scaling is naive, random routing (see rap genius), no health checks, pricey, etc.

Previously Deis built a Heroku like service on top of Kubernetes, but they got acquired by Microsoft, and the product has since atrophied.

Convox[0] seems similar to Qovery, with the added ability of self-hosting (UI is closed source though).

I think Qovery not having a UI is a deal breaking for many. Heroku's CLI, UI, and API is a killer combo.

[0]: https://convox.com

Have you tried https://jestjs.io/? It doesn't have as crazy of chaining like Mocha and has snapshots which I sometimes miss when using pytest.

Whoops!

For future internet historians, it should have been:

    sum(x % 10 == 0 for x in range(1000))

Never seen that before. Neat how the bool being a subclass of int pokes out in various ways.

A nice side effect is that bools can used with sum:

    sum(x % 10 for x in range(1000))

It's a one time fee and IMHO is totally worth it.

Sublime Text and Sublime Merge are works off art in terms of speed and usability.

Although I tend to use vscode more now for editing, I use Sublime Merge every day at work. Worth every penny.

We have something similar at my current place where every week or two someone presents.

It ends up being the same people presenting and I don’t think it is because people are afraid of public speaking, but instead people don’t care about the talks.

At most 1-2 people (~20 person eng team) will ask a question, engage with the speaker, say thanks, etc. but most people either don’t attend the video call, or do so with video and microphone off for the entire time.

I long for a group of engineers who care about honing their tools, finding better solutions, making things reliable and efficient, etc.

It becomes draining to have the same people present over and over again.

/end rant

Related to HTTP timeouts, I’ve run into database clients without default timeouts. This meant even though the HTTP request was cut off after the timeout, the database request kept on working causing tons of slow database requests to be running on the server.

With Postgres you can use roles to set timeouts, maybe you want a longer timeout for crons, shorter for HTTP endpoints.

Sadly we were using mongo which doesn’t have equivalent functionality. Ended up monkey patching the client library to define a reasonable default timeout.