Kotlin's Future: Layoffs, AI, and Google's Influence

Jake Wharton observed a dramatic reduction in engineering staff at Cash App shortly after his departure, with 70% of engineers laid off. This substantial cut occurred amid a broader industry trend where the implementation of large language models (LLMs) is frequently cited as a justification for corporate downsizing.

Many executives now view AI as a powerful tool for enhancing efficiency and reducing operational costs, particularly in engineering departments. Wharton, however, expresses disagreement with this perspective, arguing that such justifications often mask deeper issues or short-sighted strategic decisions.

The widespread layoffs, particularly those impacting significant portions of a company's technical workforce, raise questions about the true economic drivers and the long-term sustainability of AI-driven workforce reductions. Wharton’s observations suggest a disconnect between executive expectations for AI and the practical realities faced by engineering teams.

He points out that while AI promises efficiency, its adoption as a primary reason for mass layoffs can be problematic, potentially leading to a devaluation of human engineering expertise and a reliance on unproven technologies for critical functions.

This cautious strategy stemmed from the fact that the Android platform had been built on Java for approximately 10 to 12 years, establishing a deeply integrated and stable stack.

Concerns within the Android team focused on the potential risks of replacing a well-understood and stable language infrastructure with a relatively new and less proven one. The long history of Java's use meant extensive existing integrations across the entire stack, making a sudden transition a high-stakes decision.

Google's approach prioritized a thoughtful and non-disruptive transition, ensuring that Kotlin's introduction would not destabilize the Android ecosystem. This involved carefully phased implementation and strategic support for both languages, allowing developers time to adapt and migrate.

This method minimized potential disruptions and allowed for a smoother assimilation of Kotlin, mitigating risks associated with radical changes in a foundational development environment.

The realistic salary range for a senior Kotlin engineer in the United States typically starts at $200,000, often supplemented by an additional amount of equity. This figure represents a competitive base for experienced professionals in the field.

However, the market for Kotlin developers is showing signs of cooling, with companies becoming more cautious in offering exorbitant compensation packages. The previous era of rapidly escalating salaries and generous benefits appears to be moderating as the tech industry recalibrates.

Market risk tolerance for accepting new roles or negotiating compensation packages now varies significantly based on an individual's life stage and personal financial circumstances. Younger developers might be more willing to take risks, while those with more established personal commitments may prioritize stability and guaranteed compensation.

Jake Wharton questions the rationale behind CEOs and upper management dictating specific tools, such as programming languages, for engineers to use in their day-to-day work. He argues that such top-down mandates undermine the expertise of the technical team.

Wharton asserts that engineering tool choices, including language selections, should primarily be driven by engineers who possess an intimate understanding of business requirements and technical complexities. Engineers are best positioned to assess which tools will most effectively meet project goals and maintain long-term system health.

He considers being forced to use particular tools by non-technical leadership a significant red flag within an organization, drawing parallels to recurring layoffs as indicators of broader systemic issues. Such mandates can hinder productivity, stifle innovation, and lead to suboptimal technical solutions.

Jake Wharton frequently experiences dread rather than excitement when software updates are released, observing that new versions often break existing functionality or degrade the user experience. This phenomenon, which he links to the concept of 'enshittification,' describes a systemic decline in product quality.

He explains this trend as an inevitable shift in focus from creating value for users to extracting maximum value for venture capitalists and shareholders. Products, particularly those in the tech sector, tend to transition from prioritizing user experience to emphasizing monetization and financial returns, often at the expense of quality and usability.

Wharton expresses a strong desire for companies that adopt sustainable business models, which do not rely on exploiting users or their data. He seeks organizations committed to long-term value creation for customers, fostering excitement rather than dread with each product iteration.

Jake Wharton identifies geographic location as a significant source of unfair wage gaps, noting that co-workers in different countries performing identical jobs may receive salaries as low as half of what a U.S.-based employee earns. This disparity, he argues, undermines principles of equal pay for equal work.

