DaveParkCity

I'm David Jeske, the ex-Google acquiree who served as technical architect and engineering director for orkut.com (among other projects) from shortly after the Brazil popularity explosion through the service decline.

I have a few key points to add to this discussion (to the best of my recollection):

1. orkut.com was not acquired. It was developed in-house, the initial version almost entirely written by Orkut Büyükkökten as a 20% time project. It was written in C# .NET as that was what he was most familiar with and efficient in. The actual product launch was championed internally by Marissa Mayer, and encouraged as an experiement in-part because of the external pressure for Google to do "something" in social networking.

2. We believe a huge part of why it became popular in Brazil, was becuase the homepage contained a ranking of users by country and Brazil's national competitive spirit. Brazil made up the largest initial seed network, and once they were #1 on the leaderboards, it became a major viral spread factor in Brazil to "stay on top" of the leaderboard. It was unfortuantly much later in the service that we realized a good portion of why it remained popular only in Brazil was because the service tended to surface the largest sources of activity to users, which meant most users saw significant amounts of Portuguese content. Once we segtregated the service by language, we saw it experience it's second cultural explosion in India.

3. Once we kept up with performance demand on the service, orkut.com fairly quickly grew to serve more daily pages than Google.com websearch (though obviously it was much less complicated as a service, and much less profitable!) However, over time the service became increasingly dominated by abusive usage such as adult images and fake user spamming. orkut.com was always a very small team within Google, as I recall at it's height we had only around 8 engineers on the project as this was very far from Google's core focus at the time. The service ultimately curtailed in popularity as Facebook continued to win markets, including India and Brazil.

4. I believe there was very little connection between orkut.com decline and Google+. By the time Google+ was launched in June 2011, orkut.com was losing ground to Facebook even in Brazil. Facebook overtook orkut.com in Brazil in December 2011, and orkut.com remained online until September 2014, three years after Google+ was launched.

For those curious about technical details:

A. When I became involved in the project, it was because the live service was serving mostly 400 errors and keeling over dead. At the time it was running on Windows and MS-SQL and .NET, the only project of it's kind inside Linux-focused Google. Most of my background is service scalability archicture, so I was asked to get involved to "fix it", I took the team of 5 mostly junior engineers and led the architecture changes to get it serving pages quickly and stop the errors. As I recall, my code-red to fixed the key performance issues took only about a week, after which the massive increase to page performance led to a massive increase in poplarity, causing orkut to shockingly eclipse Google websearch in page views per day not long after.

B. We initially kept the service on .NET technology, both as an experiement within Google, and because I strongly feel the dotnet CLR design (largely due to parametric instantiation and their open-standard model) is the best virtual machine and runtime of it's kind. However, running Windows machines within Google was "not at all straightforward", and it was problematic running on closed source dotnet of the era because we ran into several Microsoft dotnet runtime bugs at scale and had no ability to fix them. We transitioned to using the Mono dotnet runtime on Linux, which was ironically more reliable (and fixable!) and significantly less performant that the Microsoft dotnet runtime for our needs. Eventually the service was transitioned to a Java front-end and C++ backends.

C. Orkut.com images was the first example of Bigtable serving production traffic.

D. We transitioned presentation layer from ASP.NET to Clearsilver templating, developed at my startup Neotonic.com by Brandon Long, and used inside Google for Gmail and other projects. This was for performance, reliability, and to enable the cross platform and cross-language transitions from C# to Java and C++. (Clearsilver was heavily inspired by CS/HDF templating, designed at onelist.com by Scott Shambarger and Ethan Khan) Clearsilver was an unfair weapon in the server-side rendered mostly-static HTML era.

orkut.com is dead, long live orkut.com!

While the picture painted here is viceral... I think the reality is closer to this..

Before AI, most big software was desgined and originally writen by a few key (founder-esq) architects. But they can only add functionality at human speed, so the team grows, and the quality of engineer drops as the functionality footprint grows. Eventually the functionality is much bigger, but most of it was written by a much lower quality engineer, and thus the code (even if functionally correct) is less efficient and less clean, and the big refactors a talented architect would have done never happened, so it just got bigger and bigger and more unweildy and bug prone and inflexible - until some new talented architects see the waste and build a startup to displace it.

With AI, big software can be entirely written by 1-3 people, plus alot of agent usage. Which means it can be refactored more, and the design kept cleaner. But this only happens if those senior architects are actually paying attention and controlling the design. If the agents are heavily automated and subtasaking and controlling the design, then nothing much changed, because the agents themselves are no better than the "stackoverflow engineer".

I think todays LLMs have a very non-unintuive effect on the information worker job market.

LLM models make "deisgn taste" both in product design, and software achitecture massively more valuable, becuase they massively reduce the cost of everything else, while doing comparatively little for product-design or software-architecture-design.

They can make a pretty button, sure. They can implement a clean version of an algorithm from a research paper. But they can't (as of yet) decide what software to build, why you should build it, what parts of the software to build for flexibility in the future vs practicality now. What algorithms will be the best fit for the real world needs, none of it.

And what they do in those areas is worse than not-knowing. They confidently expound garbage. Absolute drivel. And I laugh. As someone who is a lifelong programmer and entrepreneur, selling software when i was in high-school, selling a company to Google when I was 27 years old, and currently collaborating with AI like a madman to produce lots of useful software, I'm here to say that 2-4-8x productivity is not good, it's just the start. And the next tier happens when you have someone better at software development than the AI keeping it in check, micromanaging it if you will.

