TylerJewell
1. We were able to execute complete, unattended rewrites of existing systems that pass the original's unit and integration tests.
2. Low effort models were more efficient than high effort models.
3. The delivery harness and its structure had a bigger impact on consistency than model capability.
4. We saw a LOC or performance improvement on 57 of 65 ports.
Anthropic hasn't changed their licensing, just enforcing what the licensing always required by closing a loophole.
Business models aside - what is interesting is whether the agent :: model relationship requires a proprietary context and language such that without that mutual interaction, will the coding accuracy and safety be somehow degraded? Or, will it be possible for agentic frameworks to plug and play with models that will generate similar outcomes.
So far, we tend to see the former is needed --- that there are improvements that can be had when the agentic framework and model language understanding are optimized to their unique properties. Not sure how long this distinction will matter, though.
This level of throughput is achieved by including memory database within the agentic process and then the clustering system automatically shards and balances memory data across nodes with end user routing built in. Combined with non-blocking ML invocations with back pressure you get the balance for performance.
We are a pure play app dev platform and that gets to the heart of why the business model is different. I'd argue that we are very motivated to make sure that customers are successful with app dev as that is our bottom line where our rivals are financially incentives by infrastructure sales, not app dev outcomes.
We did a long podcast and a couple blogs that offered transparency to the rationale on why we moved from Apache to BSL, which still downgrades to Apache after 36 months. See Emily Omier for the specifics.
It came down to survival. The company faced a bankruptcy event as customers were using the software without contributions and after exhausting alternatives needed to change the license model to create a more sustainable approach.
The consequence of this choice was that there was less adoption from OSS and ISVs who need a flexible licensing model for embedding and redistribution. It also encouraged the Pekko fork which is a branch that is 2.5 years old. And that branch helped older projects and OSS distributions to maintain their position without financial consequences.
It is not cheap to maintain Akka, and after 15 years we have turned a profit, albeit barely. We are growing, finally, and have a prosperous future and most of our spend goes into development. It did allow us to create Akka 3, which is a simpler model for devs within enterprises mixed with a consumption based model that should be significantly cheaper than the traditional libraries, and cheaper than the cost to adopt most any other framework. We can debate the merits of different business models but we couldn't have maintained the 50 CVE fixes and create a modern version of Akka if we hadn't taken this step.
We need a better strategy on how to appeal to the OSS community once more. To appeal to startups and academics, we have free commercial licenses and subscriptions, which nearly 200 accounts have signed up in the last 18 months.
Show HN: Akka 3 – platform to build and run responsive apps
Akka was originally launched in 2009 by Jonas Boner from Sweden as a toolkit to make it simpler to program concurrent apps on multi-core systems. It grew over the years into a set of libraries for building distributed systems with persistence, clustering, integration, and protocol extensions.Akka has been downloaded more than 1 billion times and powers 100,000 apps. Many of the apps that you...
The tracking methodology buckets companies by the primary product they advertise. Withcoherence is in a different category that has a broader platform definition.
There are companies like gitlab and Codegiant that also have remote dev envs as features of the broader product line.
There are increasingly limited differentiation between various vendors. The biggest improvement areas needed now are simpler configuration, faster boot times for complex projects (pre-built code, cached artifacts, IDE plug-ins configured).
Cloud9 IDE Appvia Coder CodeSandbox CodeZero.io DevSpace Desktop Tilt Env0 Floxdev Gitpod Itopia Spaces LocalStack MetalBear Azure DevTest Labs Visual Studio Codespaces Nimbus Okteto SourcePro Porter Codeready Workspaces Repl.it Stackblitz Strong.network Subpoint Solutions Tangram.dev
Complexity, Automation and a Future of Autonomous Development
I get inspired by reviewing the following things: 1. Child mortality rate over time: https://ourworldindata.org/child-mortality?country=
2. DeepMind’s protein-folding breakthrough signals a promising decade for the science of proteomics. Most directly, being able to predict protein shapes will enable us to discover drugs more rapidly.
3. The cost to produce PV modules: https://ourworldindata.org/grapher/solar-pv-prices
4. Advancement of geothermal as a potential energy source. The next generation of the industry, however, is a bunch of scrappy startups manned by folks leaving the oil and gas industry who think with today’s technology they can crack 3.5¢/kWh without being confined to volcanic regions.
5. Space exploration. The Space Shuttle entered service in 1981 and launched successfully 134 times. The payload cost to low-Earth orbit (LEO) was $65,400/kg. Today’s Falcon 9 is at $2,600/kg.
6. The improvement in adult literacy rates over time. So much more to do here, but a literate population is one that is more likely to contribute to our global productivity and success. https://ourworldindata.org/grapher/literacy-rate-adults?tab=...
7. Quantum computing experiments and trails are doubling the number of qubits every couple of years right now. Quantum computing will cause a re-imagining of security and cryptography of digital assets if it becomes production grade. https://www.bbc.com/news/science-environment-59320073
I am sure there are many other examples. Even though I am an enterprise software guy working at Dell, the progress we made in the areas of technology that we get to work in have some contributing impact to all of these trends.
Is it fair to think of IDEs that include language-specific refactoring capabilities as a providing a developer abstraction over AST editing?
What is a dApp? https://twitter.com/TylerJewell/status/1474468145704280064?s...
What are the investment opptys for an infra investor? https://twitter.com/TylerJewell/status/1474468607295832069?s...
What are various people saying about Web3? https://twitter.com/TylerJewell/status/1474468866101157889?s...
Why make the pull request such a formality? The process of writing the code, developers can have active discussions with other key members of the team from within their IDE. Those conversations are then captured as essential context to facilitate the PR review itself.
So many ways and innovative companies like Axolo which are finding ways to remove barriers to better information sharing and context.
Cloud IDEs provide value for specific portions of the market: 1. Training 2. Remote contractors in secure environments 3. Support 4. Classrooms 5. Vendors who want embedded dev envs in other products 6. Open source clones / snippet evaluations
Codenvy was strong in the embedded dev envs for other products. When you look at the various vendors that have emerged like Coder, Repl.IT, among others, they have a tendency to specialize in one of these areas.
That is quite different from the first generation cloud IDEs which tried to compete with classic desktop IDEs.
Studying for the license felt like I was back in university. So I treated it as a goal, studying ground materials consistently every day while blocking out 2 lessons every week. It was effectively a job on top of the work I was already doing.
Most shocking was how much longer it took me to absorb the materials vs. studying equivalently complicated topics 25 years ago. Not to understand what they were, but to be able to have instant recall with precision.
The landscape contains 800 companies across 22 segments that publish 1000 products which generate $40B in revenues.
Today, I am publishing some of the data and analysis.
It includes products from amazing companies like JFrog, Atlassian, HashiCorp, CloudBees, Red Hat, Snyk, Microsoft, JetBrains, and VMware.
I am hopeful that we can get the community to engage by identifying missing companies, help refine segment definitions, and to bring better awareness on the the influence and reach of developers.
I undertook this effort for a few reasons: 1. Developer businesses are still misunderstood by investors and business professionals 2. To bring clarity on the size and growth of different sub-segments of developers 3. To identify long-lived trends in developer businesses and products 4. To bring awareness to my efforts as a technologist and investor, helping to identify interesting companies I may get to connect or collaborate with.
A sample of what's included: ️Developer runtimes generate 2.5x more than pre-prod ️Early segment leaders usually become dominant ️1 trillion programmable endpoints drives need for lifecycle automation and operations to "Shift Left" ️$5M ARR is the threshold between startup and going concern ️It takes a mega vendor to straddle pre-production and production ️Substantial application server businesses emerge (category creation) around programming paradigms ️Private companies have raised a staggering $50B in venture capital ... though deliver questionable capital efficiency ️Software supply chain industrialization will propel the industry towards autonomous software development
Developer-Led Landscape: 800 Companies, 1000 Products, $40B in Revenues
It was a challenging exercise and so can relate to Rust's community efforts to the redesign. I wanted to offer some perspectives of what Rust's challenges must be.
1. It is really hard to capture the value proposition for a programming language. While working through Ballerina, there is a hard balance between a) describing the language design, b) explaining why language elements are valuable, c) describe the key types of programming workloads that most benefit from your language philosophy, d) direct those interested to learn more to the right information, efficiently.
2. As such, whomever is leading the Rust site evolution over the years shows a real touch and depth for messaging. It takes a lot of insight and careful observation to your community over an extended period of time to tease out which elements are fundamentally what is driving your audience. Having said this, I have a tendency to feel that the messaging in the latest version might be creating a messaging abstraction trying to appeal to a wider developer base vs. the messaging in the current site which is more strongly appealing to existing system developers. Is this a conscious choice of the Rust team?
3. The rust team has figured out, through years of promotion, that the first (and last) question language teams get is always about "who's using the language? how big is the community?". The hardest part about birthing a language is the chicken and egg problem - someone needs to be the first big production app. Dogfooding is really the only way. Rust takes this head on.
I am not a big design person, so don't have an opinion about whether the minimalistic design is better than the new flowing design. A lot of the design influences for ballerina.io came from Go and Rust lang's web site - we are fans! So, I guess you could say that we prefer the minimalism concept.
I have packaged up my observations on the acquisition and the impact to open source in this blog post.
https://medium.com/@tylerjewell/ibm-acquires-red-hat-what-th...