He criticizes the practice of solely paying "market rates" when those rates prevent employees from sustaining a comfortable lifestyle in their respective regions, despite their contributions being equivalent to higher-paid colleagues elsewhere. This approach, he believes, perpetuates systemic inequities.

Wharton firmly states that discrimination based on factors beyond an individual's control, such as their geographic location, is an absurd and unethical concept in compensation. He advocates for a more equitable global compensation model that values contributions consistently, irrespective of where an engineer resides.

His choice was heavily influenced by a strong alignment between Skylight's values and his own professional principles.

A significant bonus for Wharton was that Skylight's product directly targeted his own demographic: families. This personal connection meant he was effectively a customer of the product, allowing him to bring a unique, user-centric perspective to his work and understand the product's value firsthand.

Furthermore, Skylight's operational model, which involves distributing its own application and bypassing the Google Play Store, resonated with Wharton's critical stance on platform control and third-party dependencies. This independence from major app ecosystems was a key factor in his decision.

The hiring of Kevin Barry, a highly respected figure in the Android community, served as another strong vote of confidence for Wharton, indicating Skylight's commitment to attracting top-tier engineering talent and fostering a robust technical environment.

He believes this firm position encourages others to critically evaluate the underlying implications of AI usage.

He expresses a deep concern that engineers are increasingly offloading critical thinking and problem-solving to AI systems, leading to a potential degradation of human expertise and making them more replaceable. This reliance, he fears, diminishes the core skills that define effective engineering.

Wharton distinguishes between using AI as a "tailwind"—a supplementary tool that enhances existing capabilities—and using it as a "crutch"—an indispensable aid that replaces fundamental understanding. He advocates for approaches that maintain and develop human intellectual capacity rather than diminishing it through over-reliance on AI.

Jake Wharton expresses skepticism about the long-term viability of current AI development, particularly concerning models that are recursively trained on their own generated data. He highlights a certainty that this practice will inevitably lead to a phenomenon known as 'model collapse.'

He refers to various studies and discussions within the AI community that suggest feeding an AI's output back into its training data causes a degradation in the model's quality and performance over time. This self-referential training loop is seen as unsustainable, ultimately leading to a collapse in the model's coherence and utility.

Wharton emphasizes that large language models (LLMs) fundamentally lack genuine reasoning and comprehension abilities, despite their impressive output. Their capacity to generate human-like text does not equate to understanding or true intelligence, which makes recursive training particularly problematic.

This inherent limitation, combined with the feedback loop of self-generated data, points to a structural weakness in current AI methodologies that, according to Wharton, will prove unsustainable in the long run.

Java's recent evolution, marked by the adoption of modern language features such as records and sealed classes, has significantly narrowed the feature gap with Kotlin. This progress means that many of the conveniences once exclusive to Kotlin are now available in Java.

Wharton notes that Java's new language features often appear more thoughtfully integrated, benefiting from a six-month release cycle that allows for cohesive design within the JVM ecosystem. This more deliberate approach can lead to a more polished and consistent language experience.

In contrast, Kotlin, when targeting the JVM, has often had to "shim" new features into an existing architecture, which can sometimes result in less elegant implementations. Kotlin's need to maintain compatibility with older JVM bytecode also introduces constraints that Java, with its direct control over the JVM, can bypass.

To maintain its relevance and competitive edge, Kotlin must continue to innovate and integrate modern features effectively, ensuring its distinct advantages remain compelling for developers, especially as Java continues its rapid evolution.

Jake Wharton finds many of Rust's core design decisions, particularly concerning its type system, remarkably intuitive, stating that they align closely with how his brain naturally approaches problem-solving. This includes its robust error handling mechanisms.

Rust's type system forces developers to explicitly confront potential failure states, making error handling an integral part of the development process rather than an afterthought. This contrasts with languages where errors might be implicitly ignored or handled inconsistently.

The language's unique concepts of ownership and borrowing are highly effective in preventing common programming pitfalls such as memory leaks and resource management issues. While these concepts can present a steep learning curve initially, Wharton argues that they represent a powerful and intuitive model for managing complex systems.