I'm currently hovering between 40-50x productivity (on a LOC basis, which I know is bad, but it's the only objective mesure I have), over 16+ weeks, with Opus 4.6 (nothinking!) and now Fable (low thinking). I get there not doing a few things differently:

1. I frontload the design-time thinking and elaboration. I absolutely use agents in design (usually 2 of them, plus me). However, I don't let agents design my software. I use them as researchers, as sounding boards, then I make the call when I see how my goals fit in. Then I have them write a design spec, and review it, and I review it; then i have them write a "concise phazed bulleted checkbox implementation plan" then i review that, and once it seems coherent, I put that into a new session that has VERY LOW thinkikng budget, so the model can stop second guessing everything we've already pinned down in the thinking/design phase, and just implement it.

2. I stay connected and read most of the verbal chat output and careful code details to see the big picture... No trees of subagents. I watch and manage every agent chat, all the time. 4-6 simultaneous windows of agent chats (in my own self authored harness) that I watch like a hawk, because they type 100x faster than I do, but they are much worse coders and so I have to catch their mistakes before they compound and eat the codebase. (This is a large interconnected codebase, not a pile of isolated separate things)

3. I design the process to get from A to B... the ordering of the feature development, just like I would do myself, to minimize architecture risk, get the unknowns out of the way, feel the thing taking shape before the complexity layers in..Then build harnesses with as much AI visible iteration loop as is practical for the part we are working on. I use third-party oracle references when I can (like pixel correct font and shape tests against Skia, instead of just eyeballing) And I decide the level of detail where this is useful, then put the LLM in a place where it can succeed.

absolutionist => absolutist

Abstract

Rust is not a memory-safe language. Memory safety, as the term has always meant in language design — the property that programs in the language cannot violate memory integrity — is a compositional property of a language and its runtime: it holds for all programs, over all data shapes, unconditionally. Rust does not have this property.

What Rust has is a static checker that verifies an ownership discipline over tree-shaped data only, plus a set of unsafe escape hatches whose use is not optional but structurally mandatory: any cyclic, self-referential, or densely shared data structure — doubly-linked lists, graphs, DOMs, scene graphs, caches, entity systems — is inexpressible under the checker and forces the program into hand-written unsafe, runtime reference counting, or unchecked index schemes. Because these structures dominate real systems software, the unverified surface of a Rust program grows with the program's structural complexity, and at engine scale the observed end state — in Servo, Bevy, and Zed alike — is that every large Rust project builds its own bespoke, unverified object-lifetime runtime.

A language whose safety property is conditional on universally quantified, undischarged proof obligations across its entire ecosystem, whose checker cannot express the core data structures of the domain it targets, and whose flagship projects manage memory through hand-audited runtimes, is not a memory-safe language under any definition of the term that does not also admit reference-counted C++. Garbage-collected platforms are memory safe. Rust is a memory-disciplined language with a memory-safe subset for trees — and the difference is not pedantry; it is the difference between a property of the language and a property of small programs.

If you would like a rigerous look at this reality, read on for the full paper. This is not an attempt to throw shade on Rust developers. Rust has many great properties. People like it. Languages have become popular for less. Memory Safety, or "safety" in general is not one of them, and we should stop pretending it is.

I respect someone who knows what they like, but i love the journey as much or more, and i love AI coding. Not vibe coding mind you, deep engaged, specify tightly and review most edits in a high velocity flow state. Its not easy to read code at 80 tokens/second, but its fun, and feels more like im dreaming in code, using AI to type exactly what i want at 10x the speed. Which allows me to experience more of the journey..and i still get plenty of thorny bugs to work through. What would you code, if you could code anything you dreamed. Go code that today. Btw, 50 years old,started programming at age 9.

THe composable executable tool pattern is great, but hiding all details behind "search" is no panacea. Without any capability description in the context, LLMs won't necessarily know they SHOULD search for something in the tool API... so it's a tradeoff.. The real challenge is figuring out how to give them context-aware tool documenation. Maybe if that's built into the model somehow with a retrained model, or if it knows broadly enough about cloudflare (or any provided sdk)

The news is not that they turned off this account. The news is that this user understands very little about the nature of zero sum context mathematics. The mentioned Claude.md is a totally useless mess. Anthropic is just saving themselves from the token waste of this strategy on a fixed billing rate plan.

If the OP really wants to waste tokens like this, they should use a metered API so they are the one paying for the ineffectiveness, not Anthropic.

(Posted by someone who has Claude Max and yet also uses $1500+ a month of metered rate Claude in Kilo Code)

I think it is failure to differentiate between moments of risk with safety margin and risk without safety margin (or with substantially reduced margin) that puts most people in danger.

We tend to look at overall "risk of dying doing a sport" and fail to maintain awareness to identify these specific moments.

For example, our family wakesurfs on Lake Tahoe. My wife considers boating and wakesurfing pretty safe. However, in June the water temp is 53 degrees F. If our boat sinks 3 miles offshore and nobody sees it, life jackets will not save anyone. The boat sinking that fast is unlikely, but it is possible. I consider that an unacceptable unmitigated risk, and ask her to stay near shore when she drives.. yet she never does, and when i scold her she thinks im nagging and annoying.

While i'm not a pilot, i've been up with private pilots, taken hang gliding lessons, done tandem skydives, ride motorcycles, dirt bikes, ski a ton, backcountry ski..

..i don't consider any of these activities to be "safe" or "unsafe" overall.. i consider moments of low safety margin to be dangerous and to be understood, treated with extra care and mitigated or avoided as much as possible.