I am now making an emotional reaction based on zero knowledge of the B2B codebase's environment, but to be honest I think it is relevant to the discussion on why people are "worlds apart".
200k lines of code is a failure state. At this point you have lost control and can only make changes to the codebase through immense effort, and not at a tolerable pace.
Agentic code writers are good at giving you this size of mess and at helping to shovel stuff around to make changes that are hard for humans due to the unusable state of the codebase.
If overgrown barely manageble codebases are all a person's ever known and they think it's normal that changes are hard and time-consuming and needing reams of code, I understand that they believe AI agents are useful as code writers. I think they do not have the foundation to tell mediocre from good code.
I am extremely aware of the judgemental hubris of this comment. I'd not normally huff my own farts in public this obnoxiously, but I honestly feel it is useful for the "AI hater vs AI sucker" discussion to be honest about this type of emotion.
I am the author of the optimization of partial sorting and selection in Clickhouse. It uses Floyd-Rivest algorithm and we tried a lot of different things back at the time, read [1]
Overall clickhouse reads blocks of fixed sizes (64k) and finds top elements and then does top of the top until it converges.
There might be some papers or other guides out there, but their advice will be based on whatever tools happened to be available at the time they were written and on the particular types of translations the authors cared about. The technology is advancing so rapidly that you might be better off just experimenting with various LLMs and prompts for texts and language pairs you are interested in.
I started using LLMs for translation after GPT-4 came out in March 2023—not that long ago! At first, the biggest problem was the context window: it wasn’t possible to translate more than a couple of pages at a time. Also, prompt writing was in its infancy, and a lot of techniques that have since emerged were not yet widely known. Even now, I still do a lot of trial and error with my prompts, and I cannot say with confidence that my current prompting methods are the best.
But, for what it’s worth, here are some strategies I currently use when translating with LLMs:
- In the prompt, I explain where the source text came from, how the translation will be used, and how I want it to be translated. Below is a (fictional) example, prepared through some metaprompting experiments with Claude:
- I run the prompt and source text through several LLMs and glance at the results. If they are generally in the style I want, I start compiling my own translation based on them, choosing the sentences and paragraphs I like most from each. As I go along, I also make my own adjustments to the translation as I see fit.
- After I have finished compiling my draft based on the LLM versions, I check it paragraph by paragraph against the original Japanese (since I can read Japanese) to make sure that nothing is missing or mistranslated. I also continue polishing the English.
- When I am unable to think of a good English version for a particular sentence, I give the Japanese and English versions of the paragraph it is contained in to an LLM (usually, these days, Claude) and ask for ten suggestions for translations of the problematic sentence. Usually one or two of the suggestions work fine; if not, I ask for ten more. (Using an LLM as a sentence-level thesaurus on steroids is particularly wonderful.)
- I give the full original Japanese text and my polished version to one of the LLMs and ask it to compare them sentence by sentence and suggest corrections and improvements to the translation. (I have a separate prompt for this step.) I don’t adopt most of the LLM’s suggestions, but there are usually some that I agree would make the translation better. I update the translation accordingly. I then repeat this step with the updated translation and another LLM, starting a new chat each time. Often I cycle through ChatGPT --> Claude --> Gemini several times before I stop getting suggestions that I feel are worth adopting.
- I then put my final translation through a TTS engine—usually OpenAI’s—and listen to it read aloud. I often catch minor awkwardnesses that I would overlook if reading silently.
This particular workflow works for me because I am using LLMs to translate in the same language direction I did manually for many years. If I had to translate to or from a language I don’t know, I would add extra steps to have LLMs check and double-check the accuracy of the translation and the naturalness of the output.
I was asked recently by some academics I work with about how to use LLMs to translate documents related to their research into Japanese, a language they don’t know. It’s an interesting problem, and I am planning to spend some time thinking about it soon.
Please note that my translation process above is focused on quality, not on speed. If I needed to translate a large volume of text more quickly, I would write a program to do the translation, checking, and rechecking through API calls, accepting the fact that I would not be able to check and polish the translation manually as I do now.
If anyone here would like to brainstorm together about how to use LLMs for translation, please feel free to email me. My website, with my email address on the Contact page, is linked from my HN profile page.
I went from 0.3Mbps on T-Mobile to 50+ Mbps with this; on providers that limit hotspot speed by examining TTL, this can be an effective way to get around it.
(They assume if they see TTL as one lower than expected, data is passing through a hotspot/phone instead of directly from the phone.)
I found an enjoyable demo (can't find it now though...) of the animated table-of-contents feature mentioned here, and adapted for a website I maintain:
His blog post mentions people influenced (and misguided) by reading only American Sci-Fi. What are some examples of good "worldly" Sci-Fi? Or, good non-US Sci-Fi authors? Should I just check the Hugo and Nebula awards? I would like to expand my Sci-Fi palate.
I've switched almost entirely to ebooks for fiction, but I will only buy books that fit the following criteria:
1. DRM-free
2. No more expensive than the cheapest suggested retail price
3. Available in a generic format (EPUB, preferably)
So far, I've had excellent luck with Baen books, and decent luck with Tor books and miserable luck with just about every other publisher. Still, jokes on them, I will just pirate if I can't find a version that fits my criteria.
Oh wow. I'd be very interested in hearing how they sandbox rust-analyzer. I found a discussion of supporting the analyzer itself by generating config files [1][2], but not how you can sandbox it.
That would be extremely useful as the analyzer is a pretty juicy target and also runs proc-macros/build.rs scripts.
Can you explain what Menhir does better than other parser frameworks? For what it's worth, I'm not a huge fan of parser frameworks. I tend to prefer hand written parsers, either via a combinator library or fully manually.
Rust has a pretty darn good ecosystem too btw. chumsky for parsing, rowan for syntax trees, salsa for incremental computation, miette for errors, inkwell/walrus for code generation.
what're some other interesting "incremental games" out there these days?
for me at least, just seeing numbers go up and get huge (Swarm Simulator) doesn't really do it for me. part of what makes Universal Paperclips so good is that, like Candy Box, a huge part of the joy is uncovering entirely new gameplay systems as you progress. A Dark Room was neat in that it brought the idea of a coherent narrative that you (sometimes subtly) uncover as you progress, too.
I feel like there's a lot of room left to explore in the space: different mechanics and systems to explore (outside of just clicking and upgrading), the possibility of cooperation with other players... the browser-based incremental game is pretty versatile in what it could do.
one of the most interesting one of these I've seen is Parameters (http://nekogames.jp/swf/prm.swf — download & play locally with Ruffle or some other SWF player). it's like an abstract RPG where you go on quests (or something) by clicking squares to fill them up. it's kinda crazy to me that nobody seems to have iterated on this concept.
I've noticed amongst many peers that when going down the type theory/pl theory journey there is a ton of hidden knowledge and context we all find ourselves collecting which makes all it "click" and help produce more idiomatic implementations.
All of this knowledge and context spread amongst a common set of books, papers, blog posts, and git repos floating around the internet.
At the risk of creating yet another partial silo, I decided earlier this year to create a project similar to the [Elaboration Zoo](https://github.com/AndrasKovacs/elaboration-zoo) but focused on a blessed path to MLTT with a number of the desirable language features via bidirectional typechecking.
The project is incomplete and my end goal is a website like the [1 Lab](https://1lab.dev) but focused on Type Theory and PL Theory, but I ran low on steam and could use some collaborators.
The 1987 paper about superoptimizers is well worth the read, BTW. It's quite short. Even the first example on its own (writing the sign function without any conditionals) is a mind-bender but becomes straightforward once you see the trick used: https://courses.cs.washington.edu/courses/cse501/15sp/papers...
I agree. While I like the idea of tup (https://gittup.org/tup/ -- the first "forward" build system I remember hearing of), writing a makefile is easy enough that thinking about the problem upside-down doesn't offer a compelling reason to switch.
In case it's new to anyone, I recommend going through the jones forth "literate program" - even if you don't understand assembly. You can try porting it to a language you know, it gives a good understanding of how forth works
To set my non-coffee-snob bona fides, I exclusively drink decaf (I've avoided caffeine for almost 10 years now).
The reactions this post is getting are kind of odd. A typical home coffee brewing setup is going to offer you just a couple of variables --- a set-it-and-forget-it grind size, water temperature, and the dose of grounds you use for whatever amount of coffee you brew.
It is not especially weird or "gourmet" to be interested in what the right values are for each of those variables. You figure out the right grind size and dial it into your grinder; you figure out the right temperature and hit that button on your kettle; you figure out the right dose and either weigh or scoop-measure that much grounds. Mostly what I'm describing is the simple act of brewing a cup of coffee.
Hey, Steve. We've received a few, but not as many as you might think (at least relative to fish's popularity). I can't speak for @ridiculousfish but I would say such comments probably had close to zero impact on (t)his decision.
I think certain team members have individually gravitated towards rust over the years, probably each for reasons of their own. Peter is the driving force behind this commit (I don't think anyone else would have ventured to open this PR and would probably have launched a rust fork as a side project instead) and I've been seeing him publicly state his evolving opinion on rust over the years. He's thorough and methodical and certainly not prone to seismically shaking up the codebase on a whim or because of a RIIR comment made in passing; I think it probably just reached the point a lot of others that maintain other projects have reached in the past, where the appeal of porting it to a (hopefully better) language reaches a tipping juncture that makes it worth entertaining.
Personally, every time I delve deep within the internals of fish's legacy codebase I just come away increasingly frustrated with how much of what I'm doing is battling the language or working around its warts rather than working on what I really want to be doing. We've spent too many man hours to count porting concepts like Option<T> and friends over to take advantage of the hygiene and correctness they lend to codebases. I most recently spent forever working out a CoW string, then didn't have it in me to actually merge the branch because of how much churn it would probably entail.
But back to your question - I feel like most "why don't you rewrite it in rust" questions can generally be dismissed almost entirely out of hand because they're made in passing by people with no stake in the project who have no idea what that would entail, what it would look like, and at what cost it would come. The only people I ever spoke to seriously about that were other core maintainers, and there are very few outside that pool whose opinion I would personally attribute any weight to on a question like that.
Absolutely do not use make for any new project. If you love make, it's a big, red, burning flag that you're not demanding enough of your tools and that you're not keeping up with changes in your ecosystem.
There are many, many way better alternatives to make. Which one is better depends on the platform you're on. The majority of them throws in automatic dependency management for free.
Yes, I know that the essence of the post is "use a build system". I agree completely. In fact, script everything. Then script your scripts. Then refactor your scripts because they are getting messy. But don't give impressionable souls the idea that "make" is anywhere near an acceptable (generalised, default) choice today.
Another neat "pick an OS to boot into" tool I discovered recently is Ventoy [1]. You install the bootable menu on your USB drive, and then you just drop ISOs or IMGs on there to add choices.
Let's try appending just one more item before redoing ^ that example, where they all shared the same data: https://go.dev/play/p/5JneXHMeUjx
[a b c]
[z b c x x2]
[a b c y y2]
Notice that in all of these examples, I haven't explicitly declared a length or capacity. There's nothing "funny looking" or clearly intentionally allowing these different behaviors, it's just simple, very-common slice use.
.... so yeah. This is a source of a number of hard-to-track-down bugs.
First step, if you get a demand like that, file a police report. Extortion, and attempted extortion, are crimes. You can also file with the FBI online, which will at least result in your complaint being accumulated with other similar complaints. Not much may happen, but now it's on record.
Now you have paperwork establishing a crime.
If you're willing to spend legal fees, talk to a lawyer. You can potentially sue the extortionist as an unknown "John Doe", and Google as collaborating with the extortionist to extract money from you.
Google is in a touchy position here, because they really did cooperate with an extortionist to extract money.
Google can claim the cooperation was unwitting, but that can fall apart if an ongoing pattern of similar behavior can be shown, and if Google can be shown to have been negligent in determining whether takedown requests were valid.
This is routine in fleet auto accidents. Uber gets this all the time. They want to pass the buck to the driver, but they have to be able to identify the driver to do that. So they are very helpful about identifying the driver.
Because this arises from a criminal offense, Google's terms of service may be irrelevant. You cannot contract away liability for a crime.
So there's stuff you can do. This sort of thing usually settles out of court. But when you file a lawsuit, you're dealing with people well above the level of the customer service staff. Talk to a lawyer. Might even be able to find one willing to take this on a contingency fee basis.
This is an area where Google might not want extensive pre-trial discovery looking into exactly what level of cooperation they provide extortionists. If someone is extorting small dollar amounts, they're doing this more than once.
Lots of little things that might not matter much individually, but still add up significantly when taken together:
- tabs can't be reordered any more
- bookmarks/history/recently closed tabs/top sites... are more cumbersome to access
- no "recently closed tabs" for quite a few months after the initial release
- bookmarks always force-open a new tab
- search suggestions needlessly take up more space (apparently by design, because these days information density is baaaaad), so you can't see local history/bookmark results without closing the keyboard or scrolling down
- using a search engine other than the default one requires two extra click at least, whereas previously they were directly accessible at the bottom of the screen
- Can't install search engines any more, instead you manually need to enter the correct search URL, which isn't fun (and then the manually created engine is of course lacking a proper icon)
- bookmark keywords and keyword searches aren't supported
- you used to be able to open a new tab by simply tapping the "tabs" button twice because the "new tab" button in the tabs list was suitably aligned – this is no longer the case (at least with the URL bar in classic on top mode)
- the tab queue for tabs opened from other apps doesn't exist any more
- the share sheet – you used to be able to share a URL to Firefox and then directly bookmark it or send it to another Firefox instance via Firefox Sync without having to actually open the URL in Firefox locally. Now you can't – any shared URLs are automatically opened and you need to wait for the full browser to actually load before you can bookmark/send the tab (and then you also need to close it again)
- view page source doesn't exist, not even if you manually prepend view-source: to the URL (supposedly there's an addon that works, but due to the blasted add-on policy you can't actually install it)
- can't view/browse local (HTML) files any more
- can't install themes anymore
- various small bugs introduced by the fact that this was a total rewrite
- despite having to rewrite the whole UI from scratch anyway, they didn't fix the "XKCD" bug and make long <img "title"> attributes scrollable instead of truncating them
- and probably quite a few more things I'd notice if I was actually regularly using the current version…
And of course the whole add-on thing: Even on the previous iteration of Firefox, the Webextension API implementation was somewhat half-hearted once you got to APIs that required special handling on the Android version, and the fact that this was a total rewrite hasn't helped in significantly expanding the coverage there, because instead the dev time largely had to be spent on re-implementing things.
Then there's of course that absolutely infuriating policy of only allowing a very limited selection of add-ons to be installed (unless you're on Nightly and jump through about half a dozen hoops, and even then you can only install the current version (and only the current version) of add-ons actually published on AMO). If you're lucky (or basically only using uBlock), maybe your add-on needs are actually covered by that, but the long tail of unsupported add-ons starts very early.
This also makes life more difficult for add-on developers (even if your add-on is actually one of the selected few), because you can no longer permanently install a testing version of your add-on or heaven help distribute a Beta version to your users (no, not even on Nightly and not even if the add-on is signed) – the best you get is temporary installation as long as your phone is connected to your computer and that's that.
Former Uber engineer/EM here: I worked on the Rider app.
The “there are only a few screens” is not true. The app works in 60+ countries, with features shipped in the app that often for a country, and - in rare cases - a city.
The app has thousands of scenarios. It speaks to good design that each user thinks the user is there to support their 5 use cases, not showing all the other use cases (that are often regional or just not relevant to the type if user - like business traveler use cases).
Uber builds and experiments with custom features all the time. An experimental screen built for London, UK would be part of the app. Multiply this by the 40-50 product teams building various features and experiments outside the core flows you are talking about (which core flows are slightly different per region as well).
I worked on payments, and this is what screens and components are in the Uber app:
- Credit cards (yes, this is only a a few screens)
- Apple Pay / Google Pay on respective platforms
- PayPal (SDK)
- Venmo (SDK)
- PayTM (15+ screens)
- Special screens for India credit cards and 2FA, EU credit cards and SCA, Brazil combo cards and custom logic
- Cash (several touch points)
- AMEX rewards and other credit card rewards (several screens)
- Uber credits & top-ups (several screens)
- UPI SDK (India)
- We used to have Campus Cards (10 screens), Airtel Money (5), Alipay (a few more), Google Wallet (a few) and I other payment methods I forget about. All with native screens. Still with me? This was just payments. The part where most people assume “oh, it’s just a credit card screen”. Or people in India assume “oh it’s just UPI and PayTM”. Or people in Mexico “oh, it’s just cash”. And so on.
Then you have other features that have their own business logic and similar depths behind the scenes when you need to make them work for 60 countries:
- Airport pickup (lots of specific rules per region)
- Scheduled rides
- Commmuter card functionality
- Product types (there are SO many of these with special UI, from disabled vehicles, vans, mass transport in a few regions etc)
- Uber for Business (LOTS of touchpoints)
- On-trip experience business logic
- Pickup special cases
- Safety toolkit (have you seen it? Very neat features!)
- Receipts
- Custom fraud features for certain regions
- Customer support flows
- Regional business logic: growth features for the like of India, Brazil and other regions.
- Uber Eats touchpoints
- Uber Family
- Jump / Lime integrations (you can get bikes / scooters through the app)
- Transit functionality (seen it?)
- A bunch of others I won’t know about.
Much of the app “bloat” has to do with how business logic and screens need to be bundled in the binary, even if they are for another region. E.g. the UPI and PayTM SDKs were part of the app, despite only being used for India. Uber Transit was in a city or two when it launched, but it also shipped worldwide.
And then you have the binary size bloat with Swift that OP takes about.
Well there are eggplants, peaches and melons of course, but outside of emoji, there is also unicode for egyptian hieroglyphs breast (U+13091 U+13092 𓂑 𓂒) and phallus (U+130B9 and U+130BA 𓂹 𓂺)
Gasp! I just learned the phallus heiroglyphs are missing from the fonts on my windows box! Even U+130B8 𓂸 which isn't even a penis, it's just a somewhat phallic finger.
200k lines of code is a failure state. At this point you have lost control and can only make changes to the codebase through immense effort, and not at a tolerable pace.
Agentic code writers are good at giving you this size of mess and at helping to shovel stuff around to make changes that are hard for humans due to the unusable state of the codebase.
If overgrown barely manageble codebases are all a person's ever known and they think it's normal that changes are hard and time-consuming and needing reams of code, I understand that they believe AI agents are useful as code writers. I think they do not have the foundation to tell mediocre from good code.
I am extremely aware of the judgemental hubris of this comment. I'd not normally huff my own farts in public this obnoxiously, but I honestly feel it is useful for the "AI hater vs AI sucker" discussion to be honest about this type of emotion.