Despite the initial challenge, the clarity and safety provided by Rust's design decisions offer a new standard for reliability and performance, guiding developers toward more robust and secure codebases.

Rust benefits from a powerful library ecosystem specifically tailored for hardware interaction, providing developers with the tools needed to build efficient and reliable embedded systems. This rich support simplifies complex tasks often associated with low-level programming.

Wharton also notes that Rust's asynchronous programming model maps cleanly to the event-driven nature of hardware interactions, making it an ideal choice for managing concurrent operations in embedded contexts. This alignment enhances code clarity and performance in resource-constrained environments.

He uses Rust as a way to remain productive and engaged with programming outside of his professional work, leveraging its strengths for side projects that allow him to explore new technical challenges and maintain his skills.

Jake Wharton criticizes Flutter for disregarding native platform UI conventions, explaining that Flutter essentially creates its own rendering stack, similar to how a video game engine operates. This involves drawing every pixel on the screen independently of the underlying operating system's UI components.

In contrast, Kotlin Multiplatform (KMP) compiles to native code (JVM for Android, LLVM for iOS, and JavaScript for web) within each respective ecosystem. This allows KMP to integrate more closely with native platform UI elements, rather than rendering a custom UI that might deviate from user expectations.

Wharton argues that Flutter's custom rendering approach can lead to what he calls "foreign body" issues, where applications might not feel truly native or perform as smoothly as those built with native UI toolkits. This can manifest as subtle inconsistencies in scrolling, animations, or input responsiveness.

KMP avoids these performance and aesthetic discrepancies by leveraging the native capabilities of each platform, aiming for an experience that is indistinguishable from fully native applications. This approach prioritizes adherence to platform guidelines and user expectations for consistency.

His argument centers on the user's interaction patterns, noting that users primarily move between different applications within a single operating system, not across various OS platforms.

This constant interaction within a specific OS means that consistency across applications on that platform is paramount for user intuition and comfort. A native UI ensures that elements, gestures, and behaviors are familiar and predictable, reducing cognitive load and improving usability.

While sharing business logic across platforms is highly desirable for development efficiency, Wharton stresses that the user interface layer should always respect local conventions and design guidelines. This approach delivers a more integrated and satisfying experience tailored to each platform's unique ecosystem.

Ignoring native UI standards can lead to a disjointed user experience, even if the underlying business logic is identical. For Wharton, the perceived quality and user satisfaction derived from a truly native UI outweigh the development conveniences of entirely cross-platform rendering solutions.

He recalls that competition in the browser market was initially beneficial for Chrome's rise, as it pushed for innovation and better performance. However, its current dominance has shifted the dynamic, raising concerns about its ability to dictate web standards and developer practices.

Wharton suggests that Chrome's market position now allows it to "strong-arm" the ecosystem rather than participating in a more collaborative and healthy manner. This power imbalance can stifle innovation from other browser vendors and lead to a less diverse web.

Due to these ethical considerations regarding browser competition and market power, Jake expresses a preference for Firefox, which he views as a more ethically aligned choice in maintaining an open and competitive web environment.

This initial focus set the stage for later challenges.

The "churn" that developers frequently experience with Gradle, characterized by complex configurations and debugging difficulties, is seen as the cost of retrofitting correctness and improving performance after the initial design choices. This ongoing effort can lead to a less stable and predictable build system.

Wharton contrasts Gradle with build systems like Bazel, which prioritize performance and correctness from the outset, often at the expense of user experience. Bazel's steep learning curve is tolerated because its core design guarantees a high degree of build integrity and speed.

He suggests that while Gradle has made significant strides in improving its foundational aspects, its historical emphasis on developer-friendly syntax initially created a technical debt that continues to impact its usability and reliability for many users.

Jake Wharton emphasizes that there are distinct programming languages for valid reasons, and exploring them prevents developers from becoming entrenched in a single linguistic paradigm. This exposure broadens their understanding of software design.

Engaging with different languages allows developers to observe the diverse choices made by language designers and understand the underlying rationale behind those decisions. This insight can then be applied back to the developer's primary language, improving their problem-solving approaches.

