I’ve been hacking on something in this vein and would love your feedback.
What if you could reuse your CI env by using Github Actions as your sandbox. You can reuse the caching, any oidc based roles and self host via runs-on.com for cost and performance. We expose a claude code web experience of interactive low latency chat. I have a working prototype I’m happy to share if you think it would be interesting.
This is very convenient but has limitations. GitHub actions are not built to resume state (conversations in our case) and handle multi player experiences.
However reusing the GitHub workflows out of the box feels really nice
Is this telemetry enabled internally at Google? Enabling it internally would be an interesting litmus test of what is required to make it privacy/security compliant.
Most code at Google is built in the cloud (https://bazel.build/remote/rbe), with the compiler running in a sandbox that prohibits network access (https://bazel.build/docs/sandboxing). The language server works similarly. So as a technical matter, this kind of telemetry can't work in that environment.
In principle, the Go telemetry could instead be hooked up to a build-system-specific metric reporting system, and the results from that could then be shared with the Go team. A company that uses a Google-style build system could do that kind of integration work if they wanted to contribute their data. But this doesn't make sense for the scenario where the Go compiler is running on some individual dev's machine; there, you want it to upload the data to Google's servers itself.
I mean that that's what's required in order for the telemetry to useful enough to be worth doing at all. If you're against telemetry entirely then of course this isn't going to satisfy you, but then there's no point arguing over the details of how it should work.
Also a lot of CI is "start a VM/container, run the build, save the artefacts, wipe everything", whereas the telemetry data is only uploaded every however often; most CI systems wouldn't collect data for long enough to actually send it before getting wiped anyway.
1. Can you share information about the specific hardware/CPUs used and where you are hosted?
2. Running untrusted workloads is a huge security challenge. Can you share the technology you are using for isolation and how you have approached mitigation of security threats?
This new release seems to continue the trend of new AWS hardware generations increasing performance while also increasing cost, as opposed to the prior trend of increased performance and decreased cost.
The "Flex" variants appear to be pushing the "burstable" machine types (T4,T3,etc) to be positioned for use in production workloads.
Has anyone migrated a large code base between MyPy and Pyright? In particular would love to hear about experiences with Django.
Mypy’s performance and the join based type merging are quite limiting. At the same time, the ecosystem support around MyPy seems strong.
Django is one library that has some apis that are beyond type system and likely difficult to ever fully describe in type system. Some of this it handles with a custom mypy plugin to overrule/extend some type rules. No other python type checker I'm aware of supports plugins so this is one place mypy will have an advantage. Usually when behavior is too dynamic to be described well the stubs will fallback to Any leaving some typing holes for other type checkers.
At same time this only affects a subset of Django behavior and I have used pyright with a Django codebase and it mostly worked well. The more you use very dynamic features of Django the more this matters.
One note for both is you do want to tune configuration settings. Pyright basic is fairly easy to satisfy, pyright strict is too hard for most codebases. Similarly mypy defaults are too lenient, but mypy strict is pretty hard (even mypy doesn't use strict to check itself). I roughly go for strict for both and then remove ~5 hardest rules and call that good enough. Strictest rules pretty much require all of your dependencies to be well typed/stubbed.
Yes. I moved a very large/mature Django project from use of MyPy to use of Pyright. My experience was that pyright flagged a bunch of new conditions that MyPy seemed to have missed. The cost was that I needed to add (many!) explicit annotations or casts in places the Django MyPy plug-in would have just “known” about the types, for instance in foreign key relations in Models.
In general, we were very happy with the result and never looked back. Correctness and perf were both notably improved. (That pyright is also part of pylance, Microsoft’s proprietary LSP implementation for Python that plays well with VSCode, was an advantage for this particular team.)
This was about a year and a half ago so the experience may differ; both pyright and mypy + its plugins have gotten more capable and mature over time.
Is anyone else using MyPyC in production and can share their experience?
Did you attempt the compile it all approach, or incrementally add?
What do compile times look like at scale?
Would love to buy you a coffee and hear about your experience and the challenges and benefits.
It reads your cost and usage report + AWS APIs and offers RI options for you to purchase or ignore.
What Eco is lacking is being a reseller like usage.ai and buying your unused RIs
We use cast.ai and it certainly has saved us a LOT of money. I unfortunately am not on the implementation / devops side of this, but it has been worth using, or can speak to exact figures, but it was definitely a significant difference in expenditures.
