Yeah, hard disagree on that one, based on recent surveys, 80-90% of developers globally use IDEs over CLIs for their day-to-day work.
I was pretty worried about Cursor's business until they launched their Composer 1 model, which is fine-tuned to work amazingly well in their IDE. It's significantly faster than using any other model, and it's clearly fine-tuned for the type of work people use Cursor for. They are also clearly charging a premium for it and making a healthy margin on it, but for how fast + good it's totally worth it.
Composer 1 + now eventually creating an AI native version of GitHub with Graphite, that's a serious business, with a much clearer picture to me how Cursor gets to serious profitability vs the AI labs.
DevCycle | Senior/Staff Full Stack | Full-time | Toronto (Hybrid / Remote) | $150k - $180k | https://devcycle.com
We are looking for a Senior-level engineer to help us build out and scale DevCycle. We are a small team that's been building in the feature flagging / AB testing space for a while (from Taplytics YC W14), supporting open standards like OpenFeature. We run a large distributed system serving trillions of monthly evaluations, relying on technologies like Cloudflare Workers, Next.js, Nest.js, WASM, etc.
Also, once you are on Enterprise, they will not bug/charge you for contracted overages very often (like once a year) and will forgive significant overages if you resolve them quickly, in my experience.
Actually, M4 is reportedly on a more cost-efficient TSMC N3E node, where Apple was apparently the only customer on the more expensive TSMC N3B node; I'd expect Apple to move away from M3 to M4 very quickly for all their products.
Owner of the purposefully controversial opinion here :) Looks like its proven to be very controversial, which was the stated goal of the podcast segment :)
For context, I had just returned from KubeCon + CloudNativeCon EU in Amsterdam. I had a chance to talk to many of the great folks pushing the WASM ecosystem forward, and there certainly seemed to be a large amount of momentum behind using WASM in the server space and at the edge. I'd had a great time learning from the folks at various open-source projects / companies pushing WASM forward:
At DevCycle we are using WASM to help share core Feature Flag decisioning code across our Cloudflare Worker APIs and our server SDKs for local decisioning. We've learned a bunch about compatibility / optimizing performance / limitations that I'm happy to chat about in more detail. But we are generally excited for the future of WASM, especially for the new features coming: Component Model / Threading / Garbage Collection changes / Networking.
If you are looking for how to use WASM Components to replace container-based runtimes, look at the companies linked above.
Happy to provide more details on this. In most cases, our server SDKs use a common WASM library to make all user bucketing and segmentation decisions locally. We have been impressed with the performance we've achieved with WASM. It allows us to share our most critical non-trivial amount of decision-making code, and it lets us share it between our Edge APIs and Server SDKs. So the same WASM code making decisions locally in our server SDKs is also making decisions at the edge for our APIs powering our client-side SDKs and public APIs.
We have stuck to the Bytecode alliance-supported Wasmtime runtimes that we highly recommend for anyone going down a similar path.
There have been cases with highly parallel environments where we needed to support micro-second level optimizations for our GO SDK, where we ended up building a native version of our bucketing logic. We hope that WASMs' upcoming threading and memory management improvements will make this use case supportable without needing native code. But for our higher-level language SDKs like NodeJS / Python / Ruby / PHP we've generally seen as good or better execution performance from WASM.
What desktop environment are you looking to support? We have customers using our iOS SDK in MacOS (we need to find a better name for our Apple platforms SDK that supports iOS / iPadOS / MacOS / WatchOS / tvOS). Our React SDK works with electron apps, and we have on our roadmap to investigate client SDK support for our .NET SDK.
We certainly see workflows where defining everything as code can be powerful. As we've been chatting about this internally today, we have ideas of how you could define all your features / audiences / variables as code and only deploy changes using a Terraform interface.
I feel like, ultimately, this overly limits the reach of feature flags within an organization; it makes it more difficult for most engineers who are not comfortable with Terraform to deploy their features; it limits the ability of product / marketing / project managers / QA from; scheduling releases, configuring experiments, testing features, modifying audiences, etc.
Modifying configurations certainly can cause production issues, which is why we have built tools like our variable schemas and strong typings for our variables to limit the value changes to only known values. With our CI / CLI / IDE integrations, we make it known what values variables can be set to, when variables are added and removed, and when variables enabled in production are modified by PRs. This is all in addition to existing permissions / change logs / rollback functionality we are improving on. One of our core responsibilities is to make changing Feature Flag values as safe as possible. We know that flags can quickly become tech debt, so we also preach that feature flags should be as easy to remove from your code as they are to add to your code.
A fully featured feature management platform should be with you from your IDE / CLI, Code Review / CI, Deployment Pipelines / Alerting and Monitoring, and integrated with your Project Management and Product Analytics. It should be visible to your team throughout their workflows what features are enabled across all your environments.
You can use a git-based workflow for feature flags, that's likely how most teams will start using flags in their code with environment variables and infrastructure state. However, most deployment pipelines in the wild are very slow and owned by engineering, limiting the value of doing git-based state for your Feature Flags.
I've seen that disconnecting the deployment of code from releasing of features can be transformative in various ways that fit better with an API-based model for Feature Flags:
- Many flags / remote config changes in production environments are made by non-developer members of a team.
- Coordinating releases across multiple platforms that have different deployment cycles. For example, deploying a new feature to Mobile + Web + APIs simultaneously.
- Enabling / disabling flags in real-time across your stack to respond to incidents.
- Support / Sales teams using Flags to gate features for customers.
- Remote config to populate data for UIs, to act as a CDN for content.
- Rolling out infrastructure changes, being able to roll back changes instantly without another deployment.
(And for context: our Feature Flag decisioning is done locally for our local bucketing server SDKs)
Really interesting take on your experience with experimentation / feature flags and wanting it to be more stateful in code. I assume that follows the more Terraform-like infrastructure as code approach, which certainly makes sense to rollout infrastructure changes. We have a V1 of a Terraform provider where we hope to enable more control through terraform to manage infrastructure changes directly, but you are correct that has yet to be our core focus. Another way we hope to expose that state outside of our UI is building out a great CLI, which we are actively working on.
Our primary usecase has been working with product development teams who have adopted Feature Flags as part of their workflows, using DevCycle to help them deploy features faster / safer to their end users, even deploying continuously as we do. Generally, customers integrate DevCycle into their Websites / Mobile Apps + API servers to control those feature deployments. We have had a couple of customers use us at the infrastructure layer. One of the best use cases I've seen is in a proxy service controlling the rollout of a new infrastructure stack. I'd love to dig into this use-case deeper and see how we can better support it in the future, "Ops" flags are one of the flag types we are looking to support.
I would say that for customers looking to disconnect the deployment of code from the release of features, our approach where you can "release" features at any time has many advantages over "git-ops" style configurations. But certainly, for Ops use-cases where you are controlling infrastructure changes, we are believers in "git-ops" and use it ourselves. The challenge comes with how to connect those two deployment styles effectively.
(DevCycle Co-Founder & CTO here) The truth of the Feature Flagging market is the vast majority of engineering teams aren't using a third-party tool for Feature Flagging. Most teams are using an internal system (Environment Variables, Database flags, S3 files ect.) or not doing any feature flagging. The potential for the Feature Flagging market is as large as any other developer tools market, and the challenge is to build a product with a better developer experience that encourages the adoption of feature flags and integrates with team's workflows.
We've been in the A/B + Feature flagging space for about ten years with our visual A/B testing-focused product Taplytics (W14), so I'd say we have lots of experience running Feature Flags + A/B tests at scale. We've learned a lot from our customers over the years and were excited to build DevCycle as a green-field project from those lessons. If you are interested, try it out and we are always open to direct feedback.
But Stocks and Currencies aren't technically a digital good, they are partial ownership of a company or a hard currency. A NFT is exactly the definition of a digital only good, seeing as how a large number of NFT use-cases are to replace / make portable in-app goods sold in online games / mobile apps, which all currently require IAP fees to purchase on mobile. So this is just Apple applying the same rules to NFTs that apply to purchasing items in mobile games.
Apple was never going to allow the blockchain to remove their 30% cut on these purely digital items, as much as crypto folks preached that the blockchain would remove us from the shackles of App Store IAP payments.
Roku and Google (Chromecast) have always been subsidizing their hardware. Their business is: selling your data, showing you ads, and selling you subscriptions, it was a race to the bottom to get on as may TVs as possible. Which has turned into a really solid business for Roku. But it also means that Roku's business interests will conflict with what's best for their consumers, updating their devices to support AV1, fighting with streaming partners to collect more revenue, and selling their customer's data.
If you want to see what the real cost of these devices with margin would be, look at the comparatively ridiculously priced new AppleTVs.
I get all the doom and gloom about this announcement, but it's exactly what I would be doing if I ran Stadia. Don't waste money trying to build first-party games when you don't have scale, spend all your money on scaling. Specifically:
- Spend budget on getting more AAA titles released on Stadia on launch day. (like they did with Cyberpunk)
- Spend budget giving huge discounts on AAA titles to attract more users.
- Spend the money to get integrated into every Smart TV platform (Roku, Google TV, LG Web OS, Tizen, Apple TV, ect.). TV Boxes should include a Stadia controller in their box and a few months free.
- Advertise that you can play AAA console games on the TV / Streaming box you already own.
We've been working with an amazing group of Doctors and Volunteers for the past week to prototype and produce a flat-packable plastic box to protect medical workers while intubating COVID-19 patients.
We are starting to mass-produce these boxes and would like to get them out to as many Hospitals as possible.
Thanks to Darrell and TechCrunch for covering the effort so quickly!
A lot more of those things work than you might expect. I was able to get a very large node app working on their ARM instances very quickly... Docker support is also there from as far I know.
I was pretty worried about Cursor's business until they launched their Composer 1 model, which is fine-tuned to work amazingly well in their IDE. It's significantly faster than using any other model, and it's clearly fine-tuned for the type of work people use Cursor for. They are also clearly charging a premium for it and making a healthy margin on it, but for how fast + good it's totally worth it.
Composer 1 + now eventually creating an AI native version of GitHub with Graphite, that's a serious business, with a much clearer picture to me how Cursor gets to serious profitability vs the AI labs.