Learning multiple languages exposes developers to different design trade-offs and programming paradigms, such as functional, object-oriented, or concurrent programming. This variety enhances their adaptability and problem-solving toolkit.

This cross-pollination of concepts, including advanced topics like ownership and memory management found in languages like Rust, helps developers recognize patterns from other ecosystems. Such knowledge can be invaluable for finding innovative solutions and avoiding common pitfalls in any language.

Kotlin benefited significantly from its deep integration with the established Java open-source culture, which provided a robust foundation and a large community for collaboration. This allowed Kotlin to quickly gain traction and foster a vibrant ecosystem.

In contrast, Swift initially faced challenges due to a more closed-off, Apple-centric development model, which limited community contributions and slowed its adoption in broader open-source contexts. The perception was often that Swift was a "golden thing" handed down by Apple developers annually.

JetBrains, the creator of Kotlin, prioritized open-source practices from the very beginning, encouraging community involvement and transparent development. This commitment to openness fostered a collaborative environment that resonated with developers.

The initial management and cultural approach of a language's development significantly influence how its community culture perpetuates itself, with Kotlin's early openness leading to a more engaged and self-sustaining open-source ecosystem compared to Swift's more controlled origins.

Jake Wharton argues that a core problem in software development lies in a misperception of what it truly means to use an open-source library. He stresses that developers must feel a direct sense of responsibility for the dependencies they incorporate into their projects.

He posits that developers should treat open-source code as if they had written it themselves, understanding its intricacies and potential vulnerabilities. This perspective encourages a more thorough vetting process and ongoing vigilance.

To avoid what he terms the "dependency trap," users must be proactive in monitoring, contributing to, and participating in the health of their open-source dependencies. This includes staying updated on changes, reporting bugs, and engaging with the community.

Wharton considers contributing back to open-source projects a standard practice for ensuring the long-term sustainability and reliability of the entire open-source ecosystem. This reciprocal relationship strengthens both individual projects and the broader community.

Jake Wharton points out the difficulty in quantifying the benefits derived from open-source contributions in a way that easily translates into standard business metrics or spreadsheet analyses. The value often extends beyond direct, measurable returns.

Maintaining open-source projects, even those with significant community involvement, requires non-trivial additional work from companies. This includes code reviews, community management, and documentation, which are often not fully captured in traditional cost-benefit analyses.

Wharton suggests that the quality of a company's open-source contributions and its engagement with the community serve as a key indicator of its overall engineering culture. A strong commitment to open source reflects a dedication to technical excellence and collaboration.

The benefits of corporate investment in open source include shared improvements across the industry, enhanced long-term project stability, and the ability to attract top engineering talent who value open collaboration. These indirect benefits contribute significantly to a company's reputation and innovation capacity.

He feels the choices regarding what features are included or excluded resonate with his preferences.

He recounts an instance where he directly influenced a Kotlin feature, specifically the 'exhaustive when' construct, by providing a compiler plugin example during his time at Square. This demonstrates the tangible impact individual developers can have on a language's direction.

Wharton strongly encourages developers to actively participate in language proposals and discussions to influence the future direction of the tools they use. He believes that community engagement is crucial for guiding language evolution in a way that benefits its users.

Language evolution requires a delicate balance between introducing new, powerful features and ensuring that programmers maintain responsibility for understanding and correctly utilizing those features. This balance is key to creating a robust and developer-friendly language.

This structure ensures broader community input and prevents unilateral decisions.

Google's significant adoption of Kotlin for Android development was predicated on this very principle: avoiding the risks associated with a proprietary language owned by a single vendor. The Foundation ensures that no one party can make decisions that would negatively impact major stakeholders like Google.

The Foundation's structure is designed to promote effective governance by listening to and integrating community feedback alongside organizational management. This multi-stakeholder approach aims to balance the interests of various contributors and users.

This collaborative governance model is essential for fostering trust and ensuring the long-term stability and growth of the Kotlin ecosystem, preventing any single entity from wielding disproportionate control over the language's future direction.