[HN Gopher] Ladybird adopts Rust
___________________________________________________________________
Ladybird adopts Rust
Author : adius
Score : 990 points
Date : 2026-02-23 11:29 UTC (11 hours ago)
(HTM) web link (ladybird.org)
(TXT) w3m dump (ladybird.org)
| viktorcode wrote:
| > We previously explored Swift, but the C++ interop never quite
| got there
|
| But Rust doesn't have C++ interop at all?
| tonyedgecombe wrote:
| >But Rust doesn't have C++ interop at all?
|
| It also doesn't have the disadvantages of Swift. Once the
| promise of Swift/C++ interop is gone there isn't enough left to
| recommend it.
| nicoburns wrote:
| You can do it via the C ABI, and use opaque pointers to
| represent higher-level Rust/C++ concepts if you want to.
|
| Firefox is a mixed C++ / Rust codebase with a relatively close
| coupling between Rust and C++ components in places
| (layout/dom/script are in C++ while style is in Rust, and a mix
| of WebRender (Rust) and Skia (C++) are used for rendering with
| C++ glue code)
| wavemode wrote:
| > You can do it via the C ABI, and use opaque pointers to
| represent higher-level Rust/C++ concepts
|
| Yeah but, you can do the same in Swift
| nicoburns wrote:
| My understanding from a brief read of the Swift issue is
| that they kept running into bugs in the Swift compiler
| which, in practice, prevented them from doing the things
| that they ought to be do in theory. This went on for long
| enough, that they got fed up and abandoned Swift.
|
| The Rust compiler is incredibly solid (across all target
| platforms), and while it's C/C++ interop is relatively
| simplistic, what does exist is extensively battle tested in
| production codebases.
| azornathogron wrote:
| It may have in the future. Crubit is one effort in this
| direction: https://crubit.rs/
| woadwarrior01 wrote:
| Yeah, that part doesn't make much sense to me. IMO, Swift has
| reasonably good C++ interop[1] and Swift's C interop has also
| significantly improved[2] since Swift 6.2.
|
| [1]: https://www.swift.org/documentation/cxx-interop/
|
| [2]: https://www.swift.org/blog/improving-usability-of-c-
| librarie...
| matthewkosarek wrote:
| There is also cxx.rs, which is quite nice, albeit you have to
| struggle sending `std` types back and forth a bit
| nicoburns wrote:
| > albeit you have to struggle sending `std` types back and
| forth a bit
|
| Firefox solves this partly by not using `std` types.
|
| For example, https://github.com/mozilla/thin-vec exists in
| large part because it's compatible with Firefox's existing
| C++ Vec/Array implementation (with the bonus that it's only 8
| bytes on the stack compared to 24 for the std Vec).
| nickorlow wrote:
| Luckily, ladybird also does not use `std` types
| the_mitsuhiko wrote:
| Rust has cxx which I would argue is "good enough" for most use
| cases. At least all C++ use cases I have. Not perfect, but
| pretty damn reasonable.
| mosura wrote:
| Interestingly editorialized title omits "with help from AI".
| supriyo-biswas wrote:
| A LLM-assisted codebase migration is perhaps one of the better
| use cases for them, and interestingly the author advocates for
| a hands-on approach.
|
| Adding the "with help from AI" almost always devolves the
| discussion from that to "developers must adopt AI or else!" on
| the one hand and "society is being destroyed by slop!" on the
| other, so as long as that's not happening I'm not complaining
| about the editorialized title.
| alpinisme wrote:
| That's probably just the classic HackerNews title shortening
| algorithm at work.
| throwaway2037 wrote:
| > classic HackerNews title shortening algorithm
|
| Woah, this is a wild claim. @dang: Is this a thing? I don't
| believe it. I, myself, have submitted many articles and never
| once did I see some auto-magical "title shortening algorithm"
| at work!
| logicprog wrote:
| I've seen it happen a couple times, iirc, it removes things
| after commas, and removes certain words as well
| ivanjermakov wrote:
| Adds [video] to YouTube links, too.
| simlevesque wrote:
| It's been confirmed by @dang many times before. I'm not
| sure if that's what cut the title here but I've seen it
| many times in the last 10 years.
| sjosh wrote:
| I went to check if this was documented in the list of
| undocumented HN features on GitHub but it's not.
|
| There is an open PR (by simonw btw):
| https://github.com/minimaxir/hacker-news-
| undocumented/pull/4...
| FpUser wrote:
| I think we've come to the point when it should be the opposite
| for any new code, something in line of: "done without AI". Bein
| an old fart working in software development I have many friends
| working as very senior developers. Every single one of them
| including yours truly uses AI.
|
| I use AI more and more. Goes like create me classes A,B,C with
| such and such descriptive names, take this state machine /
| flowchart description to understand the flow and use this
| particular sets of helpers declared in modules XYZ
|
| I then test the code and then go over and look at any un-
| optimal and other patterns I prefer not to have and asking to
| change those.
|
| After couple of iterations code usually shines. I also cross
| check final results against various LLMs just in case
| throwaway2027 wrote:
| I guess the ETA will pushed back by a few years then?
| FpUser wrote:
| Probably not unless using Rust present some particular
| challenge for this type of project. But having eaten this
| proverbial apple they would probably use AI more and more
| assuming they have a budget and in this case being less rich
| than C++ might not mean much for productivity
| OtomotO wrote:
| By 2 weeks so far ;-)
| VMG wrote:
| developers with good taste like Andreas Kling will be able to
| design entire OSes with coding agents
| embedding-shape wrote:
| Yeah, some weekends ago I tried writing a cross-platform
| browser without any Rust crates, this weekend I made my own
| self-hosted compile to Rust Clojure-like lisp, maybe next
| weekend attempting to create a OS that uses my language to run
| on bare-metal would actually be a challenge. Thanks for the
| inspiration :)
| Vsreddyh wrote:
| He already did
| vdupras wrote:
| This comment raises an interesting question: Would Serenity OS
| have brought Andreas the same kind of serenity had it been
| developed with AI? Open candid question.
| Imustaskforhelp wrote:
| I don't think so because if I remember it correctly, Andreas
| suffered from alcoholism and serenity prayer helped him to go
| on the right path and iirc he honored that and created an os
| named serenityos.
|
| God grant me the serenity
|
| to accept the things I cannot change;
|
| courage to change the things I can;
|
| and wisdom to know the difference.
|
| (courage to change the things I can;):- I think that this
| line must've given Andreas the strength, the passion to make
| the project reality.
|
| but if AI made the change. Would the line be changed to
| courage to prompt an all powerful entity to change the things
| I asked it to.
|
| Would that give courage? Would that inspire confidence in
| oneself?
|
| I have personally made many projects with LLM's (honestly I
| must admit that I am a teenager and so I have been sort of
| using it from the start)
|
| and personally, I feel like there are some points of
| curiosity that I can be prideful of in my projects but there
| is still a sense of emptiness and I think I am not the only
| one who observes it as such.
|
| I think in the world of AI hype, it takes true courage &
| passion to write by hand.
|
| Obviously one tries to argue that AI is the next bytecode but
| that is false because of the non deterministic nature of AI
| but even that being said, I think I personally feel as if the
| people who write assembly are definitely likely to be more
| passionate of their craft than Nodejs (and I would consider
| myself a nodejs guy and there's still passion but still)
|
| Coding was definitely a form of art/expression/sense-of-
| meaning for Mr Andreas during a time of struggle. To automate
| that might strip him of the joy derived from stroking brush
| on an empty canvas.
|
| Honestly, I really don't know about AI the more I think about
| it so I will not pretend that I know a thing/two about AI.
| This message is just my opinion in the moment. Opinions
| change with time but my opinion right now is that coding by
| hand definitely is more meaningful than not if the purpose of
| the project is to derive meaning.
| ramon156 wrote:
| > design entire OSes with coding agents
|
| They ported an existing project from CPP to Rust using AI
| because the porting would've been too tedious. I don't think
| they're planning on vibe coding PRs the way you're imagining.
| qudat wrote:
| > We know the result isn't idiomatic Rust, and there's a lot that
| can be simplified once we're comfortable retiring the C++
| pipeline. That cleanup will come in time.
|
| Correct me if I'm wrong since I don't know these two languages,
| but like some other languages, doing things the idiomatic way
| could be dramatically different. Is "cleanup" doing a lot of
| heavy lifting here? Could that also mean another complete rewrite
| from scratch?
|
| A startup switching languages after years of development is
| usually a big red flag. "We are rewriting it in X" posts always
| preceded "We are shutting down". I wish them luck though!
| samiv wrote:
| This is the famous trap that Joel on Software talked about in a
| blog post long time ago.
|
| If you do a rewrite you essentially put everything else on halt
| while rewriting.
|
| If you keep doing feature dev on the old while another "tiger
| team" is doing the rewrite port then these two teams are
| essentially in a race against each other and the port will
| likely never catch up. (Depending on relative velocities)
|
| Maybe they think that they can to this LLM assisted tools in a
| big bang approach quickly and then continue from there without
| spending too much time on it.
| JumpCrisscross wrote:
| > _then these two teams are essentially in a race against
| each other and the port will likely never catch up_
|
| Ladybird appears to have the discipline to have recognized
| this: "[Rust] is not becoming the main focus of the project.
| We will continue developing the engine in C++, and porting
| subsystems to Rust will be a sidetrack that runs for a long
| time."
| safercplusplus wrote:
| And I might suggest that there's the possibility that the
| C++ code could end up being more cleanly ported to a
| memory-safe subset of C++. plug: https://github.com/duneroa
| drunner/scpptool/blob/master/appro...
| christophilus wrote:
| I've been part of at least 2 successful rewrites. I think
| that Joel's post is too often taken as gospel. Sometimes a
| rewrite is the best way forward.
|
| Moving Ladybird from C++ to a safer more modern language is a
| real differentiator vs other browsers, and will probably pay
| dividends. Doing it now is better than doing it once ladybird
| is fully established.
|
| One last point about rewrites: you can look at any industry
| disruptor as essentially a team that did a from-scratch
| rewrite of their competitors and won because the rewrite was
| better.
| abuyalip wrote:
| I still don't buy this "safer more modern" mentality.
| Modern C++ pretty much solves the safety issues. People
| need to learn how to use tools properly.
|
| If you ask me, Go is a better Rust. Rust is an ugly version
| of C++ with longer compile times and a band of zealous
| missionaries.
|
| I mean the keywords mut and fn very annoying to read just
| get rid of them or spell the f*n thing function.
| nicoburns wrote:
| > Modern C++ pretty much solves the safety issues.
|
| The statistics from projects that have adopted Rust and
| measured the effect say otherwise. See
| https://security.googleblog.com/2025/11/rust-in-android-
| move... for example.
| steve1977 wrote:
| This article is not really specifying if Rust is compared
| against "Modern C++" or "Old School C++". The only thing
| we can assume is that at least part of it is "Google
| C++".
|
| Maybe we would see similar effects adopting Modern C++.
| Maybe not. The article doesn't tell us.
| bogeholm wrote:
| Yeah I guess most True Scotsmen write modern C++ after
| all.
| panstromek wrote:
| > Modern C++ pretty much solves the safety issues.
|
| I always wonder how can one come to such a conclusion.
| Modern C++ has no way to enforce relationship between two
| objects in memory and the shared xor mutable rule, which
| means it can't even do the basic checks that are the
| foundation of Rust's safety features.
|
| Of course, this statement is also trivially debunked by
| the reality of any major C++ program with complexity and
| attack surface of something like a browser. Modern C++
| certainly didn't save Chrome from CVEs. They ban a bunch
| of C++ features, enforce the rule of two, and do a bunch
| of hardening and fuzzing on top of it and they still
| don't get spared from safety issues.
| abuyalip wrote:
| Yeah sure. Thing is, C does just fine people are making
| "safe" ways to run libc. Rust is a complicated
| monstrosity with a bunch of "unsafe" sprinkles.
|
| What does the memory safety even matter when hackers
| poison heavily used crates?
| GoblinSlayer wrote:
| FWIW Chrome includes third party libraries like freetype
| and lots of bugs are in javascript. I imagine defensive
| checks in javascript will be controversial since
| performance of javascript is controlled by webdev, not by
| browser.
| Koranir wrote:
| Note that Chrome is replacing[1] FreeType with Skrifa[2],
| which is a Rust-based library that can handle a lot of
| the things FreeType is being used for in Chrome. A lot of
| Chrome's dependencies are being rewritten in Rust.
|
| [1]: https://developer.chrome.com/blog/memory-safety-
| fonts
|
| [2]: https://github.com/googlefonts/fontations/tree/main/
| skrifa
| josephg wrote:
| > Go is a better Rust. Rust is an ugly version of C++
| with longer compile times and a band of zealous
| missionaries.
|
| Eh. There's a lot I like about Go. I adore its
| compilation speed and the focus on language simplicity.
| But its got plenty of drawbacks too. Default nullability
| is a huge mistake. And result types (zig, swift, rust)
| are way better than go's error handling. Sum types in
| general are missing from Go, and once you start using
| them its so hard to go back. Go also doesn't have
| anywhere near as good interop with native code. Mixing C
| (or any other LLVM langauge) with rust is easy and feels
| great. You even get LTO across the language barrier.
|
| The big thing I'm growing to dislike about rust is how
| many transitive dependencies a lot of projects end up
| pulling in. Its very easy to end up with projects that
| take a million years to compile & produce huge binaries.
| Not because they do a lot but simply because everything
| depends on everything, and the dependency tree takes a
| long time to bottom out. I don't know what the right
| answer is. It feels more like a cultural problem than a
| language / ecosystem problem. But I wish rust projects
| felt as lightweight and small as most C projects I've
| worked with. I'm doing some work with the stalwart email
| server at the moment (written in rust). Stalwart is a
| relatively new, well written email server. But it somehow
| pulls in 893 transitive dependencies! I'm not even
| joking. Compiling stalwart takes about 20 minutes, and
| the compilation process generates several gigabytes of
| intermediate build assets. What a mess.
| nicoburns wrote:
| > Compiling stalwart takes about 20 minutes
|
| 20 minutes! What hardware is this on? I've worked on Rust
| projects with similar numbers of dependencies where the
| compile time (for a clean release build) was 2-4 minutes
| (on a MacBook M1 Pro)
| nicoburns wrote:
| UPDATE: tried compiling stalwart on my machine, and it
| took 14 minutes, with a really weird timing profile:
|
| - 99% of the ~700 crates were done compiling in about a
| minute or 2 - RocksDB (a C++ dependency) was 2 minutes by
| itself - And then it took 10 minutes (ten!) just for the
| final binary at the end.
|
| That's not normal for Rust code at all. Even large ones
| like Servo or Rustc or Zed.
|
| UPDATE2: turns out they have LTO enabled by default.
| Disabling that brings the compile time down to 7 minutes.
| But that's still really unexpectedly slow.
| josephg wrote:
| Disabling codegen units = 1 speeds up the compilation
| further. But it's still too many dependencies and too
| slow. The binary is pretty huge too.
| nicoburns wrote:
| > But it's still too many dependencies and too slow.
|
| I definitely agree that it's too slow. I just don't think
| the cause is "too many dependencies" because I've
| compiled Rust codebases with twice as many dependencies
| in half the time!
|
| It seems to produce a 94MB binary. So it may be partly
| that there are some very big dependencies. But the amount
| of compilation time that ends up in the top-level crate
| (even with LTO disabled) also makes me feel like this
| must be triggering a compiler bug. Either that or using
| far too many generics.
| 9rx wrote:
| _> Sum types in general are missing from Go_
|
| Not quite. It doesn't have tagged unions, which is what I
| expect you are thinking of, but it does have sum types.
| josephg wrote:
| Only by abusing interface {}. The result is horrible.
|
| Go doesn't have sum types as a first class primitive.
| 9rx wrote:
| Using interface as it was designed to be used offers
| first-class sum types. Although not all interface use
| equates to sum types.
|
| But they're not tagged unions. I expect that is still
| where your confusion lies. Tagged unions and sum types
| are not equivalent. Tagged unions are a subset of sum
| types.
| lock1 wrote:
| I'm curious, if tagged unions are a subset of sum type,
| what is your definition of "sum type"?
|
| AFAIK, tagged union _is_ sum type, based on sum type
| mathematical definition.
| 9rx wrote:
| On second thought, I agree with your definition. So Go
| does, in fact, have tagged unions.
| josephg wrote:
| This may be a bit too pedantic, but I consider interface
| {} to be a way to do polymorphism via type classes.
| Interface defines an open class of types which implement
| some interface.
|
| Sum types are a type definition defining something as A
| or B. Not "anything that quacks like a duck". But
| concretely "one of this or one of that". This enables
| different syntax, like the match expression to be used,
| in which you exhaustively list all the variants. The
| compiler doesn't need to heap allocate enums because it
| knows the maximum size of a single value. The compiler
| and programmer can take advantage of the knowledge that
| there's a closed set of values the type can hold. It's
| not an open type class.
|
| Result and Option are quite beautiful as sum types. But
| they're horrible as type classes. Try implementing them
| using interface{} in Go. It's not the same.
| 9rx wrote:
| _> Interface defines an open class of types_
|
| But can also define a closed set of types, perfectly
| satisfying "sum types".
|
| _> This enables different syntax, like the match
| expression to be used, in which you exhaustively list all
| the variants._
|
| Go does not provide this out of the box, but that is not
| prerequisite for sum types. The mathematical theory says
| nothing about "the compiler must produce an error if the
| user doesn't match call cases". There is sufficient
| information provided by the sum types if you wish to add
| this to your build chain yourself, of course.
| josephg wrote:
| By that definition C has sum types too.
|
| This argument feels like the "we have sum types at home"
| meme. Ergonomics matter.
|
| I write a lot of rust. Rust has traits which are similar
| to Go's interfaces. But the features aren't the same, and
| I use enum all the time. (I also use trait all the time,
| but I use trait and enum for different things).
| hypeatei wrote:
| > Modern C++ pretty much solves the safety issues
|
| The data says otherwise, three overflows and two UAFs
| this month in Chrome alone:
| https://www.cvedetails.com/vulnerability-
| list/vendor_id-1224...
| throwaway2037 wrote:
| > People need to learn how to use tools properly.
|
| Two things: (1) I see that you are using a throwaway/new
| account. If throwaway, I have little sympathy for any
| downvotes that you get. If new, welcome to the community.
| I hope your share you personal experiences. (2) Nothing
| gets me more angry than telling highly skilled people it
| is a "problem between keyboard and chair." ("Oh, you just
| need to use it correctly.") As a top secret C++ fanboi
| for more than 25 years, I am just so tired of hearing
| this bullshit. As much as it hurts me to say it, Rust is
| better at _FORCING_ programmers to do the right thing...
| instead of C++ where you _CAN_ do the right thing. In my
| mind, without a very fast iteration for C++ "dialects"
| (see the Google project) where teams can trivially enable
| or disable language features (like multiple inheritance),
| C++ is a dying language compared to Rust.
| riku_iki wrote:
| > C++ is a dying language compared to Rust.
|
| there is a good chance Rust will start dying and will
| actually die by being replaced by some new hyper-
| overengineered lang much faster than C++ actually die.
| staticassertion wrote:
| This is a very shallow, very boring criticism. I doubt it
| will resonate. Modern C++ does not solve the safety
| issues, it has plenty of brand new footguns like
| string_view. Who cares if Go is better than Rust? Feel
| free to write Go, no one cares.
|
| "mut and fn very annoying to read" like okay lol who
| cares? What should anyone take from your post other than
| that you aren't that into Rust?
| anthk wrote:
| If C++ died for services under Unix and medium sized
| indie games (such as I2PD, or Cataclysm DDA and its
| forks) and these where rewritten in Go the maintenance
| would be far greater in these projects. A GC, a much
| better cross compatibility and your code for sure could
| probably be compiled in 10 years.
|
| Also CDDA:Bn wouldn't damn need a > 40h long build using
| 1.5 GB of RAM under an n270 netbook. Ditto with Nchat,
| FFS, which is _worse_. A Golang counterpart for nchat as
| a TG client (and tdlib rewritten in Go) would weight far
| less while compiling and maybe even the binary itself,
| and performance wise it would be similar.
|
| I still remember tons of C++ projects from 2005-2009
| impossible to compile today but with GCC 4.3 or GCC 4.9,
| can't remember. Not because of the size, but because C++
| incompatible changes over the years. At least tons of C
| code will compile it today as is modulo some POSIX
| changes from C code pre 1996. C++ it's something that
| should died long ago, among stuff like locales under
| Unix. UTF8 everywhere, use your own currency and the
| like.
|
| Yeah, I know, game engines, and tons of physics engines
| and libraries even FLOSS ones such as OGRE, gdal and the
| like are C++ domain. Still, most of these could be ported
| to C.
| throwaway2037 wrote:
| > I've been part of at least 2 successful rewrites. I think
| that Joel's post is too often taken as gospel. Sometimes a
| rewrite is the best way forward.
|
| HN nerd-snipe alert! OK, you got me good. Can you share
| some battle stories? I have also been part of rewrites in
| my career, but my experience is mixed. I'm not here to
| simple brush away your experience; I want to know more
| about _why_ you think (in retrospective) it was a good idea
| and _why_ it was successful.
|
| I can recall recently, listening to an Oxide and Friends
| podcast where they spent 30 minutes dumping all over "Agile
| Dev", only to have a very senior, hands-on guy join from
| AWS and absolutely deliver the smack down. (Personally, I
| have no positive experiences with Agile Dev, but this guy
| really stunned the room into silence.) The best part: The
| Oxide crew immediately recognized the positive experence
| and backed off the give this guy the space he needed to
| tell and interesting story. (Hats off the Ox crew for doing
| that... even if I, personally, have zero love for Agile
| Dev.)
| GoblinSlayer wrote:
| Firefox, Opera and first Edge were rewrites.
| samiv wrote:
| The good news is as of now ladyboy doesn't have any
| competition.
|
| Rarely if ever is anything able to compete simply by being
| "better". As far as USPs go it's just not enough. I reckon
| for ladyboy the USP (if any) is going to be it being open
| and NOT chrome (or derivative). So "safe" "modern" language
| is not going to mean much to the end users.
| simonw wrote:
| Nearly 26 years ago!
| https://www.joelonsoftware.com/2000/04/06/things-you-
| should-...
|
| What's different today really is the LLMs and coding agents.
| The reason to never rewrite in another language is that it
| requires you to stop everything else for months or even
| years. Stopping for two weeks is a lot less likely to kill
| your project.
| oblio wrote:
| He's still right if you don't have good automated testing
| and you lost most of the original developers (or you don't
| have other seniors ceva familiar with the domain).
| simonw wrote:
| Hah, yeah if you don't have a comprehensive test suite
| any rewrite will be a disaster - step one is to get the
| test suite up to code.
| ignoramous wrote:
| > _What 's different today really is the LLMs and coding
| agents._
|
| In Ladybird's case, tests they could rely upon.
| gaigalas wrote:
| > A startup switching languages after years of development is
| usually a big red flag.
|
| Startups are not a good comparison here. They have a different
| relationship with code than software projects.
|
| Linux has rewriten entire stacks over and over again.
|
| The PHP engine was rewritten completely at least twice.
|
| The musl libc had entire components rewritten basically from
| scratch and later integrated.
| jvillasante wrote:
| Exactly my thought! I guess I'll keep Firefox for the
| foreseeable future...
| einpoklum wrote:
| Firefox is already spying on you with a lot of telemetry, and
| they have recently amended their terms of use to remove the
| obligation to "never sell your data" [1]. So perhaps you
| should reconsider that statement.
|
| [1] : https://news.ycombinator.com/item?id=43213612
| tvshtr wrote:
| Surely nobody's using them forks which exist for no reason
| whatsoever.
| nicoburns wrote:
| A mitigating factor in this case is the C++ and Rust are both
| multi-paradigm languages. You can quite reasonably represent
| _most_ C++ patterns in Rust, even if it might not be quite how
| you 'd write Rust in the first place.
| array_key_first wrote:
| In addition, C++ and Rust are very, very similar languages.
| Almost everything in C++ translates easily, including low
| level stuff and template shenanigans. There's only a few "oh
| shit there's no analog" things, like template specialization
| or virtual inheritance.
|
| Out of all the languages rust takes inspiration from, id rank
| C++ at the top of the list.
| pornel wrote:
| Strong disagree. Rust copied C++ syntax to avoid looking
| weird to C++ programmers, but the similarity is skin deep.
| C can be tamed, because it's mostly a subset of Rust, but
| C++ idioms are a death from papercuts.
|
| OOP, weakly-typed templates, and mutable aliasing create
| impedance mismatch in almost every C++ API.
|
| Rust doesn't have data inheritance, and what looks like
| interface inheritance is merely extra requirements in a
| flat list of traits, so subclassing won't behave like C++
| APIs expect. When you translate a class hierarchy to Rust,
| it needs lots of crutches which make it weird,
| boilerplatey, and tedious to use. There's no good recipe
| for OOP hierarchy in Rust, because the idioms are so
| different. The mismatch feels like writing an ORM.
|
| For some C++ APIs mutability and circular references can be
| a pain too. Rust works well with DAG data structures and
| clear mostly-immutable data flow. Objects with some
| "parent" pointer are common in C++, but Rust sees them as
| potentially dangling, with shared mutable state, and
| requires much heavier control of them. It can be done, but
| it's ugly. Idiomatic Rust designs go to great lengths to
| avoid it unless necessary, but C++ APIs can have the extra
| pointers "for convenience".
|
| There's a reason why Rust doesn't have typical GUI
| libraries - an arbitrary web of references between widgets
| and event handlers make it ugly in Rust, and that's on top
| of a view class inheritance.
|
| C++ templates sit very uncomfortably between Rust's macros
| (duck typed) and Rust's generics (strictly typed at point
| of declaration).
|
| C++ templates almost always are a mix of types they're
| attached to and some duck-typing in their expansion.
|
| Rust's generics do not allow any duck typing at all. This
| makes translation of even a tiny bit clever C++ templates a
| chore. There's no specialization. No way to deal with
| SFINAE and such.
|
| Rust macros have flexibility for all the syntax shenanigans
| (and even similarly bad errors at instantiation time), but
| macros can't see any types. Idiomatic Rust has very
| deliberate division between traits (usually much simpler
| and smaller in scope), macros and proc macros/derives.
| Splitting C++ templates like that can be a major redesign.
| ozgrakkurt wrote:
| Spending weeks porting (presumably) working code with LLM is a
| bit strange
| blibble wrote:
| that's only the mechanical translation too
|
| the hard bit (borrow checker) has still to be done...
| renewiltord wrote:
| Twitter is the canonical startup rewrite. It worked.
| aero-glide2 wrote:
| Sigh agents keep killing all the passion I have for programming.
| It can do things way faster than me, and better than me in some
| cases. Soon it will do everything better and faster than me.
| apples_oranges wrote:
| It automates both the fun and the boring parts equally well.
| Now the job is like opening a box of legos and they fall out
| and then auto-assemble themselves into whatever we want..
| close04 wrote:
| Rather like opening a box of legos and reading them the
| instruction sheet while they auto assemble based on what they
| understood. Then you re-read and clarify where the assembly
| went wrong. Many times, if needed.
| airstrike wrote:
| Not sure why you'd get that from this post, which says it
| required careful small prompts over the course of weeks.
|
| In the hands of experienced devs, AI increases coding speed
| with minimal impact to quality. That's your differentiator.
| throwaway2027 wrote:
| It's the opposite for me, most of the time it's first rough
| pass it generates is awful and if you don't have good taste and
| a solid background of years of experience programming you won't
| notice it and I keep having to tell it to steer into better
| design choices.
| supriyo-biswas wrote:
| Is a migration from language X to Y or refactoring from pattern
| A to B really the kind of task that makes you look forward to
| your day when you wake up?
|
| Personally my sweet spot for LLM usage is for such tasks, and
| they can do a much better job unpacking the prompt and getting
| it done quickly.
|
| In fact, there's a few codebases at my workplace that are quite
| shit, and I'm looking forward to make my proposal to refactor
| these. Prior to LLMs, I'm sure I'd have been laughed off, but
| now it's much more practical to achieve this.
| nananana9 wrote:
| I'm not sure 25,000 lines translated in 2 weeks is "fast", for
| a naive translation between languages as similar as C++ and
| Rust (and Ladybird does modern RAII smart-pointer-y C++ which
| is VERY similar to Rust). You should easily be able to do 2000+
| lines/day chunks.
| OtomotO wrote:
| 2000+ lines/day chunks are 10 days for 20+k lines...
| nananana9 wrote:
| I'm aware. What I meant is this is a reasonable output for
| a 1:1 translation by hand, without LLM use.
| tonyedgecombe wrote:
| 2000 lines a day feels like a lot to me if you want to be
| thorough.
| nicoburns wrote:
| Yeah, it also a lot that the person doing the translation is
| the lead developer of the project who is very familiar with
| the original version.
|
| I imagine LLMs do help quite a bit for these language
| translation tasks though. Language translation (both human
| and programming) is one of the things they seem to be best
| at.
| camel-cdr wrote:
| Agreed, however, I'm quite sure 25,000 lines translated in
| "multiple months" is very "slow", for a naive translation
| between languages as similar as C++ and Rust.
| michaelcampbell wrote:
| "I will never be a world class athlete, so I play for the love
| of the sport."
|
| Helps me.
| pjmlp wrote:
| Look into platforms like Workato, Boomi, or similar iPaaS
| products, unfortunely it feels like those of us that like
| coding have to be happy turning into architect roles, with AI
| as brick layers.
| bigstrat2003 wrote:
| Despite the many claims to the contrary, agents can't do
| anything better than a human yet. Faster, certainly, but the
| quality is always poor compared to what a human would produce.
| You aren't obsolete yet, brother.
| storus wrote:
| Dunno, that probably doesn't hold for webapps with backend as
| they are typically complete garbage and LLMs (even local
| ones) would give you about the same result but in 1 hour.
| LeFantome wrote:
| > Soon it will do everything better and faster than me
|
| There is no evidence of that coming from this post. The work
| was highly directly by an extremely skilled engineer. As he
| points out, it was small chunks. What chunks and in what order
| were his decision.
|
| Is AI re-writing those chunks much faster than he could. Yes.
| Very much so. Is it doing it better? Probably not. So, it is
| mostly just faster when you are very specific about what it
| should do. In other words, it is not a competitor. It is a
| tool.
|
| And the entire thing was constrained by a massive test suite.
| AI did not write that. It does not even understand why those
| tests are the way they are.
|
| This is a long way from "AI, write me a JavaScript engine".
| rzerowan wrote:
| Id put it as a example of a carpenter preparing their
| material with a lathe and circular saw vs one working with a
| handsaw and chisel.
|
| Both will get a skilled craftsman to the point where thie
| output is a quality piece of work. Using the autotoools to
| prepare the inputs allows velocity and consistency.
|
| Main issue is the hype and skiddies who would say - feed this
| tree into a machine and get a cabinet.Producing non-
| detrministic outputs with the operator being unable to adjust
| requirements on the fly or even stray from patterns/designs
| that havent been trained yet.
|
| The tools have limitiations and the operators as well , and
| the hype does adisservice to what would be establishing
| reasonable patterns of usage and best practices.
| skerit wrote:
| > I used Claude Code and Codex for the translation. This was
| human-directed, not autonomous code generation. I decided what to
| port, in what order, and what the Rust code should look like. It
| was hundreds of small prompts, steering the agents where things
| needed to go. After the initial translation, I ran multiple
| passes of adversarial review, asking different models to analyze
| the code for mistakes and bad patterns. > The requirement from
| the start was byte-for-byte identical output from both pipelines.
| The result was about 25,000 lines of Rust, and the entire port
| took about two weeks. The same work would have taken me multiple
| months to do by hand. We've verified that every AST produced by
| the Rust parser is identical to the C++ one, and all bytecode
| generated by the Rust compiler is identical to the C++ compiler's
| output. Zero regressions across the board
|
| This is the way. Coding assistants are also really great at
| porting from one language to the other, especially if you have
| existing tests.
| giancarlostoro wrote:
| This is also how some of us use Claude despite what the haters
| say. You dont just go "build thing" you architect, review,
| refine, test and build.
| gnfargbl wrote:
| It's how _most_ of us are actually going to end up using AI
| agents for the foreseeable future, perhaps with increasing
| degrees of abstraction as we move to a teams-of-agents model.
|
| The industry hasn't come up with a simple meme-format term to
| explain this workflow pattern yet, so people aren't excited
| about it. But don't worry, we'll surely have a bullshit term
| for it soon, and managers everywhere will be excited. In the
| meantime, we can just continue doing work with these new
| tools.
| card_zero wrote:
| This is an opportunity to select some stupid words that you
| would like to hear repeated a million times. The process is
| like patiently nurturing a well-contained thing, so how
| about "egg coding"?
| DANmode wrote:
| How about "engineering"?
| mr_mitm wrote:
| I thought the term was "agentic engineering"
| simonw wrote:
| Yeah that's the top contender at the moment. I think it's
| pretty good.
| giancarlostoro wrote:
| I like "spec driven development" but I honestly don't
| care what you call it, just let me build things and leave
| me alone. :)
| newswasboring wrote:
| SDD is more like a subset. There are different ways to
| manage context in agentic engineering
| giancarlostoro wrote:
| I guess, I just know I force my agent to use a ticketing
| system like Beads (I made my own).
| DANmode wrote:
| > SDD
|
| Don't do _that_! On a two-day-old term?!
|
| No wonder we're called gatekeepers.
| newswasboring wrote:
| Ok jeez, calm down. I am not shouldering all of the AI
| discourse lol.
| DANmode wrote:
| ^_^
| viraptor wrote:
| I'm not sure there's going to be a term, because there's no
| difference from normal, good quality engineering. You
| iterate on design, validate results, prioritise execution.
| It's just that you hand over the writing code part. It's as
| boring as it gets.
| giancarlostoro wrote:
| I havent quite dealt with "teams of agents" yet outside of
| Claude Code itself spawning subagents, but I have some
| ideas as to how to achieve it in a meaningful way without
| giving a developer 10 claude code licenses, I think the
| real approach that makes more sense to me is to still have
| humans in the loop, but have their respective agents sync
| together and divide work towards one goal, but being able
| to determine which tasks are left to be worked one and
| tested. I do think for the foreseeable future you will need
| human validation for AI.
| gf000 wrote:
| https://youtu.be/JV-wY5pxXLo?si=ga-9Gg8IZfU6g8Tg
|
| It's vibe engineering
| gnfargbl wrote:
| This does not spark joy.
| latexr wrote:
| > how some of us
|
| Operative word being "some". The issue is that too many
| aren't doing it that way.
|
| > You dont just go "build thing"
|
| Tell that to the overwhelming majority of posters discussing
| vibe coding, including on HN.
| tonyedgecombe wrote:
| I suppose to some extent those people have always existed.
| The ones who would choose the most expedient solution.
|
| The difference now is they can get much further along.
| danielvaughn wrote:
| Sure, but they're going to be stuck writing software for
| yesterday's problems. As our tools become more powerful,
| we're going to unlock new problems and expectations that
| would be impossible or impractical to solve with
| yesterday's tooling.
| coldtea wrote:
| > _Sure, but they 're going to be stuck writing software
| for yesterday's problems_
|
| As long as they get paid for it (or have fun, if it's a
| personal project), they couldn't care less about that.
| Tomorrow's problems are overrated.
| philipallstar wrote:
| > despite what the haters say
|
| Thinking people who disagree with you hate you or hate the
| thing you like is a recipe for disaster. It's much better to
| not love or hate things like this, and instead just observe
| and come to useful, outcome-based conclusions.
| simonw wrote:
| LLMs really do attract haters in the classic sense though.
| You'll find them in almost every thread on here.
| jcgrillo wrote:
| They also attract grifters, frauds, conmen, snake oil
| peddlers, and every stripe of bullshit artist. I'm
| someone you probably would view as a hater, but I truly
| don't hate LLMs. I hate the lies. Projects like this are
| interesting, I wish there was a lot more of this and a
| lot less of the "trust me bro" stuff.
| giancarlostoro wrote:
| Look at any HN thread that has a project that uses AI in
| any way, shape or form. People quickly remark that it is
| slop, without even reviewing the code. If that's not blind
| hatred of AI, I don't know what is.
|
| There's a huge distinction between Vibe Coding, and actual
| software engineers using AI tooling effectively. I vibe
| code for fun sometimes too, nothing wrong with it, helps me
| figure out how the model behaves in some instances, and to
| push the limits of what I understand.
| mghackerlady wrote:
| Vibe Coding is like porn for programmers. It probably
| isn't good for you, and you'd probably be better off
| actually doing the thing yourself, but it feels good and
| satisfies our desires for instant gratification
| giancarlostoro wrote:
| Well, take for example, I have ideas I've had for years
| but no time for because by now the requirements are
| insane. I want to build a backend that could survive
| nuclear fallout type stuff. I braindump to Claude, watch
| it churn out my vision for the last 12 years, its insane.
|
| There's other things too though: my ADD and my impostor
| syndrome don't matter to Claude, Claude just takes it all
| in, so as I keep brain dumping, it keeps chugging along.
| I don't have to worry a bout "can I really do this?" it
| just does it and I can focus on "what can I do to make it
| better" essentially.
|
| For me it's beyond "porn coding" its basically fulfilling
| my vision that's been locked away for years but I've had
| no time to sit down and do it fully. I can tell Claude to
| do something, my kid comes up and asks me to go draw with
| them and I can actually just walk away and look at the
| output and refine.
| mghackerlady wrote:
| I never said it doesn't have use cases (much like porn a
| lot of the arguments against are just fear mongering)
| just that it isn't as good as the real thing. I myself
| like yapping to an LLM about ideas to see how feasible
| they actually are before taking a crack at it
| Sohcahtoa82 wrote:
| > People quickly remark that it is slop, without even
| reviewing the code.
|
| I absolutely hate how "slop" has lost its meaning.
|
| "AI slop" was supposed to mean poor-quality content
| that's obviously AI-generated. But the anti-AI crowd has
| co-opted it to mean _any_ AI-generated content,
| _regardless_ of quality. EDIT: Or even the _quantity_ of
| AI. Expedition 33 had a ton of critical acclaim and ended
| up winning tons of awards, yet once it was discovered
| that AI was used to generate some placeholder art, of
| which NONE of it was actually used in the final product,
| some people started labeling the game as AI slop. It 's
| utterly ridiculous.
|
| So now, we can't have conversations about AI slop without
| starting off with making sure everyone is on the same
| page on what the term even means.
|
| EDIT: "Vibe coding" is suffering a similar fate. If I use
| AI to write some code, and I examine the code to make
| sure it doesn't have any obvious bugs or security issues,
| is that still vibe coding?
| embedding-shape wrote:
| Agree, and it's also such a shame that none of the AI companies
| actually focus on that way of using AI.
|
| All of them are moving into the direction of "less human
| involved and agents do more", while what I really want is
| better tooling for me to work closer with AI and be better at
| reviewing/steering it, and be more involved. I don't want "Fire
| one prompt and get somewhat working code", I want a UX tailored
| for long sessions with back and forth, letting me leverage my
| skills, rather than agents trying to emulate what I already can
| do myself.
|
| It was said a long time ago about computing in general, but
| more fitting than ever, "Augmenting the human intellect" is
| what we should aim for, not replacing the human intellect. IA
| ("Intelligence amplification") rather than AI.
|
| But I'm guessing the target market for such tools would be much
| smaller, basically would require you to already understand
| software development, and know what you want, while all AI
| companies seem to target non-developers wanting to build
| software now. It's no-code all over again essentially.
| dsr_ wrote:
| Is it any surprise that the cocaine cartels really want you
| to buy more cocaine, so they don't focus on its usefulness in
| pain relief and they refine it and cut it with the cheapest
| substances that will work rather than medical-grade reagents?
|
| Same thing.
| embedding-shape wrote:
| It's surprising that the ones who are producing the
| cocaine, don't try to find the best use of the cocaine,
| yes. But then these are VC-fueled businesses, then it all
| goes out the window, unfortunately. Otherwise they'd
| actually focus on usefulness, not just "usage" or whatever
| KPI they go by and share with their investors.
| Barbing wrote:
| LLMs are drugs because they're addictive and sap your
| abilities, is it?
|
| (or generally: "Is the cocaine cartel comparison fair or
| unfair?")
| Thanemate wrote:
| >Agree, and it's also such a shame that none of the AI
| companies actually focus on that way of using AI.
|
| This is because, regardless of the current state of things,
| the endgame which will justify all the upfront investment is
| autonomous, self-improving, self-maintaining systems.
| freeopinion wrote:
| Of course there are tools focusing on this. It takes a little
| getting used to how prevalent it is. My editor now can
| anticipate the next three lines of code I intend to write
| complete with what values I want to feed to the function I
| was about to invoke. It all shows up in an autocomplete
| annotation for me. I just type the first two or three
| characters and press tab to get everything exactly how I was
| about to type it in--including an accurate comment worded
| exactly in my voice.
|
| Is that what you mean by IA?
|
| For example, I type "for" and my editor guesses I want to
| iterate over the list that is the second argument of the
| function for which I am currently building the body. So it
| offers to complete the rest of the loop condition for me. Not
| only did it anticipate that I am writing a for loop. It
| figures out what I want to iterate over, and perhaps even
| that I want to enumerate the iteration so I have the index
| and the value. Imagine if I had written a comment to explain
| my intent for the function before I started writing the
| function body. How much better could it augment my intellect?
| embedding-shape wrote:
| To be honest, I'm not quite sure what the ideal UX looks
| like yet. The AI assisted autocomplete is too little, but
| the idea of saying "Build X for purpose Y" is too high-
| level. Maintaining Markdown documents that the AI
| implements, also feels too high-level, but letting the
| human fully drive the implementation probably again too
| low-level.
|
| I'm guessing the direction I'd prefer, would be tooling
| built to accept and be driven by humans, but allowed to be
| extended/corrected by AI, or something like that, maybe.
|
| Maybe a slight contradiction, and very wish-washy/hand-
| wavey, but I haven't personally quite figured out what I
| think would be best yet either, what the right level
| actually is, so probably the best I could say right now :)
| Sorry!
| zozbot234 wrote:
| The Markdown documents can be at any level. Just keep
| asking the AI to break each individual step in the plan
| down into substeps, then ask it to implement after you
| review. It's great for the opposite flow too - reverse
| engineering from working legacy code into mid-level and
| high-level designs, then proposing good refactors.
| embedding-shape wrote:
| Yes, I'm talking about a UX that could handle that for
| the programmer instead, as an example. Zoom out a bit :)
| Barbing wrote:
| Still magical a few years in?
|
| >Imagine if I had written a comment to explain my intent
| for the function before I started writing the function
| body.
|
| This in particular is not dissimilar from opening a chat
| with a model and giving it a prompt as usual but then
| adding at the end:
|
| _Begin your response below:_ { func
| jibal wrote:
| Which editor?
|
| > Imagine if I had written a comment to explain my intent
| for the function before I started writing the function
| body.
|
| The loon programming language (a Lisp) has "semantic
| functions", where the body is just the doc comment.
| eikenberry wrote:
| I think this could be a decent interface with one addition,
| a way to comment on the completion being suggested. You
| could ask it for a different completion or to extend the
| completion, do something different, do a specific thing,
| whatever. An active way to "explain my intent" with the AI
| (besides leaving comments hinting at what you want) in
| addition to the passive completion system.
| mghackerlady wrote:
| I think it was Steve Jobs who said computers should be like a
| bicycle for the mind, I tend to agree
| embedding-shape wrote:
| Yeah, Douglas Engelbart was also a huge believer in that,
| and I think from various stuff I've read from him and the
| Augmentation Research Center put me on this track of really
| agreeing with it.
|
| "Bicycle for the mind", as always when it involves Jobs,
| sounds more fitting for the masses though, so thanks for
| sharing that :)
| axus wrote:
| Agents are a "self-driving car for the mind". I don't enjoy
| or dislike driving, but lots of Americans love to drive. In
| the future they will lament their driving skills' decline.
| ivell wrote:
| We as the general population have consistently lost lots
| of skills from just 200 years back. Most likely we will
| not miss them (though coding used to be my hobby).
|
| Though if apocalypse happens and all of our built tech
| goes away, we are in for a serious survival issu.
| Barrin92 wrote:
| >Most likely we will not miss them
|
| given that we've also lost the faculty to look at the
| past with anything other than contempt most people
| wouldn't even know what they miss. The little problem
| with losing the 'general cognition' department, just like
| broad social or cultural decline is that you lose the
| ability to even judge what you're losing, because the
| thing you just lost was doing the judging
| jcgrillo wrote:
| I love this Jobs quote for two reasons:
|
| (1) It captures the ideal so well
|
| (2) The bitter irony of how thoroughly pre-OS X Macintosh
| computers failed to live up to it
|
| I feel like there's a similar dichotomy in LLM tools now
| blibble wrote:
| > Agree, and it's also such a shame that none of the AI
| companies actually focus on that way of using AI.
|
| their valuations are replaced on getting rid of you entirely,
| along with everyone else
|
| the "humans can use it to increase their productivity" is an
| interim step
| JetSetIlly wrote:
| "All of them are moving into the direction of "less human
| involved and agents do more", while what I really want is
| better tooling for me to work closer with AI and be better at
| reviewing/steering it, and be more involved."
|
| I want less ambitious LLM powered tools than what's being
| offered. For example, I'd love a tool that can analyse
| whether comments have been kept up to date with the code they
| refer to. I don't want it to change anything I just want it
| to tell me of any problems. A linter basically. I imagine
| LLMs would be a good foundation for this.
| refsys wrote:
| Any terminal tool like Claude Code or Codex (I assume
| OpenCode too, but I haven't tried) can do it, by using as a
| prompt pretty much exactly what you wrote, and if it still
| wants to edit, just don't approve the tool calls.
|
| One problem I've noticed is that both claude models and
| gpt-codex variants make absolutely deranged tool calls
| (like `cat <<'EOF' >> foo...EOF` pattern to create a file,
| or sed to read a couple lines), so it's sometimes hard to
| see what is it even trying to do.
| vunderba wrote:
| I'm glad I'm not the only one who's noticed these
| seemingly arbitrary calls to write files using the cat
| command instead of the native file edit capabilities of
| the agent.
| JetSetIlly wrote:
| "Any terminal tool like Claude Code or Codex (I assume
| OpenCode too, but I haven't tried) can do it, by using as
| a prompt pretty much exactly what you wrote, and if it
| still wants to edit, just don't approve the tool calls."
|
| I'm sure it can. I'd still like a single use tool though.
|
| But that's just my taste. I'm very simple. I don't even
| use an IDE.
|
| edit: to expand on what I mean. I would love it if there
| was a tool that has conquered the problem and doesn't
| require me to chat with it. I'm all for LLMs helping and
| facilitating the coding process, but I'm so far
| disappointed in the experience. I want something more
| like the traditional process but using LLMs to solve
| problems that would be otherwise difficult to solve
| computationally.
| otikik wrote:
| I am learning rust myself and one of the things I definetly
| didn't want to do was let Claude write all the code. But I
| needed guidance.
|
| I decided to create a Claude skill called "teach". When I
| enable it, Claude never writes any code. It just gives me hints
| - progressively more detailed if I am stuck. Then it reviews
| what I write.
|
| I am finding it very satisfying to work this way - Rust in
| particular is a language where there's little space to "wing
| it". Most language features are interlaced with each other and
| having an LLM supporting me helps a lot. "Let's not declare a
| type for this right now, we would have to deal with several
| lifetime issues, let's add a note to the plan and revisit this
| later".
| philipportner wrote:
| FYI: Claude has output styles, one of them is called
| `learning`. Instead of writing the code itself, it will add
| `TODO(human)` and comments to explain how to. Also adds
| `Insights` explaining concepts to you in its output.
|
| This link also has a comparison to Skills further down.
|
| https://code.claude.com/docs/en/output-styles#built-in-
| outpu...
| nu11ptr wrote:
| Quite good. I ported my codebase from Go to Rust in a fraction
| of the time it would have taken me to rewrite it.
| patates wrote:
| > Coding assistants are also really great at porting from one
| language to the other
|
| I had a broken, one-off Perl script, a relic from the days when
| everyone thought Drupal was the future (long time ago). It was
| originally designed to migrate a site from an unmaintained
| internal CMS to Drupal. The CMS was ancient and it only ran in
| a VM for "look what we built a million years ago" purposes (I
| even had written permission from my ex-employer to keep that
| thing).
|
| Just for a laugh, I fed this mess of undeclared dependencies
| and missing logic into Claude and told it to port the whole
| thing to Rust. It spent 80 minutes researching Drupal and
| coding, then "one-shotted" a functional import tool. Not only
| did it mirror the original design and module structure, but it
| also implemented several custom plugins based on hints it found
| in my old code comments.
|
| It burned through a mountain of tokens, but 10/10 - would
| generate tens of thousands of lines of useless code again.
|
| The Epilogue: That site has since been ported to WordPress,
| then ProcessWire, then rebuilt as a Node.js app. Word on the
| street is that some poor souls are currently trying to port it
| to Next.js.
| josephg wrote:
| > 10/10 - would generate tens of thousands of lines of
| useless code again.
|
| Me too! A couple days ago I gave claude the JMAP spec and
| asked it to write a JMAP based webmail client in rust from
| scratch. And it did! It burned a mountain of tokens, and its
| got more than a few bugs. But now I've got my very own email
| client, powered by the stalwart email server. The rust code
| compiles into a 2mb wasm bundle that does everything client
| side. Its somehow insanely fast. Honestly, its the fastest
| email client I've ever used by far. Everything feels instant.
|
| I don't need my own email client, but I have one now. So
| unnecessary, and yet strangely fun.
|
| Its quite a testament to JMAP that you can feed the RFC into
| claude and get a janky client out. I wonder what semi-useless
| junk I should get it to make next? I bet it wouldn't do as
| good a job with IMAP, but maybe if I let it use an IMAP
| library someone's already made? Might be worth a try!
| metabeard wrote:
| Please post this. I'd love to play with it and, especially,
| see how fast it is.
| mr_mitm wrote:
| Same here. I had Claude write me a web based RSS feed
| reader in Rust. It has some minor glitches I still need to
| iron out, but it works great, is fast as can be, and is
| easy on the eyes.
|
| https://github.com/AdrianVollmer/FluxFeed
| echelon wrote:
| Rust is the final language.
|
| Defect free. Immaculate types. Safe. Ergonomic. Beautiful
| to read.
|
| AI is going to be writing a lot of Rust.
|
| The final arguments of "rust is hard to write" are going
| to quiet down. This makes it even more accessible.
| tekne wrote:
| Needs monads (not joking)
| lproven wrote:
| > Rust is the final language.
|
| I honestly can't tell if this is a humorous attack or
| not.
|
| Poe's law is validated once again.
| echelon wrote:
| It's honest. If we can serialize our ideas to any
| language for durability, Rust is the way to go.
|
| It's not the best tool for the job for a lot of things,
| but if the LLMs make writing it as fast as anything else
| - whelp, I can't see any reason not to do it in Rust.
|
| If you get any language outputs "for free", Rust is the
| way to go.
|
| I've been using Claude to go ridiculously fast in Rust
| recently. In the pre-LLM years I wrote a lot of Rust, but
| it definitely was a slow to author language. Claude helps
| me produce it as fast as I can think. I spend most of my
| time reviewing the code and making small fixes and
| refactors. It's great.
| klsdjfdlkfjsd wrote:
| I'll just stick with C as my lingua franca, and won't be
| involving Microsoft in my programming life, thanks.
| tcfhgj wrote:
| are you implying that using Rust involves using MS
| products?
| jibal wrote:
| > It's honest.
|
| It's not, nor is it well informed. People are currently
| developing languages specifically for use by LLMs.
|
| > It's not the best tool for the job for a lot of things
|
| Then how could it possibly be the final language?
|
| > if the LLMs make writing it as fast as anything else -
| whelp, I can't see any reason not to do it in Rust
|
| This has nothing to do with the claim that it's the final
| language.
| hathawsh wrote:
| While Rust is excellent, you must acknowledge that Rust
| has issues with compilation time. It also has a steep
| learning curve (especially around lifetimes.) It's much
| too early to say Rust is the "final" language, especially
| since AI is driving a huge shift in thinking right now.
|
| I used to think that I would never write C code again,
| but when I decided recently to build something that would
| run on ESP32 chips, I realized there wasn't any good
| reason for me to use Rust yet. ESP-IDF is built on C and
| I can write C code just fine. C compiles quickly, it's a
| very simple language on the surface, and as long as you
| minimize the use of dynamic memory allocation and other
| pitfalls, it's reliable.
| 0x457 wrote:
| If you're programming for ESP, then embassy is the way to
| go in most cases. You don't need to learn much about
| lifetimes in most of the application code. Steep learning
| curve people refer it is "thing blow up at compile time
| vs runtime." It's easy to write JS or C that passes all
| tests and compiles and then wonderful blows up when you
| start using it. It just forces you to learn things you
| need to know at IMO right now.
|
| My biggest problem with rust right now is enormous
| target/ dirs.
| JoshTriplett wrote:
| > My biggest problem with rust right now is enormous
| target/ dirs.
|
| We're working on that and it should get better soonish.
| We're working on shared caches, as well as pruning of old
| cached builds of dependencies that are unlikely to be
| reused in a future build.
| tmtvl wrote:
| > _Beautiful to read._
|
| Oh my, there's a new language called Rust? Didn't they
| know there already is one? The old one is so popular that
| I can't imagine the nicely readable one to gain any
| traction whatsoever (even if the old one is an assault on
| the senses).
| ikety wrote:
| Why not go full functional programming at that point? If
| the main issue with FP has been accessibility, then it
| should really take off now.
| zozbot234 wrote:
| When you do fully value-oriented programming in Rust
| (i.e. no interior mutability involved) that's essentially
| functional programming. There's mutable, ephemeral data
| involved, but it's always confined to a single well-
| defined context and never escapes from it. You can even
| have most of your code base be sans-IO, which is the
| exact same pattern you'd use in Haskell.
| theLiminator wrote:
| I actually like rust more than Haskell, but `You can even
| have most of your code base be sans-IO, which is the
| exact same pattern you'd use in Haskell.` glosses over
| the fact that in Haskell it's enforced at compile time.
| jimbokun wrote:
| Isn't Rust a pretty good functional language? It has most
| of the features that enable safe, correct code without
| being anal about immutability and laziness that make
| performance difficult to predict.
| tehnub wrote:
| I wouldn't because idiomatic Haskell is way slower than
| idiomatic Rust.
| the__alchemist wrote:
| I would say it's overall the best existing language,
| probably due to learning from past mistakes. On the whole
| it wins via the pro/con sum. But ... Still loads of room
| for improvement! Far from a perfect lang; just edges out
| the _existing_ alternatives by a bit.
| johnebgd wrote:
| Sometimes I forget programming languages aren't a
| religion, and then I see someone post stuff like this.
| Programming languages really do inspire some of us to
| feel differently.
| vovavili wrote:
| I'd say that it's taking much needed steps to achieve
| perfection but many more steps are there ahead. The next
| language closer to perfection would definitely have a
| much gentler introduction curve, among other things.
| DANmode wrote:
| Which coding assistant do you think needs a gentle
| introduction curve?
| JoshTriplett wrote:
| > Rust is the final language.
|
| > Defect free.
|
| I am an upstream developer on the Rust Project (lang,
| library, cargo, others), and obviously a big fan of Rust.
| _This_ kind of advocacy doesn 't help us, and in fact
| makes our jobs _harder_ , because for some people this
| kind of advocacy is their main experience of people they
| assume are representative of Rust. Please take it down a
| notch.
|
| I think Rust is the best available language for many
| kinds of problems. Not yet all, but we're always
| improving it to try to work for more people. It gets
| better over time. I'd certainly never call it, or almost
| any other software, "defect free".
|
| And I'd never call it "the final language"; we're
| building it to last the test of time, and we hope things
| like the edition system mean that the successor to Rust
| is a future version of Rust, but things can always
| change, and we're not the only source of great ideas.
|
| If you genuinely care about Rust, please adjust your
| advocacy of Rust to avoid hurting Rust and generating
| negative perceptions of Rust.
| estebank wrote:
| As a member of t-compiler, seconded.
| jacquesm wrote:
| Thank you, thank you, thank you.
| josephg wrote:
| I'd also add: as a lover of forward progress, I really
| hope rust isn't the last good idea programming language
| designers have. I love rust. But there are dozens of
| things I find a bit frustrating. Unfortunately I don't
| think I'm clever & motivated enough to write a whole new
| language to try to improve it. But I really hope someone
| else is!
|
| For a taste: I wish we didn't need lifetime annotations,
| somehow. I wish rust had first class support for self
| borrows, possibly via explicit syntax indicating that a
| variable is borrowed, and thus pinned. Unpin breaks my
| brain, and I wish there were ways to do pin projections
| without getting a PhD first. I wish for async streams. I
| wish async executors were in std, and didn't take so long
| to compile. I could go on and on.
|
| I feel like there's an even simpler & more beautiful
| language hiding inside rust. I can't quite see it. But I
| really hope someone else can bring it into the world some
| day.
| basch wrote:
| Rust may be the darling of the moment, but Erlang is oft
| slept on.
|
| As AI makes human-readable syntax less relevant, the
| Erlang/Elixir BEAM virtual machine is an ideal
| compilation target because its "let it crash" isolated
| process model provides system-level fault tolerance
| against AI logic errors, arguably more valuable than
| Rust's strict memory safety.
|
| The native Actor Model simplifies massive concurrency by
| eliminating shared state and the complex thread
| management. BEAM's hot code swapping capability also
| enables a continuous deployment where an AI can
| dynamically rewrite and inject optimized functions
| directly into live applications with zero downtime.
|
| Imagine a future where an LLM is constantly monitoring
| server performance, profiling execution times, and
| dynamically rewriting sub-optimal functions in real-time.
| With Rust, every optimization requires a recompile and a
| deployment cycle that interrupts the system.
|
| Finally, Erlang's functional immutability makes
| deterministic AI reasoning easier, while its built-in
| clustering replaces complex external infrastructure,
| making it a resilient platform suited for automated
| iteration.
| chwtutha wrote:
| Haha glad to see someone else did something like this. A
| couple weeks ago I asked Claude to recommend a service
| that would allow me to easily view a local .xml file as
| an RSS feed. It instead built a .html RSS viewer.
| srcreigh wrote:
| Re "is fast as can be": in my experience generating C/Zig
| code via Codex, agent generated code is usually several
| multiples slower than hand optimized code.
| LoganDark wrote:
| Given parent and GP are both using Claude... have you
| tried Claude? (I say this as someone who has not tried
| Claude recently. I did try Claude Code when it first came
| out, though.)
| srcreigh wrote:
| First, it is important for these discussions that people
| include details like I did. We're all better off to not
| generalize.
|
| RE: Claude Code, no I haven't used it, but I did do the
| Anthropic interview problem, beating all of Anthropic's
| reported Claude scores even with custom harnesses etc.
|
| It's not a dunk that agents can't produce "as fast as can
| be" code; their code is usually still reasonably fast;
| it's just often 2-10x slower than can be.
| josephg wrote:
| Yeah, I'm sure my Claude generated email client could be
| even faster if I wrote it by hand. Modern computers can
| retire billions of instructions per second per core. All
| operations that aren't downloading or processing
| gigabytes of data should be instant on modern computers.
|
| Claude's toy email client gets closer to the speed limit
| than Gmail does. Why is Gmail so slow? I have no idea.
| grey-area wrote:
| Just curious, does it look anything like this library?
|
| https://docs.rs/jmap-client/latest/jmap_client/
| therein wrote:
| Also curious why would one be proud of having an LLM
| rewrite something that there is already a library for. I
| personally feel that proud LLM users boasting sounds as
| if they are on amphetamines.
| josephg wrote:
| It made a webmail client. Not a jmap library.
| grey-area wrote:
| Not sure I understand, wouldn't a webmail client in rust
| need client code like this or to use a library like this?
| josephg wrote:
| Yeah but it's like saying, "why are you impressed with
| Claude making a car when there are plans for an engine
| online?". Even if Claude used that code (it didn't), it
| made the whole car. Not just an engine. There's a lot
| more stuff going on than simply calling a backend mail
| server over jmap.
|
| And fyi, jmap is just a protocol for doing email over
| json & http. It's not that hard to roll your own.
| Especially in a web browser.
| soperj wrote:
| Can you release it as open source code?
| josephg wrote:
| Sure; I'll throw it online in a few hours when I'm at my
| computer.
| mjrpes wrote:
| Did you use dioxus? I had claude write up a test web app
| with it, but when attempting to use a javascript component
| it built it couldn't get past memory access out of bound
| errors.
| tasuki wrote:
| > a relic from the days when everyone thought Drupal was the
| future (long time ago).
|
| Drupal _is_ the future. I never really used it properly, but
| if you fully buy into Drupal, it can do most everything
| without programming, and you can write plugins (extensions?
| whatever they 're called...) to do the few things that do
| need programming.
|
| > The Epilogue: That site has since been ported to WordPress,
| then ProcessWire, then rebuilt as a Node.js app. Word on the
| street is that some poor souls are currently trying to port
| it to Next.js.
|
| This is the problem! Fickle halfwits mindlessly buying into
| whatever "next big thing" is currently fashionable. They
| shoulda just learned Drupal...
| patates wrote:
| I'm not sure if you're serious or not, but while I never
| liked Drupal (even used to hate it once upon a time), I
| always liked the pragmatism surrounding it, reaching to the
| point of saving php code into the mysql database and
| executing from there.
| Twirrim wrote:
| > reaching to the point of saving php code into the mysql
| database and executing from there.
|
| Wordpress loves to shove php objects into the database
| (been a good long while since I used it, don't remember
| the mechanism, it'd be the equivalent of `pickle` in
| python, only readable by php).
|
| Not sure if they've improved it since I last dealt with
| it about 15 years ago, but at the time there was no way
| to have a full separated staging and production
| environment, lots of the data stored in the database that
| way had hardcoded domain names built into it. We needed
| to have a staging and production kind of set-up, so we
| ended up having to write a PHP script that would dump the
| staging database, fix every reference, and push it to
| production. Fun times.
| rovr138 wrote:
| There's implode() and explode() as well as serialize()
| and unseralize()
|
| No idea what's used in wordpress, but back in D6 and
| before, it was common to see it when it would store
| multiple values for an instance.
| oblio wrote:
| > It burned through a mountain of tokens, but 10/10 - would
| generate tens of thousands of lines of useless code again.
|
| Pardon me, and, yes, I know we're on HN, but I guess
| you're... rich? I imagine a single run like this probably
| burns through tens or hundreds of dollars. For a joke,
| basically.
|
| I guess I understand why some people really like AI :-)
| patates wrote:
| It was below 100$, but only after burning through the 20x
| max session limit.
| ErikBjare wrote:
| The subsidized Codex/Claude subscriptions make it not so
| bad.
| pjmlp wrote:
| There are plenty of SMEs trapped into that future. :)
| uyzstvqs wrote:
| > It burned through a mountain of tokens, but 10/10 - would
| generate tens of thousands of lines of useless code again.
|
| This is the biggest bottleneck at this point. I'm looking
| forward to RAM production increasing, and getting to a point
| where every high-end PC (workstation & gaming) has a
| dedicated NPU next to the GPU. You'll be able to do this kind
| of stuff as much as you want, using any local model you want.
| Run a ralph loop continuously for 72 hours? No problem.
| Sharlin wrote:
| Wasting electricity to "generate tens of thousands of lines
| of useless code" at will? Why is that in any way a
| desirable future?
| Barbing wrote:
| Optimists will imagine it to one day be as taxing and
| thus as wasteful as firing up MS Paint.
|
| No that's a stretch, but firing up a AAA game.
| Sharlin wrote:
| At least you (hopefully) get hours of entertainment from
| firing up an AAA game. Whereas generating vast amounts of
| code that you're never going to use has... some novelty
| value, I suppose. Luckily the novelty is going to wear
| off soon, I can't really see many people getting their
| daily happiness boost from making code machine say brrrrt
| straight to /dev/null. Even generating smut is a vastly
| more understandable (and vastly more commonplace, even
| now) use case for running genAI every day for hours.
| embedding-shape wrote:
| > I can't really see many people getting their daily
| happiness boost from making code machine say brrrrt
| straight to /dev/null
|
| How long time do we have to wait before these people get
| bored? Or might they actually find what they generate
| useful and it doesn't all go straight to /dev/null, since
| seemingly it seems to gain usage, not drop in usage?
| hathawsh wrote:
| A lot of code is "useless" only in the sense that no one
| wants to buy it and it will never find its way into an
| end user product. On the other hand, that same code might
| have enormous value for education, research, planning,
| exploration, simulation, testing, and so on. Being able
| to generate reams of "useless" code is a highly desirable
| future.
| Sharlin wrote:
| Obviously "useful" doesn't just involve making money.
| Code that will be used for education and all of these
| things is clearly not useless.
|
| But let's be honest to ourselves, the sort of useless
| code the GP meant will never ever be used for any of
| that. The code will never leave their personal storage.
| In that sense it's about as valuable for the society at
| large as the combined exabytes of GenAI smut that people
| have been filling their drives with by running their
| 4090s 24/7.
| shoobiedoo wrote:
| The climate change alarms have been sounding for decades
| and yet vehicles keep getting bigger. Even in formerly
| "doing it right" countries like Japan. Turns out humans
| will always choose vanity and status symbols over facts.
| Oh well
| flatline wrote:
| One person's waste is another's value. Do you have any
| idea how "wasteful" tik tok or any other streaming
| platform is? I'll grant that AI is driving unprecedented
| data center development but it's far from the root cause,
| or even a leading clause, of our climate issues. I always
| find it strange that _this_ is the first response so many
| have to AI, when it poses other more imminent existential
| threats IMO.
| Sharlin wrote:
| It was a reply to what the GP said about running local
| generation 24/7 for no good reason, just because it's
| possible (and electricity is too cheap, apparently).
| There are many more threats, but those are beside the
| point in this specific context.
| LoganDark wrote:
| I bet RAM production will only increase to meet AI demand
| and there will be none left for you. Or me. Or anyone.
| Crucial is already going probably forever and I'm sure more
| will follow...
| polyterative wrote:
| I am having immense success with the latest models developing a
| personal project that I open sourced and then got burned off
| by.I can't write anymore by hands but I do enjoy writing
| prompts with my voice.I have been shipping the best code the
| project has ever seen.The revolution is real.
| staticassertion wrote:
| I had a script in another language. It was node, took up >200MB
| of RAM that I wanted back. "claude, rewrite this in rust".
| 192MB of memory returned to me.
| zozbot234 wrote:
| Solving the big RAM shortage one prompt at a time.
| ricardobeat wrote:
| This is sad to see. Node was originally one of the memory
| efficient options - it's roots are solving the c10k problem.
| Mind sharing what libraries/frameworks you were using?
| staticassertion wrote:
| It was an express server. I don't think c10k is
| particularly interesting since it mostly just involves
| having cooperating scheduling. Doesn't really impact flat
| memory overhead etc. I mean, the binary for node alone,
| without any libraries etc, is larger than the produced rust
| binary.
| vunderba wrote:
| I used to have a bunch of bespoke node express server
| utilities that I liked to keep running in the background to
| have access to throughout the day but 40-50mb per process
| adds up quickly.
|
| I've been throwing codex at them and now they've all been
| rewritten in Go - cut down to about 10mb per process.
| codegladiator wrote:
| > This was human-directed, not autonomous code generation.
|
| All my vibe coded projects are human directed, unless
| explicitly stated otherwise
| Aurornis wrote:
| Coding assistants are great at pattern matching and pattern
| following. This is why it's a good idea to point them at any
| examples or demos that come with the libraries you want to use,
| too.
| bee_rider wrote:
| I haven't done a ton of porting. And when I did, it was more
| like a reimplementation.
|
| > We've verified that every AST produced by the Rust parser is
| identical to the C++ one, and all bytecode generated by the
| Rust compiler is identical to the C++ compiler's output.
|
| Is this a conventional goal? It seems like quite an
| achievement.
| tinco wrote:
| My company helps companies do migrations using LLM agents and
| rigid validations, and it is not a surprising goal. Of course
| most projects are not as clean as a compiler is in terms of
| their inputs and outputs, but our pitch to customers is that
| we aim to do bug-for-bug compatible migrations.
|
| Porting a project from PHP7 to PHP8, you'd want the exact
| same SQL statements to be sent to the server for your test
| suite, or at least be able to explain the differences.
| Porting AngularJS to Vue, you'd want the same backend
| requests, etc..
| adw wrote:
| It's a very good way of getting LLMs to work autonomously for
| a long time; give it a spec and a complete test suite, shut
| the door; and ask it to call you when all the tests pass.
| dwood_dev wrote:
| I had a bash spaghetti code script that I wrote a few years ago
| to handle TLS certificates(generate CSRs, bundle up trust
| chains, match keys to certs, etc). It was fragile, slow,
| extremely dependent on specific versions of OpenSSL, etc.
|
| I used Claude to rewrite it in golang and extend its features.
| Now I have tests, automatic AIA chain walking, support for all
| the DER and JKS formats, and it's fast. My bash script could
| spend a few minutes churning through a folder with certs and
| keys, my golang version does a few thousand in a second.
|
| So I basically built a limited version of OpenSSL with better
| ergonomics and a lot of magic under the hood because you don't
| have to specify input formats at all. I wasn't constrained by
| things like backwards compatibility and interface stability,
| which let me make something much nicer to use.
|
| I even was able to build a wasm version so it can run in the
| browser. All this from someone that is not a great coder. Don't
| worry, I'm explicitly not rolling my own crypto.
| hsaliak wrote:
| This is the way. This exact workflow is my sweet spot.
|
| In my coding agent std::slop I've optimized for this workflow
| https://github.com/hsaliak/std_slop/blob/main/docs/mail_mode...
| basically the idea is that you are the 'maintainer' and you get
| bisect safe, git patches that you review (or ask a code
| reviewer skill or another agent to review). Any change re-rolls
| the whole stack. Git already supports such a flow and I added
| it to the agent. A simple markdown skill does not work because
| it 'forgets'. A 'github' based PR flow felt too externally
| dependent. This workflow is enforced by a 'patcher' skill, and
| once that's active, tools do not work unless they follow the
| enforced flow.
|
| I think a lot of people are going to feel comfortable using
| agents this way rather than going full blast. I do all my
| development this way.
| tarasglek wrote:
| your patch queue approach is very clever. Solves a huge tech
| debt poblem with llm code gen. Should work with jujitsu too
| probably.
|
| Would be curious to see more about how you save tokens with
| lua too.
|
| Do you blog?
| hsaliak wrote:
| Thanks for your interest in this work - I do not blog(maybe
| I should?) but i have posted a bit more on X about this
| work.
|
| - A bit more on mail mode
| https://x.com/hsaliak/status/2020022329154420830
|
| - on the Lua integration
| https://x.com/hsaliak/status/2022911468262350976 (I've
| since disabled the recursion, not every code file is long
| and it seems simpler to not do it), but the rest of it is
| still there
|
| - hotwords for skill activation
| https://x.com/hsaliak/status/2024322170353037788
|
| Also /review and /feedback. /feedback (the non code
| version) opens up the LLM's last response in an editor so
| you can give line by line comments. Inspired by "not top
| posting" from mailing lists.
| scuff3d wrote:
| We keep seeing this pattern over and over as well. Despite LLM
| companies' almost tangible desperation to show that they can
| replace software engineers, the real value comes from domain
| experts using the tools to enhance what they're already good
| at.
| nz wrote:
| How does he solve the Fruit of the Poison Tree problem? For all
| he know, his LLMs included a bunch copyrighted or patented code
| throughout the codebase. How is he going to convince serious
| people that this port is not just a transformation of an
| _asset_ into a _liability_?
|
| And you might say that this is a hypothetical problem, one that
| is not practically occurring. Well, we had a similar problem
| like this in the recent past, that LLMs are close to _making
| actual_. When it comes to software patents, they were
| considered a _hypothetical_ problem (i.e. nobody is going to
| bother suing you unless you were so big that violating a patent
| was a near certainty). We were instructed (at pretty much all
| jobs), to never read patents, so that we cannot incriminate
| ourselves in the discovery process.
|
| That is going to change soon (within a year). I have friend,
| whom I won't name, who is working on a project, using LLMs, to
| discover whether software (open source and proprietary) is
| likely to be violating a software patent from a patent
| database. And it is designed to be used, not by programmers,
| but by law firms, patent attorneys, etc. Even though it is not
| marketed this way, it is essentially a target acquisition
| system for use by patent trolls. It is hard for me to tell if
| this means that we will have to keep ignoring patents for that
| plausible deniability, or if this means that we will have to
| become hyper informed about all patents. I suppose, we can just
| subscribe to the patent-agent, and hope that it guides the
| other coding agents into avoiding the insertion of potentially
| infringing code.
|
| (I also have a friend who built a system in 2020 that could
| translate between C++ and Python, and guarantee equivalent
| results, and code that looks human-written. This was a very
| impressive achievement, especially because of how it guarantees
| the equivalence (it did not require machine-learning nor GPUs,
| just CPUs and some classic algorithms from the 80s). The friend
| informs me that they are very disheartened to see that now any
| toddler with a credit card can mindlessly do something similar,
| invalidating around a decade of unpublished research. They tell
| me that it will remain unpublished, and if they could go back
| in time, they would spend that decade extracting as much
| surplus from society as possible, by hook or by crook
| (apparently they had the means and the opportunity, but lacked
| the motive); we should all learn from my friend's mistake. The
| only people who succeed are, sadly, perversely, those who
| brazenly and shamelessly steal -- and make no mistake, the AI
| companies are built on theft. When millionaires do it, they
| become billionaires -- when Aaron Swartz does it, he is
| sentenced to federal prison. I'm not quite a pessimist yet, but
| it really is saddening to watch my friend go from a passionate
| optimist to a cold nihilist.).
| DANmode wrote:
| One or both of you have the story very wrong.
|
| If there was value (the guarantees) to this tech he buried a
| bunch of time in, he should be wrapping a natural language
| prompt around it and selling it.
|
| Not even the top providers are giving any sort of tangible
| safety or reliability guarantees in the enterprise...
| einpoklum wrote:
| > _Coding assistants are also really great at porting from one
| language to the other_
|
| No, they are quite terrible at doing that.
|
| They may (I guess?) produce code that compiles, but they will,
| almost certainly not produce the appropriate combination of
| idioms and custom abstractions that may the code "at home" in
| the target language.
|
| PS - Please fix your blockquote... HN ignores single
| linebreaks, so you have to either using pairs of them, or
| possibly go with italicization of the quoted text.
| ocd wrote:
| I am unsure if I can rationally justify saying this, but I am
| left with disappointment and unease. Comparable to when a series
| I care about changes showrunner and jumps the shark.
| OtomotO wrote:
| Maybe you're part of an anti-cult-cult?
|
| Would be as bad as being in a cult.
| nz wrote:
| Hate to tell you this, but it's cults all the way down. Plato
| understood this, and his disdain for caves and wall-shadows,
| is really a disdain for cults. The thing is, over the last
| 2300 years, we have gotten really good at making our caves
| super cozy -- much cozier than the "real world" could ever
| be. Our wall-shadows have become theme parks, broadway
| theaters, VR headsets, youtube videos, books, entire cities
| even. In Plato's day, it made sense to question the cave, to
| be suspicious of it. But today, the cave is not just at
| parity with reality, it is superior to it (similar to how a
| video game is a precisely engineered experience, one that
| never has too little signal and never has too much noise, the
| perfect balance to keep you interested and engaged).
|
| I'm no mind reader, and certainly no anthropologist, but I
| suspect that what separates humans from other (non extinct)
| animals, is that we compulsively seek caves that we can
| decorate with moving shadows and static symbols. We even
| found a series of prime numbers (sequences of dots, ". ...
| ..... .......") in a cave from the _ice age_. Mathematics
| before writing. We seek to project what we see with our
| mind's eye into the world itself, thereby making it
| communicable, shareable. Ever tell someone you had a dream,
| and they believed you? You just planted the seed for a cult,
| a shared cave. Even though you cannot photograph the dream,
| or offer any evidence that you can dream at all.
|
| The industrial and scientific revolutions have distanced our
| consciousness from this idea, even as they enabled ever more
| perfect caves to manifest. Our vocabulary has become
| corrupted and unclear. We started using words like "reality",
| and "literally", and "truth", when we mean the exact
| opposite.
|
| The conspiracy theorists and cultists, are just people who
| wandered into a new cave, with a different kind of fire, and
| differently curved walls, and they want to tell people from
| their old cave that they have found a way out of the cave
| into reality -- they do not yet realize (or do not want to
| accept), that they live in a network of caves, a network of
| different things in the same category.
|
| During the early 2020s, we did a lot of talking about the
| disappearance of "consensus reality". This is scientific
| terminology mapped over the idea of caves and cults. You can
| tell, because the phrase is an oxymoron. It is not reality,
| if it requires consensus. It is fantasy, it is fiction, it is
| a dream. The cave has indeed become so widespread that we
| even _call_ it reality.
|
| If you speak language, and read words, you are participating
| in a cult (we even call caves that had a kind of altar in the
| center a cult -- in Eurasia, there was a cave-cult called
| _the cult of the bear_, which had a bear skull placed in its
| center during the last ice age, and I would not be surprised
| if people spoke to it, with the help of hallucinogens). The
| only question is whether the cult is nourishing you or
| cannibalizing you.
|
| To the person you are responding to (user ocd): your cave
| (ladybird, your hypothetical tv-series), no longer nourishes
| you like it once did. Maybe find a new cave, build a fire in
| it. Unlike a television series, you can fork a code base. You
| make it into the perfect cave, just for you. And if another
| person likes this cave, chooses to sit by the fire with you,
| well, now you have a cult.
| gethly wrote:
| i rememebr seeing interviews saying rust is not suited for this
| project because of recursion and dom tree. how they tested
| multiple languages and settled on swift. then they abandon swift
| and now they shift towards rust.
|
| this entire project starts to look like "how am i feeling today?"
| rather than a serious project.
| tcfhgj wrote:
| So Swift didn't turned out like they imagined and Rust is just
| the next best alternative to that failed vision using Swift.
|
| So far this is the first and only shift
| adastra22 wrote:
| They were doing their own custom language before Swift.
| tcfhgj wrote:
| didn't know
|
| > The browser and libraries are all written in C++. (While
| our own memory-safe Jakt language is in heavy development,
| it's not yet ready for use in Ladybird.)
|
| https://awesomekling.github.io/Ladybird-a-new-cross-
| platform...
|
| only thing I could find - has it been actually used in
| Ladybird after all?
| LeFantome wrote:
| No, they never completed or adopted their own language.
| It was back in the SerenityOS days, before the browser
| forked into its own project.
|
| https://github.com/SerenityOS/jakt
| MrFurious wrote:
| Yes, i understand that in a personal project, but they have
| investors behind them.
| cromka wrote:
| They adopted Rust for LibJS, not the browser and its engine.
| norman784 wrote:
| From the link it seems that Ladybird architecture is very
| modular, in this case LibJS is one of the subsystems that has
| less external dependencies, said that they don't need to
| migrate everything, only the parts that makes sense.
| jvillasante wrote:
| > We've been searching for a memory-safe programming language to
| replace C++ in Ladybird for a while now.
|
| The article fails to explain why. What problems (besides the
| obvious) have been found in which "memory-safe languages" can
| help. Do these problems actually explain the need of adding
| complexity to a project like this by adding another language?
|
| I guess AI will be involved which, at this early point in the
| project would make ladybird a lot less interested (at least to
| me).
| panstromek wrote:
| > besides the obvious
|
| Well, what else is there besides the obvious? It's a browser.
| michaelcampbell wrote:
| > What problems (besides the obvious) have been found in which
| "memory-safe languages" can help.
|
| Why isn't that enough?
| nicoburns wrote:
| Browsers are incredibly security-sensitive projects.
| Downloading untrusted code from the internet and executing is
| part of their intended functionality! If memory safety is
| needed anywhere it's in browsers.
| f311a wrote:
| You don't want a browser with a bunch of RCEs that can be
| triggered by opening a web page...
| Perz1val wrote:
| You do want a browser with RCE, but you want it to keep the
| it sandboxed. The hard part is executing the code safely
| norman784 wrote:
| I guess you will need to wait for their Feb 2026 update.
| the_duke wrote:
| Even Chrome has started to adopt Rust due to recurring memory
| vulnerabilities.... that's a big enough reason.
| VoxPelli wrote:
| Rust was pretty much created to help solve security issues in
| browsers:
| https://en.wikipedia.org/wiki/Rust_(programming_language)#20...
| ramon156 wrote:
| I'm a long-time Rust fan and have no idea how to respond. I think
| I need a lot more info about this migration, especially since
| Ladybird devs have been very vocal about being "anti-rust" (I
| guess more anti-hype, where Rust was the hype).
|
| I don't know if it's a good fit. Not because they're writing a
| browser engine in Rust (good), but because Ladybird praises
| CPP/Swift currently and have no idea what the contributor's
| stance is.
|
| At least contributing will be a lot nicer from my end, because my
| PR's to Ladybird have been _bad_ due to having no CPP experience.
| I had no idea what I was doing.
| ursuscamp wrote:
| They abandoned Swift recently.
| Cyphase wrote:
| The public announcement was less then a week ago. Meanwhile
| in TFA:
|
| > ... the entire port took about two weeks.
|
| So he was ~halfway in when he made the Swift announcement.
| hackpelican wrote:
| Doesn't sound like a bad thing to evaluate the most obvious
| alternative to build confidence before officially pulling
| the plug.
| fmajid wrote:
| The most obvious alternative would be Zig. I don't see
| any Swift adoption outside the Apple ecosystem.
| Perz1val wrote:
| Last time I checked, Zig was breaking it's stdlib, so
| it's not an alternative imo
| hypeatei wrote:
| Swift adoption had been dead long before the actual
| announcement. It's likely Rust was being considered long
| before this two week experiment with LLMs.
| dougiejones wrote:
| TFA mentions "the contributor's" stance on Swift.
| ramon156 wrote:
| But not the stance on Rust, which is something I'm wondering.
| I understand there's a core team assigned, but are the ~200
| contributors okay with this migration?
| the_mitsuhiko wrote:
| Why would 200 contributors have to be okay with this
| migration? The project has a leader, the leader makes
| decisions.
| gostsamo wrote:
| because let's say 150 contributors might not be okay with
| the decision and leave. hard to lead from the front if
| there is nobody behind to be lead.
| swiftcoder wrote:
| To be fair, any of them who didn't leave in the last few
| controversies probably won't leave over this.
| 0x457 wrote:
| "I can excuse foaming over pronouns and master branch,
| but I draw a line at using rust" Would not be surprised
| by that opinion.
| latexr wrote:
| > Ladybird praises CPP/Swift currently
|
| Not anymore.
|
| https://news.ycombinator.com/item?id=47067678
| ramon156 wrote:
| I guess I missed this, thanks!
| shevy-java wrote:
| They are moving fast.
|
| Next month it will be yet-another-language.
|
| Eventually they come full circle and settle for either C or
| C++.
| Perz1val wrote:
| They've been stuck with swift adoption for a long time,
| abandoning that was the reasonable decision. That only
| leaves Rust as the second language to C++
| smartmic wrote:
| I am somewhat concerned about the volatility. All three
| languages have their merits and each has a stable foundation
| that has been developed and established over many years. The
| fact that the programming language has been "changed" within a
| short period of time, or rather that the direction has been
| altered, does not inspire confidence in the overall continuity
| of Ladybird's design decisions.
| 0x00cl wrote:
| Ladybird as a project is not that old, and it's still in pre-
| alpha, if they are going to make important changes then it's
| better now than later.
| boxed wrote:
| There's been some fun volatility with the author over the
| years. I told him once that he might want to consider another
| language to which he replied slightly insultingly. Then he
| tried to write another language. Then he tried to switch from
| C++ to Swift, and now to Rust :P
| oblio wrote:
| Upside: he's learning?
| jacquesm wrote:
| Indeed, and as a school those 18 months are well worth
| it, but it is in many ways also 18 months wasted. There
| is a strong sense of NIH with the Ladybird dev(s), and I
| wonder if that isn't their whole reason for doing this.
|
| I've seen another team doing something similar, they went
| through endless rewrite cycles of a major package but
| never shipped, and eventually the project was axed when
| they proposed to do it all over again, but this time even
| better.
| rjh29 wrote:
| The sense of NIH is from Serenity, and that was probably
| the reason for Jakt's existence too. Now it's spun off
| into its own project there is a lot more pragmatism.
| jsheard wrote:
| > I am somewhat concerned about the volatility.
|
| Not just volatility but also flip-flopping. Rust was
| explicitly a contender when they decided to go with Swift 18
| months ago, and they've already done a 180 on it despite the
| language being more or less the same as it was.
| fmajid wrote:
| It's not that they are loving Rust, but they realized going
| all-in on Swift means becoming sharecroppers on massa Tim
| Apple's plantation.
| zem wrote:
| they tried swift, it didn't work, and they figured rust was
| the best remaining option. that's not "flip-flopping" (by
| which I assume you mean random indecisiveness that leads to
| them changing their mind for no reason)
| lioeters wrote:
| Yup, this was not flip-flopping, it was willingness to be
| open to options, even if it means going back on a
| decision branch made earlier in the process.
|
| For the Ladybird project, now is the best time to be
| making a big decision like this, and it's commendable
| that the project lead was honest to recognize when an
| earlier attempt was not working, to be able to re-think
| and come to a better decision. I'm no fan of Rust, but
| for this project I think most of us would agree it's a
| better language than Swift for their purpose.
| qingcharles wrote:
| They made a very pragmatic and sensible decision after
| reviewing Swift that it wouldn't be suitable for their
| purposes, so they shifted to the next best alternative. I
| think they reasoned it very well and made a great decision.
| 0x457 wrote:
| I guess they bet on Swift being more than Apple's blessed
| way of writing UI software.
| thrdbndndn wrote:
| I'd argue Ladybird itself is a "hype" project.
| throwaway2037 wrote:
| Fair point. What does Ladybird need to achieve in your
| opinion to shake the "hype" label? Honestly, I, myself, don't
| have a good answer!
| pelagicAustral wrote:
| > What does Ladybird need to achieve in your opinion to
| shake the "hype" label?
|
| A release (?)
| gkbrk wrote:
| Somehow people manage to run it without this magical
| release
| thrdbndndn wrote:
| To me, a project's "hype-ness" is the ratio of how much
| attention it gets over how useful it actually is to users.
|
| As a browser, Ladybird usefulness is currently quite
| limited for obvious reasons. This is not meant to dismiss
| its achievements, nor to overlook the fact that building a
| truly useful browser for everyday users is something few
| open source teams can accomplish without the backing of a
| billion dollar company. Still, in its present state, its
| practical utility remains limited.
| shevy-java wrote:
| Good verdict. I agree.
|
| Ladybird will have to deliver eventually - on this part I
| think many people agree with.
| Fervicus wrote:
| Anything trying to break the browser monopolies in a
| meaningful way deserves the hype, IMO.
| cardanome wrote:
| > I guess more anti-hype, where Rust was the hype
|
| Yeah that is the thing I struggle with. I am really happy for
| people falling in love with Rust. It is a amazing language when
| used for the right use case.
|
| The problem is that had my Rust adventures a few years ago and
| I am over the hype cycle and able to see both the advantages
| and disadvantages. Plus being generally older and hopefully
| wiser I don't tie my identity towards any specific programming
| language that much.
|
| So sometimes when some Junior dev discovers Rust and they get
| really obnoxious with their evangelicalism it can be very off
| putting. Really not sure how to solve it. It is good when
| people get excited about a language. It just can be very
| annoying for everyone else sometimes.
| Onavo wrote:
| > _So sometimes when some Junior dev discovers Rust and they
| get really obnoxious with their evangelicalism it can be very
| off putting._
|
| And experience doesn't equal correct decision making. People
| just get traumatized in different ways.
| geertj wrote:
| > So sometimes when some Junior dev discovers Rust and they
| get really obnoxious with their evangelicalism it can be very
| off putting. Really not sure how to solve it. It is good when
| people get excited about a language. It just can be very
| annoying for everyone else sometimes.
|
| This rings very true, and I've actually disadvantaged myself
| somewhat here. I was involved in projects that made very
| dubious decisions to rewrite large systems in Rust. This
| caused me to actively stay away from the language, and stick
| to C++, investing lots of time in overcoming its
| shortcomings.
|
| Now years later, I started with Rust in a new project. And I
| must say, I like the language, I really like the tools, and I
| like the ecosystem. On some dimension I wish I would have
| done this sooner (but on the other hand, I think I have a
| better justification of "why Rust" now).
| virgil_disgr4ce wrote:
| I'm contemplating diving into Rust for a smallish project, a
| daemon with super-basic UI intended for Linux, MacOS and
| Windows. Do you mind expanding on what disadvantages you
| encountered? Or use-cases that aren't appropriate for Rust?
| cmrdporcupine wrote:
| I'm not OP but here's my disadvantages. Rust is the way I
| earn my living, and also my open source tool of choice. And
| my background is 25 years of SWE career:
|
| 1. build / compile times can be atrocious
|
| 2. crates.io inherits the npm philosophy, which means
| fairly unmoderated space of third party deps and because
| the Rust stdlib doesn't have a lot in it, _extensive_ third
| party crate (lib) usage is strong in Rust. As a result most
| Rust projects have rather sprawling dependency trees, often
| with duplicated functionality (multiple Base64, rand,
| sha256, etc crates). I personally have a problem with this
| (auditability, accountability, security, complexity etc).
| Others don 't.
|
| 3. Despite being nominally runtime agnostic, Rust async
| basically _is_ tokio and it 's almost impossible to use
| another runtime once you factor in third party deps. In
| many ways Rust is the language that tokio ate. In fact even
| if you opt out of async entirely, you often end up with
| tokio as a dependency simply because the community just
| seems to expect it.
|
| 4. Despite advertising itself as a "systems" language, some
| basic systems programming facilities I expect from my C++
| background are still fundamentally not there. In
| particular, per-container/struct pluggable allocators
| _still_ isn 't a thing and the feature to add it
| (allocator-api) has sat unmerged in nightly for almost ten
| years at this point and it doesn't look good for it landing
| any time soon.
|
| 5. If you're working in the embedded space, there's still
| plenty of devices that will not have a workable Rust
| toolchain option yet.
|
| I still choose it for new projects instead of its
| competitors C++ or Zig. But I think it's important to
| recognize there are compromises like any other tool.
|
| As much as people might insist otherwise, there will in
| fact come a day when there are "multiple Rusts" by which I
| mean multiple styles and ways of doing things -- just like
| C++. For myself, for example... if it were my repository
| and my team and my hiring, and I was starting from
| scratch... I'd be _extremely_ careful about third party
| crate adoption and have an extremely minimalistic approach
| there. And I don 't use tokio. Though my paying jobs do.
| jacquesm wrote:
| So many great and balanced comments in this thread.
| cmrdporcupine wrote:
| Sure, and I'm available to provide balance commentary for
| hire, too ;-)
| jacquesm wrote:
| I'm pretty sure you wouldn't like to work on what I'm
| working on right now though!
| pkulak wrote:
| It's all the stuff that people always mention; they are not
| wrong. You spend a decent amount of time... conversing with
| the compiler about lifetimes and, in my experience, even
| more so about the type system, which is _extremely_
| complicated. But you also have to keep in mind that Rust
| got very popular, very fast, and the tail end of something
| like that is always a negative reaction. The language is
| the same, despite the hype roller coaster.
| LoganDark wrote:
| I find Rust's complexity freeing, in that there are often
| at least a few ways to express what I want, and I can
| choose the one I feel best fits the use-case and my
| desired ergonomics. (I also like that there are often
| ways to express _exactly_ a very _precise_ want, owing
| well to the Rust principle of "zero-cost abstractions.")
| However of course, that very same complexity can make it
| unclear which approach may best serve a given objective,
| and lead to false starts, wacky implementations, or even
| giving up entirely.
| renewiltord wrote:
| It's a pretty good language and ecosystem. Downside was
| always the community which every ten seconds someone will
| start asking to tax everyone to fund Rust Software Foundation
| or constantly argue that you have to donate a percentage of
| income to it. Now with LLM I don't have to talk to community.
| Huge improvement.
|
| Problem with community is it has experts and groupies mixed
| in. Ideally experts can talk somewhere and groupies can go
| somewhere else and talk about funding RSF etc. but now is
| unnecessary. Expert is available on demand via chatbot.
| muyuu wrote:
| it's very odd that someone with no experience would take a big
| project like this and just jump to another language because he
| trusts the AI generated code of current models
|
| if it works it works i guess, but it seems mad to me on the
| surface
| fmbb wrote:
| Why do you think the creator behind SerenityOS has no
| experience? I mean it's not the most popular OS out there but
| he seems like a capable individual.
| simonask wrote:
| It's hard to articulate, but as someone who knows first
| hand, I just want to say that manic productivity is not the
| same as solid engineering.
| muyuu wrote:
| in case it's not glaringly obvious from the comment, he has
| plenty of cpp experience and little rust experience, and
| that's according to his own comments
|
| the relevant bit here is that he's porting from a language
| in which he has plenty of experience into another one in
| which he doesn't, in a large project
|
| that in itself sounds like putting a lot of faith in LLMs
| but maybe there are factors not mentioned here, which is
| why i said "on the surface"
| jacquesm wrote:
| Indeed, the hard part won't the port, but the maintenance
| of that which got ported. To be fair though, he's
| probably going to be able to use the same techniques for
| that.
| jibal wrote:
| Did you read the OP? No trust, only thorough verification.
| muyuu wrote:
| I did, and the point stands because reading someone else's
| code is not the same as writing it, esp. when you're not
| able to do so to the same standard
| jibal wrote:
| Non sequitur. Again, no trust was involved, only
| verification through extreme testing.
|
| Also, as others have pointed out, "someone with no
| experience" simply isn't true.
| muyuu wrote:
| the trust element to me is jumping into a port, not
| specific code although code you didn't write in a
| language you're not an expert with, will ALWAYS introduce
| an added risk of falling into pitfalls you can only avoid
| with experience, the more the merrier
|
| you're banking in the LLMs quite strongly when you do
| that, which may just work but i would be very worried
| about myself if i were in his boots
| jibal wrote:
| > code you didn't write
|
| He did write it.
|
| > you're banking in the LLMs quite strongly when you do
| that, which may just work but i would be very worried
| about myself if i were in his boots
|
| I too would worry if it were _you_ doing it.
| swiftcoder wrote:
| > especially since Ladybird devs have been very vocal about
| being "anti-rust" (I guess more anti-hype, where Rust was the
| hype).
|
| I mean, they seem mostly to be against anything that isn't
| C++'s peculiar brand of Object Oriented Programming?
|
| (also against women and immigrants, but that's a different
| story)
| pkulak wrote:
| > I think I need a lot more info about this migration
|
| Doesn't sound like it's some Fish-style, full migration to Rust
| of everything. Seems like they are just moving a couple parts
| over for evaluation, and then, going forward, making it an
| official project language that folks are free to use. They note
| that basically every browser already does that, so this isn't a
| huge shakeup.
| tvshtr wrote:
| This makes sense because GUI wise Rust isn't really here yet
| (but it's close).
| accelbred wrote:
| Its possible to dislike Rust but pragmatically use it.
| Personally, I do not like Rust, but it is the best available
| choice for some work and personal stuff.
| Levitating wrote:
| So what don't you like about it?
| accelbred wrote:
| Its for the time being is stuck with LLVM, so I can't
| currently LTO with GCC objects. Its got a lot higher
| complexity than I perfer in a language. A lot of features I
| find important seem perma-unstable. Pin is unnessesarily
| confusing. No easy way to define multiple compilation units
| for use with linker object selection and attribute
| constructor. The easy path is downloading binary toolchains
| with rustup and not using your disto package manager. You
| can't use unstable features without the bootstrap env var
| on distro rust toolchains. Cargo leads to dependency bloat.
| The std/core crates are prebuilt binaries and bloat binary
| sizes. Bindgen doesn't translate static inline code. The
| language has a ton of stuff it exposes just to std and not
| user code. Unsafe code is unergonomic. No easy way to model
| a cleanup function that needs more args. No support for
| returns_twice. No ability to use newer stuff like
| preserve_none. Can't go-to-definition from a bindgen
| binding to original header file. Macros pollute global
| namespace. Can't account for platforms where size_t and
| uintptr_t are different. Traits can only be relied on if
| marked unsafe. Can't implement something like defer since
| it holds a borrow. no_std code still can pull in core::fmt.
| Can't enforce dependencies are also no_std. Panics are
| considered safe. No way to add non-function fields to dyn
| vtables. No way to declare code separately from definition.
| No way to have duplicate type definitions that merge,
| making interop between different bindgen generated modules
| annoying.
| shevy-java wrote:
| I think this is a good, realistic point of view.
|
| Personally I think most programming languages have really ...
| huge problems. And the languages that are more fun to use,
| ruby or python, are slow. I wonder if we could have a great,
| effective, elegant language that is also slow. All that try
| end up with e. g. with a C++ like language.
| zarzavat wrote:
| Honestly I find writing Rust more fun than writing Python.
| Python just doesn't scale, any non-trivial quantity of it
| has a habit of turning into spaghetti however hard I try to
| be disciplined.
|
| Rust, although annoying at a micro scale, does at least
| enforce some structure on your code, although like Kling I
| miss OO.
|
| AI has made Rust approachable to a new audience of
| programmers who didn't want to dedicate their life to
| learning the ins and outs of the language. Especially for
| C++ developers who already learned the ins and outs of a
| hyper complex programming language and don't want to go
| through that a second time.
|
| Before AI, writing Rust was frustrating experience that
| involved spending 90% of your time reading documentation
| and grumbling that "I could do this in 5 minutes in C++"
|
| Now I can write Rust in a way that makes sense to my C++
| addled brain and let the AI do the important job of turning
| it into an idiomatic Rust program that compiles.
| yanosc wrote:
| If this means we will get an independent state-of-the-art browser
| engine, I'm all for it.
| youngtaff wrote:
| IMV Servo is going to be the independent state of the art
| browser
| Perz1val wrote:
| I have my doubts it'll ever be "finished". Servo gives strong
| vibes of a project that will avoid performance hacks, because
| they're not nice/state of the art code. I have no evidence,
| it's just the energy I've picked up from it
| worldsavior wrote:
| Good step. It will bring many more contributors.
| zozbot234 wrote:
| Using LibJS with servo, when?
| djoldman wrote:
| A lot of the previous calculus around refactoring and "rewrite
| the whole thing in a new language" is out the window now that AI
| is ubiquitous. Especially in situations where there is an
| extensive test suite.
|
| Testing has become 10x as important as ever.
| pjmlp wrote:
| Well, I am on the provocative side that as AI tooling matures
| current programming languages will slowly become irrelevant.
|
| I am already using low code tooling with agents for some
| projects, in iPaaS products.
| anon-3988 wrote:
| > Well, I am on the provocative side that as AI tooling
| matures current programming languages will slowly become
| irrelevant.
|
| I have the opposite opinion. As LLM become ubiquitous and
| code generation becomes cheap, the choice of language becomes
| more important.
|
| The problem with LLM for me is that it is now possible to
| write anything using only assembly. While technically
| possible, who can possibly read and understand the mountain
| of code that it is going to generate?
|
| I use LLM at work in Python. It can, and will, easily use
| hacks upon hacks to get around things.
|
| Thus I maintain that as code generation is cheap, it is more
| important to constraint that code generation.
|
| All of this assume that you care even a tiny bit about what
| is happening in your code. If you don't, I suppose you can
| keep banging the LLM to fix that binary blob for you.
| pjmlp wrote:
| Lets say years of offshoring projects have helped to reach
| that opinion.
| _flux wrote:
| > The problem with LLM for me is that it is now possible to
| write anything using only assembly. While technically
| possible, who can possibly read and understand the mountain
| of code that it is going to generate?
|
| As a very practical problem the assembly would consume the
| context window like no other. And another is having some
| static guardrails; sometimes LLMs make mistakes, and
| without guard rails it debugging some of them becomes quite
| a big workload.
|
| So to keep things efficient, an LLM would first need to
| create its own programming language. I think we'll actually
| see some proposals for a token-effective language that has
| good abstraction abilities for this exact use.
| ignoramous wrote:
| > _As LLM become ubiquitous and code generation becomes
| cheap, the choice of language becomes more important._
|
| I think, changes to languages/tooling to accomodate Agentic
| loops will become important.
|
| > _All of this assume that you care even a tiny bit about
| what is happening in your code. If you don 't..._
|
| I mean, as software engineers, we most certainly do. I
| suspect there'll be a new class of "developers" who will
| have their own way of making software, dealing with bugs,
| building debugging tools that suit their SDLC etc. LLMs
| will be to software development what Relativity was to
| Astrophysics, imo: A fundamental & permanent shift.
| javier123454321 wrote:
| Im already using models to reason about and summarize part of
| the code from programming language to prose. They are good at
| that. I can see the process being something like english to
| machine lang, machine lang to english if the human needs to
| understand. However amother truism is that compilers are a
| great guardrail against bad generated code. More
| deterministic guardrails are good for llms. So yeah im not
| there yet where i trust binaries to the statistical text
| generators.
| staticassertion wrote:
| I don't agree. For one thing, the language directly impacts
| things like iteration speed, runtime performance, and
| portability. For another, there's a trade-off between
| "verbose, eats context" and "implicit, hard to reason about".
|
| IMO Rust will strike a very strong balance here for LLMs.
| pjmlp wrote:
| Formal specifications and automated testing, will beat any
| language specific tooling.
|
| Hardly much different than dealing with traditional
| offshoring projects output.
| anon-3988 wrote:
| If the offshore company provides me a Rust crate that
| compiles, that is already a lot of guarantee. Now that
| does not solve the logic issues and you still need
| testing.
|
| But testing in Python is so easy to abuse as LLM. It will
| create mocks upon mocks of classes and dynamically patch
| functions to get things going. Its hell to review.
| throwaway27448 wrote:
| What is a programming language used for if not the most
| formal specification possible? Of course it doesn't
| matter what language you use if you perfectly describe
| the behavior of the program. Of course, there's also no
| point in using LLMs (or outsourcing!) at that point.
| staticassertion wrote:
| > Formal specifications and automated testing, will beat
| any language specific tooling.
|
| I don't understand what you mean. Beat any language at
| what? Correctness? I don't think that's true at all, but
| I also don't see how that's relevant, it definitely
| doesn't address the fact that Rust will virtually always
| produce faster code than the majority of other languages.
|
| > Hardly much different than dealing with traditional
| offshoring projects output.
|
| I don't know what you mean here either.
| pjmlp wrote:
| Any tool that can plug into MLIR and use LLVM, can
| potentically produce fast code.
|
| Also there is the alternative path to execute code via
| agents workestration, just like low code tooling work.
|
| I see you never had the fortune to review code provided
| by cheap offshoring teams.
| staticassertion wrote:
| > Any tool that can plug into MLIR and use LLVM, can
| potentically produce fast code.
|
| I guess that's sort of technically true, but not even
| really? Like, obviously you can compile Python to C and
| then compile that with clang, but it doesn't make it
| fast. But even if that were the case, there aren't that
| many languages that have Rust performance so who cares?
| "Potentially" is sort of saying we might have a future
| language that's better, but of course anyone would agree.
|
| > Also there is the alternative path to execute code via
| agents workestration, just like low code tooling work.
|
| I don't understand how this is relevant.
|
| > I see you never had the fortune to review code provided
| by cheap offshoring teams.
|
| I just don't understand why you're bringing it up tbh I
| don't understand the relevance.
| pjmlp wrote:
| It doesn't need to win the benchmarks Olympics, it needs
| to be fast enough.
|
| Plenty of AI based tooling is already trying out this
| path.
|
| Agents execute actions that in the past would be manually
| programmed applications, now tasks can be automated given
| a few mcp endpoints.
|
| LLMs are already at the same output quality of lousy
| offshoring companies, thus having to fix a bit of it is
| something that unfortunately many of us are already used
| with fellow humans.
| staticassertion wrote:
| I feel like maybe we're drifting here. You said this:
|
| > Well, I am on the provocative side that as AI tooling
| matures current programming languages will slowly become
| irrelevant.
|
| And I said I disagree because language directly impacts
| things like performance. And it does, massively. Like,
| order of magnitude differences are not hard to achieve
| simply by changing language.
|
| You are now saying that things just need to be "fast
| enough", but I don't get how that's relevant. The point
| is that a different language will have different
| tradeoffs, and AI changes some of the calculus there, but
| language is still a major component of the produced
| artifact. If you agree that language has major
| implications on the produced artifact, then we agree. If
| you don't, then I'll just once again appeal to the
| massive performance gaps between different languages.
|
| I still am not understanding the offshoaring
| conversation.
| ivell wrote:
| I would say that current programming languages have a better
| chance due to the huge amount of code that AI can train on.
| New languages do not have that leverage. Moreover, current
| languages have large ecosystems that still matter.
|
| I see the opposite. New languages have more difficulty
| breaking into popularity due to lack of enough existing
| codename and ecosystems.
| pbronez wrote:
| Interesting take, what do you think comes next? A programming
| language optimized for coding agents?
| dizhn wrote:
| For a personal thing I had AI write some python libraries to
| power a cli. It has to do with simple excel file filtering,
| grouping and aggregating. Nothing too fancy. However since it's
| backed by a library, I am playing with different UIs for the
| same thing and it's fun to say.. Do it with streamlit. Oh it
| can't do this particular thing. Fine do it with shiny. No? OK
| Dash. It takes only like an hour to prototype with a whole new
| UI library then I get to say "nah" like a spoiled child. :)
| pjmlp wrote:
| All the best to them, however this feels like yah shaving instead
| of focusing into delivering a browser than can become an
| alternative to Safari/Chrome duopoly.
| cogman10 wrote:
| Agreed. They said they ruled out rust in 2024, I believe the
| article they published was near the end of 2024 because I
| remember reading it fairly recently.
|
| Seems like a lot of language switches in a short time frame.
| That'd make me super nervous working on such a project. There
| will be rough parts for every language and deciding seemingly
| on whims that 1 isn't good enough will burn a lot of time and
| resources.
| cromka wrote:
| Part of browser experience is safety and migrating their JS
| library to Rust is probably one of the best ways to gain
| advantage over any other existing engine out there in this
| aspect. Strategically this may and likely will attract 3rd
| party users of the JS library itself, thus helping its adoption
| and further improving it.
|
| They're not porting the browser itself to Rust, for the record.
| pjmlp wrote:
| Yet, they are open to further rewrites.
| cromka wrote:
| Your rant was about their loss of focus, not about them
| being open to other changes. Moving goalposts!
| norman784 wrote:
| Javascript is a self contained sub system, if the public API
| stays the same, then they can rewrite as much as they want,
| also I suppose this engine now will attract new contributors
| that will want to contribute to Ladybird just because they
| enjoy working with Rust.
|
| Don't forget that the Rust ecosystem around browsers is
| growing, Firefox already uses it for their CSS engine[0], AFAIK
| Chrome JPEG XL implementation is written in Rust.
|
| So I don't see how this could be seen as a negative move, I
| don't think sharing libraries in C++ is as easy as in Rust.
|
| [0] https://github.com/servo/stylo
| VoxPelli wrote:
| Not only is Firefox using it for their CSS engine but Mozilla
| created Rust to build Servo and sadly only the CSS engine and
| maybe some other parts is what they kept around when they
| offloaded Rust.
|
| "the Rust ecosystem around browsers is growing" - in the
| beginning pretty much 100% of the ecosystem around Rust was
| browser oriented
|
| Thankfully Servo is picking up speed again and is a great
| project to help support with some donations etc:
| https://servo.org/
| wolvesechoes wrote:
| Maybe it is my cynicism, but I always suspect such projects to
| be endless rabbit chasing. It is not about catching it.
| zem wrote:
| think of it as axe sharpening rather than yak shaving
| rausr wrote:
| I must admit to being somewhat confused by the article's claim
| that Rust and C++ emit bytecode. To my knowledge, neither do
| (unless they're both targeting WASM?) - is there something I'm
| missing or is the author just using the wrong words?
|
| EDIT: bramhaag pointed out the error of my ways. Thanks bramhaag!
| bramhaag wrote:
| By 'Rust compiler' and 'C++ compiler', they refer to the LibJS
| bytecode generator implemented in those languages. This is
| about the generated JS bytecode.
| rausr wrote:
| Yes, I re-read again, and I think you are correct. Thanks!
| mdavid626 wrote:
| Thanks! I was confused about this as well.
| xwowsersx wrote:
| They're referring to LibJS's bytecode (the internal instruction
| stream of Ladybird's JS engine), not to Rust/CPP output
| formats.
| potato-peeler wrote:
| Is there any discussion on why D or even Ada was not considered?
| These languages have been around for long time. If they were
| willing to use llm to break the initial barrier to entry for a
| new language, then a case can be made for these languages as
| well.
| account42 wrote:
| They already made the mistake picking a niche language twice
| (first their own language, then Swift as a cross-platform
| language), why would you want them to make it a third time?
| potato-peeler wrote:
| What kind of response is this? I was asking if there was any
| technical evaluation on other languages. And D and Ada are
| not niche. They have been battle tested in critical software.
| Imustaskforhelp wrote:
| Swift had/has some problems in the language itself. It's not
| because of the niche nature of Swift that was the problem
| iirc.
|
| I don't think this is the right response because certainly a
| meaningful discussion could've definitely taken place and
| given how they were already open to other languages which was
| the reason why they picked Swift in the first place.
|
| I remember Andreas video where he talked about how people
| used rust in his codebase and they were so happy but later it
| became very difficult whereas they found with swift that it
| became easier to manage. That was the reason why they picked
| swift that time.
|
| Certainly their goal wasn't to pick a popular language
| (because if that's what you want use python or JS) but rather
| a language that was relevant to what they were building.
|
| So if D and Ada were relevant or not, that's the main point
| of discussion imo.
| yurishimo wrote:
| Probably contributing reasons? I imagine over time they will
| have a lot more Rust contributors than D or Ada.
| tgv wrote:
| I've dabbled a bit in Ada, but it wouldn't be my choice either.
| It's still susceptible to memory errors. It's better behaved
| than C, but you still have to be careful. And the tooling isn't
| great, and there isn't a lot in terms of libraries. I think
| Ladybird also has aspirations to build their own OS, so
| portability could also be an issue.
| potato-peeler wrote:
| Not the case with spark. But I understand it requires writing
| lot of things from scratch for browsers. But I don't think
| portability will be an issue with Ada, it is cross platform.
|
| However, this is where d shines. D has a mature ecosystem.
| Offers first class cpp abi and provides memory safety
| guarantees, which the blog mentioned as a primary factor. And
| d is similar to cpp, low barrier for cpp devs to pick up.
| tgv wrote:
| There's no dynamic memory allocation with (100%) Spark.
| That's really limiting. You can to write "unsafe" code, but
| that has the same problems as Ada.
| potato-peeler wrote:
| That is true for parsers like libjs, but again crypto
| module or even networking, can still be written in spark,
| which is much more safety critical.
| Rochus wrote:
| SPARK is not used for the whole system, but for the < 5%
| parts, which are safety/security-related in a good
| architecture.
| Rochus wrote:
| Unfortunately a really good question gets downvoted instead of
| causing a relevant discussion, as so often in recent HN. It
| would be really interesting to know, why Ada would not be
| considered for such a large project, especially now when the
| code is translated with LLMs, as you say. I was never really
| comfortable that they were going for the most recent C++
| versions, since there are still too many differences and
| unimplemented parts which make cross-compiler compatibilty an
| issue. I hope that with Rust at least cross-compilation is
| possible, so that the resulting executable also runs on older
| systems, where the toolchain is not available.
| Imustaskforhelp wrote:
| I personally think that people might've framed it as use
| Ada/D over rust comment which might have the HN people who
| prefer rust to respond with downvotes.
|
| I agree that, this might be wrong behaviour and I don't think
| its any fault of rust itself which itself could be a blanket
| statement imo. There's nuance in both sides of discussions.
|
| Coming to the main point, I feel like the real reason could
| be that rust is this sort of equilibra that the world has
| reached for, especially security related projects. Whether
| good or bad, this means that using rust would definitely lead
| to more contributor resources and the zeal of rustaceans can
| definitely be used as well and also third party libraries
| developed in rust although that itself is becoming a problem
| nowadays from what I hear from people in here who use rust
| sometimes (ie. too many dependencies)
|
| Rust does seem to be good enough for this use case. I think
| the question could be on what D/Ada (Might I also add
| Nim/V/Odin) will add further to the project but I honestly
| agree that a fruitful discussion b/w other languages would've
| been certainly beneficial to the project (imo) and at the
| very least would've been very interesting to read personally
| Rochus wrote:
| > which might have the HN people who prefer rust to respond
| with downvotes.
|
| This completely misses the purpose of the downvoting
| feature, which is not surprising, since upvoting seems no
| longer to indicate quality or truth of the comment neither.
|
| > rust is this sort of equilibra that the world has reached
| for, especially security related projects
|
| Which is amazing, since Rust only covers a fraction of
| safety/security concerns covered by Ada/SPARK. Of course
| this language has some legacy issues (e.g. the physical
| separation of interface and body in two separate files; we
| have better solutions today), but it is still in
| development and more robust than the C/C++ (and likely
| Rust) toolchain. And in the age of LLMs, robustness and
| features of a toolchain should matter more than the
| language syntax/semantics.
|
| > Rust does seem to be good enough for this use case.
|
| If you compare it to the very recend C++ implementations
| they are using, I tend to agree. But if you compare it to a
| much more mature technology like e.g. Ada, I have my
| doubts.
| Imustaskforhelp wrote:
| > If you compare it to the very recend C++
| implementations they are using, I tend to agree. But if
| you compare it to a much more mature technology like e.g.
| Ada, I have my doubts.
|
| I agree with you in the sense that it would've definitely
| been interesting to read what Andreas thinks of Ada/D and
| the discussion surrounding it and your overall comment
| too.
|
| I do wish that anyone from ladybird team/maybe even
| Andreas if he's on HN (not sure) could respond to the
| original query if possible.
|
| I remember ladybird had a discord server I once joined,
| perhaps someone from the community could ask Andreas
| about it there if possible since It would be genuinely
| fascinating to read.
|
| Although a point I am worried about is if Ladybird
| changes the language again let's say after a discussion
| of using Ada/D. It might be awkward.
| Rochus wrote:
| > I am worried about is if Ladybird changes the language
| again
|
| In the time of good LLMs this is likely no longer a show-
| stopper (as e.g. the specific formating rules in C/C++
| since there are good re-formating tools). The question is
| how long we will need programming languages at all. They
| were primarily invented because large assembler projects
| were too challenging for most people. But if all the
| complicated details can now be delegated to LLMs,
| strictly speaking, we no longer need programming
| languages either.
| quesera wrote:
| > _This completely misses the purpose of the downvoting
| feature_
|
| "Downvote for disagree" has been canonicalized on HN
| since (nearly) the beginning, by pg himself, back when he
| used his real-name account to comment. :)
|
| I agree that it has undesirable consequences, but it is
| fully established.
| Rochus wrote:
| Personally I would remove the downvote button entierly
| because apparently it is a lossy projection of an at
| least three-dimensional vector: agreement, quality,
| truth. Graying out text so it is no longer readable is a
| censoring measure not justified in most cases I encounter
| on HN in the eight years I'm here.
| bigstrat2003 wrote:
| It's even worse than that. People are all too often
| willing to "flag for disagree". It's getting to be pretty
| common to see threads with comments that are
| [flagged][dead] which don't break the rules in any way,
| but merely express a view which is unpopular. Sometimes I
| even agree that it's a stupid position to take up, but
| that doesn't merit being flagged to death. I always vouch
| for those comments but it feels like an exercise in
| futility with so many people using the flag function as a
| "super fuck you" button.
| potato-peeler wrote:
| Unfortunately some folks do get bit sensitive on rust, that
| can be off putting.
|
| But what I wanted to know was about evaluation with other
| languages, because Andreas has written complex software.
|
| His insight might become enriching as to shortcomings or
| other issues which developers not that high up in the chain,
| may not have encountered.
|
| Ultimately, that will only help others to understand how to
| write better software or think about scalability.
| easton wrote:
| I know he doesn't make live coding videos anymore, but it'd be
| cool if Andreas showed off how this worked a little more. I'm
| curious how much he had to fix by hand (vs reprompting or
| spinning a different model or whatever).
| l5870uoo9y wrote:
| You can checkout the pull requests related to LibJS:
| https://github.com/LadybirdBrowser/ladybird/pulls?q=is%3Apr+...
| edgyquant wrote:
| What happened? It's been awhile since I checked in but it seems
| he doesn't work on serenity and doesn't live stream anymore
| (and is now into lifting weights)
| Perz1val wrote:
| He got his serenity and at the same time ladybird browser
| started getting somewhere, so he separated it out and went
| full on with it. From what I know, he was working on browsers
| before at Apple, so it was like he got ready to return
| markus_zhang wrote:
| 10x programmers become 100x with the power of AI. Not an
| unexpected outcome. But the world is going to suck for ordinary
| people. 10x programmers will gladly embrace this future become it
| empowers them more.
|
| We have to accept this reality and act accordingly.
|
| Yes you will downvote me. I have accepted this reality and will
| hack on my own projects in the woods or in a cave, on my own
| terms.
|
| ------ I wrote the following after a bit of thought:
|
| It was with a heavy heart that I learned that the author of
| "Ladybird Browser" managed to convert the JavaScript compiler
| from C++ to Rush in 2 weeks, with the help of AI. It was a mix of
| awe and depression. 10x programmers leveraged AI to achieve a
| great feat in only 2 weeks, passing all tests. This was not a
| surprise to me as we all saw the writing on the wall a couple of
| years ago, but reality hit hard still. I'm a very average
| programmer, a very average person, and perhaps worse than the
| median in many perspectives. The gap between an ordinary people,
| with a 10X whatever, is getting much larger due to the evolution
| of tools. No, I do not believe AI can ever replace humans
| completely, at least not in the near future. But the point is, we
| the ordinary people are getting less and less relevant. The gate
| of professional work, the gate from which we drink satisfaction
| by knowing that many are using our work, is closing. I have no
| ill feeling towards any 10X programmers who is enjoying this.
| They are much better than me. They have earned it. They deserve
| it. And I deserve it, too, to have allowed myself to be mediocre.
| Being mediocre is a lesser evil then and now, but is a major sin
| in the future.
|
| I soaked myself in "Crypto-zoologist" (Disco Elysium) to savor
| the moment. It is fine. Perhaps I will never get a professional
| job as a system programmer, and this is fine. I'll go into the
| woods, stay in a cave, and hack on my own projects, on my own
| terms. I do no care about the end products, and neither do I care
| whether people use them at all. Programming is a ritual to dispel
| the daemons from my soul, and I must keep doing it, until the
| last moment.
| account42 wrote:
| > We previously explored Swift, but the C++ interop never quite
| got there, and platform support outside the Apple ecosystem was
| limited.
|
| Why was there ever any expectation for Swift having good platform
| support outside Apple? This should have been (and was to me)
| already obvious when they originally announced moving to Swift.
| adastra22 wrote:
| Apple's own marketing speak has Swift as a cross platform
| language. Just like, I suppose, C# is a cross platform
| language.
|
| Apple puts zero resources into making that claim reality,
| however.
| hocuspocus wrote:
| Apple actually did put some resources behind it, the
| toolchain is reasonably pleasant to use outside macOS and
| Xcode, they have people building an ecosystem in the Swift
| Server Workgroup, and arguably some recent language design
| decisions don't seem to be purely motivated by desktop/mobile
| usage.
|
| But in the end I can't help but feel Swift has become an
| absolute beast of a multi-paradigm language with even worse
| compile times than Rust or C++ for dubious ergonomics gains.
| adastra22 wrote:
| A language is more than a compiler. All of the Swift
| frameworks you would need to do anything actually useful or
| interesting in the language are macOS-only. You cannot
| develop in Swift for Windows/Linux/Android the way that you
| develop in Swift for macOS/iOS. That matters.
| hocuspocus wrote:
| You don't need to convince me that Swift is poorly
| positioned there, but if you only care about server side
| (or possibly CLI) apps, the usable ecosystem on Linux
| isn't too shabby.
|
| Does it make sense compared to C#, Go, Rust or a JVM
| language? I don't know, but it's there, and Apple put
| some resources behind the initiative.
| adastra22 wrote:
| I think it is comparable to C#, at least C# a decade or
| more ago. Back then it was a great language for
| developing GUI applications on Windows, Unity games, and
| that's about it. Now there's a blossoming community of
| cross-platform frameworks, but only because Microsoft
| invested in making those first-class. Apple hasn't been
| putting that effort into Swift.
| shantara wrote:
| Was it Apple, or community driven projects?
| hypeatei wrote:
| > Just like, I suppose, C#
|
| Have you actually used .NET on Linux/macOS? I have (both at
| home and work) and there isn't anything that made me think it
| was neglected on those platforms. Everything just works(tm)
| adastra22 wrote:
| It didn't use to be that way, for a very long time.
| Fervicus wrote:
| When it wasn't that way, they never had any marketing
| speak that suggested that though?
| vips7L wrote:
| It's been 10 years of it running on Linux.
| Kapendev wrote:
| People here need time to notice XD
| nicoburns wrote:
| Very happy to see this. Ladybird's engineering generally seems
| excellent, but the decision to use Swift always seemed pretty
| "out there". Rust makes a whole lot more sense.
| VoxPelli wrote:
| Servo makes a whole lot more sense: https://servo.org/
| LeFantome wrote:
| Can you send a Gmail in Servo? No?
|
| Ladybird is much further ahead in terms of actually rendering
| web pages that people use.
|
| The biggest advantage to Servo was that it is written in
| Rust. This move begins to nullify that advantage as well.
|
| Why exactly does Servo make more sense?
|
| I hope they both succeed. But Ladybird is more likely to
| become a usable browser first.
| cmrdporcupine wrote:
| This move was only to port a part of their JS runtime
| pieces to Rust, that's it.
| usrbinenv wrote:
| This will be another bad decision just like with Swift. From what
| I heard, Rust is notoriously bad at letting people define their
| own structure and instead beats you up until you satisfy the
| borrow checker. I think it'll make development slow and
| unpleasant. There are people out there who enjoy that, but it's
| not a fit for when you need to deliver a really huge codebase in
| reasonable time. I remember Andreas mentioning he just wanted
| something like C++, but with a GC and D would be absolutely
| perfect for this job.
| thiht wrote:
| Nobody uses D
| usrbinenv wrote:
| And? Does it work? Because it does. It's a lot closer to C++
| and you literally need like a week to start being productive
| and it's insanely flexible as a language. Nobody uses Swift
| also, but the additional problem with Swift was that it's
| entirely Apple-centric.
| cromka wrote:
| Entirely Apple-centric?
| thiht wrote:
| > Nobody uses Swift also
|
| Yep, it was also a weird, not entirely pragmatic choice,
| even if it was well justified technically and all-in-all
| rational. D would be the same.
| p0nce wrote:
| This is like the "real world" argument. Nobody uses that "in
| the real world", except well people that do.
| Kapendev wrote:
| Well, I do!?!! It's even faster than zoomer langs like Odin.
| You should try it.
| Kapendev wrote:
| Zoomer is a good word btw. I love zoomers.
| Perz1val wrote:
| Maybe, but will they have to fight with borrow checker for
| doing some other than (the very OOP) DOM components? They'll
| obviously use both for a long time in the future, so more
| functional places can get Rust, while more OOP places can
| benefit from C++
| thiht wrote:
| Cool, that seems like a rational choice. I hope this will help
| Ladybird and Servo benefit from each other in the long run, and
| will make both of them more likely to succeed
| Perz1val wrote:
| I hope it does not -> because we don't more browser
| crossbreeding
| feverzsj wrote:
| Guess it will never come out.
| vipulbhj wrote:
| Someone should try this with the "Ralph Wiggum loop" approach. I
| suspect it would fail spectacularly, but it would be fascinating
| to watch.
|
| Personally, I can't get meaningful results unless I use the tool
| in a true pair-programming mode--watching it reason, plan, and
| execute step by step. The ability to clearly articulate exactly
| what you want, and how you want it done, is becoming a rare
| skill.
| simonw wrote:
| Given the quality of their existing test suite I'm confident
| the Ralph Wiggum loop would produce a working implementation...
| but the code quality wouldn't be anywhere near what they got
| from two weeks of hands-on expert prompting.
| vipulbhj wrote:
| Sure yeah, I can buy that, but that would be like collecting
| tech debt for generations.
| throwaway2037 wrote:
| > Ralph Wiggum loop
|
| Can you explain more? (I know the reference that he is the
| idiot son of Chief Wiggum from The Simpsons.)
| simonw wrote:
| https://ghuntley.com/loop/ and
| https://github.com/anthropics/claude-
| code/blob/main/plugins/...
| woadwarrior01 wrote:
| Looks like it's been renamed to ralph-loop for legal
| reasons. :D
|
| https://github.com/anthropics/claude-plugins-
| official/pull/1...
| Fervicus wrote:
| > We know the result isn't idiomatic Rust, and there's a lot that
| can be simplified once we're comfortable retiring the C++
| pipeline. That cleanup will come in time.
|
| I wonder what kind of tech debt this brings and if the trade off
| will be worth whatever problems they were having with C++.
| cromka wrote:
| I don't think they were having problems with C++, they moved to
| Rust for memory safety. Mind that they migrated LibJS, their
| JavaScript library.
| snowhale wrote:
| the tech debt risk in this case is mostly in the cleanup phase,
| not the port itself. non-idiomatic Rust that came from C++
| tends to have a lot of raw pointer patterns and manual lifetime
| management that works fine but hides implicit ownership
| assumptions. when you go to make it idiomatic, the borrow
| checker forces those assumptions to be explicit, and sometimes
| you discover the original structure doesn't compose well with
| Rust's aliasing rules. servo went through this. the upside is
| you catch real latent bugs in the process.
| surajrmal wrote:
| It depends. I migrated a 20k loc c++ project to rust via AI
| recently and I would say it did so pretty well. There is no
| unsafe or raw pointer usage. It did add Rc<RefCell in a bunch
| of places to make things happy, but that ultimately caught
| some real bugs in the original code. Refactoring it to avoid
| shared memory (and the need for Rc<RefCell<>> wasn't very
| difficult, but keeping the code structure identical at first
| allowed us to continue to work on the c++ code while the rust
| port was ongoing and keep the rust port aligned without
| needing to implement the features twice.
|
| I would say modern c++ written by someone already familiar
| with rust will probably be structured in a way that's
| extremely easy to port because you end up modeling the borrow
| checker in your brain.
| tonyedgecombe wrote:
| Yes, I just translated a Rust library from non-idiomatic and
| unsafe Rust to idiomatic and safe Rust and it was as much
| work as if I had rewritten it from scratch.
| Fervicus wrote:
| This is what I was trying to highlight in my post.
| snowhale wrote:
| yeah, matches what I'd expect. when you're porting
| idiomatic -> idiomatic within a language, the cleanup is
| mechanical. crossing from C++ to Rust means the borrow
| checker surfaces assumptions that were latent in the
| original code, so you end up redesigning rather than
| translating. that's not a complaint about Rust -- it's
| actually doing its job.
| heliumtera wrote:
| Andreas Kling mentioned many times they would prefer a safer
| language, specifically for their js runtime garbage collector.
| But since the team were already comfortable with cpp that was
| the choice, but they were open and active seeking alternatives.
|
| The problem was strictly how cpp is perceived as an unsafe
| language, and this problem rust does solve! Not being
| sarcastic, this truly looks like a mature take. Like, we don't
| know if moving to rust would improve quality or prevent
| vulnerabilities, here's our best effort to find out and ignore
| if the claim has merits for now. If the claim maintains, well,
| you're better prepared, if it doesn't, but the code holds
| similar qualities...what is the downside?
| throwaway2037 wrote:
| Fuck me. This is wild. Sorry for the potty mouth.
| > Porting LibJS > Our first target was LibJS , Ladybird's
| JavaScript engine. The lexer, parser, AST, and bytecode generator
| are relatively self-contained and have extensive test coverage
| through test262, which made them a natural starting point.
| > Results > The requirement from the start was byte-for-
| byte identical output from both pipelines. The result was about
| 25,000 lines of Rust, and the entire port took about two weeks.
| The same work would have taken me multiple months to do by hand.
|
| I'm not here to troll the LLM-as-programmer haters, but Ladybird
| (and Rust!) is loved by HN, and this is a big win.
|
| How long until Ladybird begins to impact market dominance for
| Chrome and Firefox? My guess: Two years.
| surajrmal wrote:
| Note that Firefox doesn't have market dominance. It is under 5%
| market share. That said I imagine Firefox users to be the most
| likely to make the jump. However, the web is a minefield of
| corner cases. It's hard to believe it will be enough to make
| the browser largely useful enough to be a daily driver.
| NoboruWataya wrote:
| Why do you think Firefox users would be most likely to make
| the jump? The main reason I see people give for supporting
| Ladybird is challenging the dominance of the incumbents.
| That's not really a great reason to switch from Firefox
| because, as you note, it doesn't have any dominance. And
| there's also an argument that splitting the non-Chrome market
| into two only increases Chrome's dominance.
|
| From what I can tell from HN, Brave seems to be popular with
| those users who hate Google but for whatever reason hate
| Mozilla even more, and I suspect those will be the most
| likely users to switch.
| tolerance wrote:
| Something of a culture clash here ain't it, albeit an imbalanced
| one.
| mghackerlady wrote:
| That's a pivot, iirc they wanted to swift (I'm very glad they
| didn't do that). It's cool to see something like claude be useful
| for large scale projects like that
| cbondurant wrote:
| Based on the origins of Rust as a tool for writing the really
| thorny, defensive parsers of potentially actively hostile code
| for firefox, I have to imagine that another web browser is the
| most at-home place the language could ever be.
| jurschreuder wrote:
| Oooh noooo I will have to fork it before it is too late!
| ZoomZoomZoom wrote:
| Looks like Andreas is a mighty fine engineer, but he's even
| better entrepreneur. Doesn't matter if intentional or not, but he
| managed to create and lead a rather visible passion project,
| attract many contributors and use that project's momentum to
| detach Ladybird into a separate endeavor with much more concrete
| financial prospects.
|
| The Jakt -> Swift -> Rust pivots look like the same thing on a
| different level. The initial change to Swift was surely motivated
| by potential industry support gain (i believe it was a dubious
| choice from purely engineering standpoint).
|
| It's awe-inspiring to see how a person can carve a job for
| himself, leverage hobbyists'/hackers' interest and contributions,
| attract industry attention and sponsors all while doing the thing
| he likes (assuming, browsers are his thing) in a controlling
| position.
|
| Can't fully rationalize the feeling, but all of this makes me
| slightly wary. Doesn't make it less cool to observe from a side,
| though.
| newswasboring wrote:
| > but all of this makes me slightly wary.
|
| Wary of what?
| carderne wrote:
| I'd say it's the idea/fact/feeling that, in 2026, agency
| matters more than skill/wisdom/intelligence.
|
| Long read on the topic (quite funny, covers Cluely):
| https://harpers.org/archive/2026/03/childs-play-sam-kriss-
| ai...
| clouedoc wrote:
| Probably, Roy was born agentic as a part of a package which
| included an disregard for intellectual growth.
|
| This doesn't mean that being agentic cannot be cultivated
| by regular people.
|
| In 2026, yes, agency matters more than
| skill/wisdom/intelligence _to get VC funds_. But what 's
| the point of agency alone if you are leading such a life?
|
| What gives me hope is that in 2026, skillful people can
| delegate a lot of their work to LLMs, which gives them time
| to learn the "agentic" part which is basically marketing
| and talking with people.
|
| (just thinking out loud)
| SatvikBeri wrote:
| Eh, he's given an interview where he talks about the Swift
| decision. He and several maintainers tried building some
| features in Swift, Rust, and C++, spending about two weeks on
| each one IIRC. And all the maintainers liked the experience of
| Swift better. That might have ended up wrong, but it's a pretty
| reasonable way to make a decision.
| zamalek wrote:
| Two weeks with Rust and you're still fighting with the
| compiler. I think the LLM pulled a lot of weight selling the
| language, it can help smooth over the tricky bits.
| written-beyond wrote:
| idk man it's rare to fight the compiler once you've used
| Rust for long enough unless you're doing something that's
| the slightest bit complex with async.
|
| You get to good at schmoozing the compiler you start to
| create actual logical bugs faster.
| zamalek wrote:
| That's why I said "two weeks."
| jacquesm wrote:
| That goes for almost every language. I recall my first
| couple of weeks with various compiled language and they
| all had their 'wtf?' moments when a tiny mistake in the
| input generated reams of output. But once you get past
| that point you simply don't make those mistakes anymore.
| Try missing a '.' in a COBOL program and see what
| happens. Make sure there is enough paper in the box under
| LPT1...
| blub wrote:
| This is less about languages and more about so-called AI. One
| thing's for sure: it's becoming harder and harder to deny that
| agentic coding is revolutionizing software development.
|
| We're at the point where a solid test suite and a high-quality
| agent can achieve impressive results in the hands of a
| competent coder. Yes, it will still screw up, needs careful
| human review and steering, etc, but there is a tangible
| productivity improvement. I don't think it makes sense putting
| numbers on it, but for many tasks, it looks like there's a
| tangible benefit.
| ozgrakkurt wrote:
| This looks like guerrilla advertising for sure.
|
| LLM and rust rewrite together. And it does work so hopefully
| they get more attention and build it so I have an alternative
| browser to use
| mi_lk wrote:
| Yeah, this is glorified yak-shaving if we're being real. I'm
| not getting my hopes up for a true new browser
| rjh29 wrote:
| Andreas is not some kind of hustler. He spent years writing an
| entire OS (Serenity OS) before the web browser part happened to
| gain traction. If you were just trying to be an entrepreneur,
| why do that?
|
| The truth is more simple: he's a good engineer and leader,
| people recognised that and offered him sponsorships, and the
| project took off by itself.
| jonkoops wrote:
| I hope that this opens the door for collaboration between
| Ladybird and Servo, no need to reinvent the wheel for core
| components.
| mudkipdev wrote:
| Commenting about not reinventing the wheel on a Ladybird post
| is ironic
| jabl wrote:
| I thought the entire point of Ladybird was precisely to
| reinvent the wheel?
| jonkoops wrote:
| This is also the case for Servo, so it makes sense to
| collaborate.
| VoxPelli wrote:
| Servo has a distinct design goal that sets it apart from
| its predecessor within Mozilla and has already had
| offsprings that has made its way directly into Firefox.
|
| Its purpose is not to reinvent everything. It's not a hype
| project.
| nicoburns wrote:
| Unfortunately licence incompatibility may prevent that.
| Ladybird is BSD and Servo is MPL. This is also why there is
| only limited collaboration between Servo and the Rust GUI
| ecosystem.
| kneel25 wrote:
| > After the initial translation, I ran multiple passes of
| adversarial review, asking different models to analyze the code
| for mistakes and bad patterns.
|
| I feel like you just know it's doomed. What this is saying is "I
| didn't want to and cannot review the code it generated" asking
| models to find mistakes never works for me. It'll find obvious
| patterns, a tendency towards security mistakes, but not deep
| logical errors.
| herrkanin wrote:
| Your argument is just as applicable on human code reviewers.
| Obviously having others review the code will catch issues you
| would never have thought of. This includes agents as well.
| DetroitThrow wrote:
| >Your argument is just as applicable on human code reviewers.
|
| The tests many of us use for how capable a model or harness
| is is usually based around whether they can spot logical
| errors readily visible to humans.
|
| Hence: https://news.ycombinator.com/item?id=47031580
| Fervicus wrote:
| With humans though, I wouldn't have to review 20k lines of
| code at once.
| glhaynes wrote:
| So ask the AI to just translate one little chunk at a time,
| right?
| Fervicus wrote:
| That's not what happened here though.
| kneel25 wrote:
| They're not equal. Humans are capable of actually
| understanding and looking ahead at consequences of decisions
| made, whereas an LLM can't. One is a review, one is mimicking
| the result of a hypothetical review without any of the actual
| reasoning. (And prompting itself in a loop is not real
| reasoning)
| iamleppert wrote:
| I keep hearing people say "but as humans we actually
| understand". What evidence do you have of the material
| differences in what understanding an LLM has, and what
| version a human has? What processes do we fundamentally do,
| that an LLM does not or cannot do? What here is the
| definition of "understanding", that, presumably an LLM does
| not currently do, that humans do?
| mcpar-land wrote:
| https://ml-site.cdn-apple.com/papers/the-illusion-of-
| thinkin...
| kneel25 wrote:
| Well a material difference is we don't input/output in
| tokens I guess. We have a concept of gaps and limits to
| knowledge, we have factors like ego, preservation,
| ambition that go into our thoughts where LLM just has raw
| data. Understanding the implication of a code change is
| having an idea of a desired structure, some idea of where
| you want to head to and how that meshes together. LLM has
| zero of any of that. Just because it can copy the output
| of the result of those factors I mention doesn't mean
| they operate the same.
| u_sama wrote:
| That is what the testing suite is there to check, no?
| kneel25 wrote:
| You mean the testing suite generated by AI?
| Jolter wrote:
| It isn't, in this case.
| trflynn89 wrote:
| The primary JS test suite is maintained by the authors of
| the specification itself: https://github.com/tc39/test262
| u_sama wrote:
| No, a real test suite, either their own which they
| developped or the official ECMA one
| layer8 wrote:
| No. Testing generally can only falsify, not verify. It's
| complementary to code review, not a substitute for it.
| cardanome wrote:
| Yeah, I lost all interest in the ladybird project now that it
| is AI slop.
|
| No one wants to work with this generated, ugly, unidiomatic
| ball of Rust. Other than other people using AI. So you
| dependency AI grows and grows. It is a vicious trap.
| zamadatix wrote:
| Somehow they did use this as part of their approach to get to 0
| regressions across 65k tests + no performance regressions
| though + identical output for AST and bytecode though. How much
| manual review was part of the hundreds of rounds of prompt
| steering is not stated, but I don't think it's possible to say
| it couldn't find any deep logical errors along the way and
| still achieve those results.
|
| The part that concerns me is whether this part will actually
| come in time or not:
|
| > The Rust code intentionally mimics things like the C++
| register allocation patterns so that the two compilers produce
| identical bytecode. Correctness is a close second. We know the
| result isn't idiomatic Rust, and there's a lot that can be
| simplified once we're comfortable retiring the C++ pipeline.
| That cleanup will come in time.
|
| Of course, it wouldn't be the first time Andreas delivered more
| than I expected :).
| kneel25 wrote:
| That's convincing and impressive, but I wouldn't say it
| proves it can spot deep errors. If it's incredible at porting
| files and comparing against the source of truth then finding
| complicated issues isn't being tested imo.
| grougnax wrote:
| Great! I can't wait they totally ditch C++
| pizlonator wrote:
| Porting the JS parser to Rust and adopting Rust in other parts of
| the engine while continuing to use C++ heavily is unlikely to
| make Ladybird meaningfully more secure.
|
| Attackers are surprisingly resilient to partial security.
| npalli wrote:
| If it is this easy, surely the trend is Rust output being an
| intermediate pass of the LLM super compiler. A security subset if
| you will (like other kinds of optimization), it will move from
| Rust specs to some deeper level of analysis and output the final
| executable. Some brave souls will read the intermediate Rust
| output (just like people used to read the assembler output from
| compilers) but the LLM super compiler will just translate a
| detailed English like spec into final executables.
| Perz1val wrote:
| Do you seriously think LLMs will not just spam unsafe blocks in
| it like they do with any task ever?
| alabhyajindal wrote:
| > This is not becoming the main focus of the project. We will
| continue developing the engine in C++, and porting subsystems to
| Rust will be a sidetrack that runs for a long time.
|
| I don't like this bit. Wouldn't it be better to decide on a
| memory-safe language, and then commit to it by writing all new
| code in Rust, or whatever. This looks like doing double the work.
| nicoburns wrote:
| It doesn't have to all-or-nothing. Firefox has been a mixed C++
| and Rust codebase for years now. It isn't like the code is
| written twice. The C++ components are written in C++, and the
| Rust components are written in Rust.
|
| I suspect that'll also be what happens here. And if the use of
| Rust is successful, then over time more components may switch
| over to Rust. But each component will only ever be in one
| language at a time.
| fabrice_d wrote:
| You can't compare the choices made to evolve a >20 years old
| codebase with a brand new one. Firefox also as Rust support
| for XPCOM components, so you can use and write them in Rust
| without manual FFI (this comes with some baggage of course).
|
| The Ladybird devs painted themselves in a corner when
| choosing C++ for a new web browser, with many anti-Rust folks
| claiming that "modern C++ was safe". Well...
| LeFantome wrote:
| > The Ladybird devs painted themselves in a corner when
| choosing C++ for a new web browser
|
| That choice was never made. C++ was selrcted as the
| language of choice for SerenityOS. Since the goal of the OS
| was to make its founder happy, and C++ was his faviourite
| language at the time, that seems like an obvious choice.
| Later, as part of SerenityOS, there was a need for an HTML
| parser. It was written in C++ as was the rest of the
| operating system. Then that HTML parser evolved into a full
| web browser. As part of the SerenityOS project, that
| browser was written completely in C++. Then that web
| browser forked off into an independent project...
|
| Ladybird was already a fully functioning browser (not
| finished of course but complete enough to surf many web
| pages) when it was forked from SerenityOS to create a
| stand-alone web browser. The choice at that point was "keep
| evolving the current C++ code base" or start-over. I doubt
| the second option was even considered.
|
| They have been evaluating other languages since before the
| fork. Rust was evaluated and rejectd early-on. They even
| created their own language at one point.
| https://github.com/SerenityOS/jakt
| nicoburns wrote:
| > The Ladybird devs painted themselves in a corner when
| choosing C++ for a new web browser, with many anti-Rust
| folks claiming that "modern C++ was safe". Well...
|
| Perhaps, but in fairness the project was started in 2018
| when Rust was still new and unproven.
|
| > You can't compare the choices made to evolve a >20 years
| old codebase with a brand new one.
|
| I guess not, but I'm pretty optimistic about Ladybird's
| ability to adopt Rust if they want to. It's a _much_
| smaller codebase than Firefox (~650K LoC).
|
| This initial PR is already ~25k LoC, so approximately 4% of
| the codebase. It took 1 person 2 weeks to complete. If you
| extrapolate from that, it would take 1 person-year to port
| the whole thing, which is not so bad considering that you
| could spread that work out over multiple years and multiple
| people.
|
| And Firefox has shown that the intermediate state where you
| have a mix of languages is viable over the long term, even
| in a much larger and more complex codebase.
| VoxPelli wrote:
| Firefox was special in that Mozilla created Rust to build
| Servo and then backported parts of Servo to Firefox and
| ultimately stopped building Servo.
|
| Thankfully Servo has picked up speed again and if one wants a
| Rust based browser engine what better choice than the one the
| language was built to enable?
|
| https://servo.org/
| nicoburns wrote:
| As a Servo contributor, I am aware of Servo :)
|
| But I'm also cheering along Ladybird's progress. There's
| definitely room for more than one project in the space. And
| IMO the more browsers being built in Rust in the better.
| riku_iki wrote:
| > Wouldn't it be better to decide on a memory-safe language,
|
| it is totally possible to use some strict subset of C++, which
| will be memory safe.
| LeFantome wrote:
| Ladybird already does that
| wvenable wrote:
| One could do that but then they'd lose all momentum and the
| project would never get finished.
| Shank wrote:
| Completely ignoring the Rust aspect, I'm disappointed that two
| weeks were spent on something that isn't getting Ladybird to a
| state where it can be used as a daily driver. Ladybird isn't
| usable right now, and if it was usable, improving the memory
| safety would be a commendable goal. Right now I just feel like
| this is premature.
| alabhyajindal wrote:
| From their post on Twitter in 2024 when they adopted Swift, with
| a comment on Rust.
|
| My general thoughts on Rust:
|
| - Excellent for short-lived programs that transform input A to
| output B
|
| - Clunky for long-lived programs that maintain large complex
| object graphs
|
| - Really impressive ecosystem
|
| - Toxic community
|
| https://xcancel.com/awesomekling/status/1822241531501162806
| throw_rust wrote:
| Mayhaps he had a Damascene conversion? Not that I ever
| understood the need to change from C++ in the first place
| though.
| fmajid wrote:
| Considering David Tolnay's indefensible treatment of JeanHeyd
| Meneide, I'm inclined to agree with Kling on the toxicity of
| the Rust community. Evangelical fervor does not excuse
| douchebaggery.
| feverzsj wrote:
| Most likely some big sponsor requires them turn to AI slops.
| jp1016 wrote:
| The byte-for-byte identical output requirement is the smartest
| part of this whole thing. You basically get to run the old and
| new pipelines side by side and diff them, which means any bug in
| the translation is immediately caught. Way too many rewrites fail
| because people try to "improve" things during the port and end up
| chasing phantom bugs that might be in the old code, the new code,
| or just behavioral differences.
|
| Also worth noting that "translated from C++" Rust is totally fine
| as a starting point. You can incrementally make it more idiomatic
| later once the C++ side is retired. The Rust compiler will still
| catch whole classes of memory bugs even if the code reads a bit
| weird. That's the whole point.
| cyode wrote:
| I hope, with the velocity unlocked by these tools, that more
| pure ports will become the norm. Before, migrations could be so
| costly that "improving" things "while I'm here" helped sell
| doing the migration at all, especially in business settings.
| Only to lead to more toil chasing those phantom bugs.
| ozgrakkurt wrote:
| One of the biggest point of rewriting is you know better by
| then so you create something better.
|
| This is a HUUUGE reason code written in rust tended to be so
| much better than the original (which was probably written in
| c++).
|
| Human expertise is the single most important factor and is
| more important than language.
|
| Copy pasting from one language to another is way worse than
| complete rewrite with actual idiomatic and useful code.
|
| Best option after proper rewrite is binding. And copy-paste
| with LLM comes way below these options imo.
|
| If you look at real world, basically all value is created by
| boring and hated languages. Because people spent so much
| effort on making those languages useful, and other people
| spent so much effort learning and using those languages.
|
| Don't think anyone would prefer to work in a rust codebase
| that an LLM copy-pasted from c++, compared to working on a
| c++ codebase written by actual people that they can interact
| with.
| ukblewis wrote:
| It depends on your goals. If your only initial goal is to
| ensure the safety of your code, and that is rather
| important for a browser!
| palata wrote:
| > Copy pasting from one language to another is way worse
| than complete rewrite with actual idiomatic and useful
| code.
|
| But translating with automated tools is a much faster
| experiment.
|
| Sometimes (not always), rewriting from scratch ends up in a
| big loss of time and resources and never replaces the old
| version.
| arduanika wrote:
| These are two different kinds of rewrites, for two
| different kinds of codebases, in two different situations.
| The important thing is to know which kind of rewrite you're
| doing, and have the whole team onboard.
|
| For a browser like Ladybird that's trying to not break the
| user experience, it's much better to have a pure
| translation step, and then try to improve or refactor it
| later.
| hparadiz wrote:
| I did several web framework conversions exactly like this. Make
| sure the http output string matches in the new code exactly as
| the old code and then eventually deleted the old code with full
| confidence.
| dreis_sw wrote:
| Works even better if you have a good test suite, which is
| surely the case here with Ladybird
| MontagFTB wrote:
| Any word on how much more memory safe the implementation is? If
| passing a previous test suite is the criteria for success, what
| has changed, really? Are there previous memory safety tests that
| went from failing to passing?
|
| I am very interested to know if this time and energy spent
| actually improved memory safety.
|
| Other engineers facing the same challenges want to know!
| Retr0id wrote:
| If the previous impl had known memory safety issues I'd imagine
| they'd fix them as a matter of priority. It's hard to test for
| memory safety issues you don't know about.
|
| On the rust side, the question is how much `unsafe` they used
| (I would hope none at all, although they don't specify).
| MontagFTB wrote:
| It is entirely possible a Rust port could have caught
| previously unknown memory safety issues. Furthermore, a Rust
| port that looks and feels like C++ may be peppered with
| unsafe calls to the point where the ROI on the port is
| greatly reduced.
|
| I am not trying to dunk on the effort; quite the contrary. I
| am eager to hear more about the goals it originally set out
| to achieve.
| estebank wrote:
| You can look: https://github.com/LadybirdBrowser/ladybird/pul
| l/8104/files?...
|
| It seems like it is used mostly for FFI.
| Perz1val wrote:
| None at all, the generated AST and bytecode are stated to be
| identical
| MiiMe19 wrote:
| Someone will be put down like a dog.
| blub wrote:
| I feel similar about the potential of this technique and have
| heard this from other C++ developers too.
|
| Rust syntax is a PITA and investing a lot of effort in the
| language doesn't seem worth the trouble for an experienced C++
| developer, but with AI learning, porting and maintenance all
| become more accessible. It's possible to integrate Rust in an
| existing codebase or write subparts of larger C++ projects in
| Rust where it makes sense.
|
| I was recently involved in an AI porting effort, but using
| different languages and the results were fine. Validating and
| reviewing the code took longer than writing it.
| PowerElectronix wrote:
| What are Rust programmers to do now that LLMs can port code to
| Rust??
| maleldil wrote:
| Rejoice?
| Perz1val wrote:
| It reads like a joke without a punchline
| WesolyKubeczek wrote:
| I wouldn't mind if one result of this was a writeup on what
| patterns/antipatterns are there when converting code and concepts
| that used to be very aligned with C++-style OOP, deep inheritance
| and all that jazz, to what feels natural in Rust, and how you can
| rephrase those concepts without loss in the substance of what you
| need to do.
|
| I guess it's a long way off, since the LLM translation would need
| to be refactored into natural Rust first. But the value of it
| would be in that it's a real world project, and not a
| hypothetical "well, you could probably just...".
| zppln wrote:
| Cool project, but I'm a bit curious hearing how the rest of the
| project feels about this?
|
| I'm not sure how I'd feel if I woke up and found a system I
| worked on had been translated into an another language I'm not
| neccessarily familiar with. And I'm not sure I'd want to fix an
| non-idiomatic "mess" just because it's been translated into a
| language I'm familiar with either (although I suspect they'll
| have no problem attracting rust developers).
| drnick1 wrote:
| I wonder what is gained by this port though, if the C++ codebase
| already employed modern approaches to memory management. It's
| entirely possible that the Rust version will perform worse too as
| compilers are less mature.
| maleldil wrote:
| "modern approaches to memory management" aren't enough for
| complete memory safety.
| drnick1 wrote:
| Maybe, but it's certainly possible to write memory safe code
| in C++. It may be more or less difficult, but it isn't
| typically the ONLY objective of a project. C++ has other
| advantages too, such as seamless integration with C APIs and
| codebases, idiomatic OOP, and very mature compilers and
| libraries.
| npn wrote:
| My intuition is that they will convert to zig again when it
| stables. If it is possible to do it using LLM in 2 weeks for
| rust, then it would be the same for zig, too.
|
| While rust is nice on paper, writting complex software in it is
| mentally consuming. You can not do it for a long time.
| lukaslalinsky wrote:
| If they are looking for a memory-safe language, why would they
| convert to Zig?
| hu3 wrote:
| If they do, it could be because safety is a gradient and one
| variable among many in software development, albeit a very
| important one when it comes to browsers.
| nothrows wrote:
| This is sort of hilarious if you think about it. The Firefox
| browser is completely written in Rust. Now Ladybird is a "human-
| directed ai" Rust browser. Makes you wonder how much of the code
| the two browsers will share going forward given llm assisted
| autocompletes will pull from the same Rust Browser dataset.
| d-us-vb wrote:
| Probably not much: the requirement is exact equivalence of
| program inputs to outputs, and as such the agents are
| performing very mechanical translation from the existing C++
| code to Rust. Their prompts aren't "implement X browser
| component in rust", they're "translate this C++ code to Rust,
| with these extra details that you can't glean from the code
| itself."
| feverzsj wrote:
| It's like only 10% of Firefox is rust.
| DetroitThrow wrote:
| Only a small portion of Firefox is written in Rust. Apparently
| some of the most performant and least buggy parts are those in
| Rust, but again, only parts like the CSS engine.
| TiredOfLife wrote:
| https://github.com/mozilla-firefox/firefox Rust isn't even
| mentioned in languages used.
| hu3 wrote:
| I wonder where did you get the idea that Firefox was all Rust.
| Made me curious.
| artur-gawlik wrote:
| Interesting in context of that some time ago Andreas said that
| they failed on porting TypeScript compiler from TypeScript itself
| to Go lang by using LLMs and they went with manual port
| https://youtu.be/uMqx8NNT4xY?si=Vf1PyNkg3t6tmiPp&t=1423
| onetom wrote:
| Were there any immediate benefits of this conversion, e.g.
| reduced memory use or lower CPU utilization?
| GalaxyNova wrote:
| Likely the opposite, as safe Rust has some extra safety checks
| for things like array bounds.
| shevy-java wrote:
| Some time ago I was perma-banned from the Ladybird github
| repository. One can say it is warranted, or not (people have
| their own opinion; I completely disagree with their decision).
| Now that this has happened, I can speak more freely about
| Ladybird.
|
| Naturally this will be somewhat critical, but I need to first put
| things into context. I do believe that we really need an
| alternative to Google dominating our digital life. So I don't
| object that we need alternatives; whether Ladybird will be an
| alternative, or not, will be shown in the future. Most assuredly
| we need competition as otherwise the Google empire moves forward
| like Darth Vader and the empire (but nowhere near as cool as
| that; I find Google boring and lame. Even skynet in Terminator
| was more fun than Google. Google just annoys the heck out of me,
| but back to the topic of browsers).
|
| So with that out of the way ... Ladybird is kind of ... erratic.
|
| Some time ago, perhaps two months or three, Andreas suddenly
| announced "Swift WILL BE THE FOREVER FUTURE! C++ sucks!!!".
| People back then were scratching heads. It was not clear why
| Swift is suddenly our saviour.
|
| Ok, now we learn - "wait ... swift is NOT the future, but RUST
| is!!!". Ok ... more head-scratching. We are having a deja-vu
| moment here... but it gets stranger:
|
| "We previously explored Swift, but the C++ interop never quite
| got there, and platform support outside the Apple ecosystem was
| limited. Rust is a different story."
|
| and then:
|
| "I used Claude Code and Codex for the translation. This was
| human-directed, not autonomous code generation"
|
| So ... the expertise will be with regards to ... relying on AI to
| autogenerate code in ... Rust.
|
| I am not saying this is a 100% fail strategy, mind you. AI can
| generate useful code, we could see that. But I am beginning to
| have more and more doubts about the Ladybird project. Add to this
| the breakage of URLs that are used by thousands or million people
| world-wide (see the issues reported on the github tracker); or
| also the fact that, once you scale-up and more and more people
| use ladybird, will you be able to keep up with issue trackers?
| Will you ban more people?
|
| In a way it is actually good that I am no longer allowed to make
| comments on their repository because I can now be a lot more
| critical and ask questions that the ladybird team will have to
| evaluate. Will ladybird blend? Will it succeed? Will it fail?
| Yes, it is way too early to make an evaluation, so we should
| evaluate in some months or so, perhaps end of this year. But I am
| pretty certain the criticism will increase, at the least the
| moment they decide to leave beta (or alpha or whatever model they
| use; they claimd they want a first working version in this year
| for Linux users, let's see whether that works).
| mrorigo wrote:
| ANTLIGEN!
| fdefitte wrote:
| The "human-directed, not autonomous" framing is the part people
| keep glossing over. Claude Code here is a compiler-level
| translation tool, you are still the architect deciding what gets
| ported and in what order.
|
| The real question is what this does to migrations that never
| happened because 18 months of rewrite did not pencil out. A
| 2-week port fundamentally changes that calculus.
| kayo_20211030 wrote:
| I don't get it, and I don't have a dog in the C/C++ vs. Rust
| race. Ladybird has ~1200 contributors with a predominance of C++
| contributions, followed by HTML, and with "other" lying at 0.5%.
|
| That's a lot of people contributing.
|
| How many of them will be less willing to contribute in the
| future, and less productive when they do if a sizable portion is
| in Rust? Maybe there'll be more contributions and maybe there'll
| be less. I don't know. If you've managed to develop a community
| of 1200 developers who are willing to advance the project why
| upset the applecart?
| Perz1val wrote:
| There is a flock of people yelling around that they'd
| contribute if it was Rust, but won't touch C++
| einpoklum wrote:
| Chatbot-translated code which is C++ foisted onto Rust? I will
| respectfully roll my eyes.
|
| Ah, but I see they actually haven't done that to most of their
| code, so maybe it's just a bit of pandering to the hype and
| fashion.
| storus wrote:
| This is really YOLOing as the original author doesn't know Rust
| well so what happens if they hit some complex production issue
| LLM aren't aware of? Hiring an expensive consultant to fix that
| until the next LLM iteration?
| etcetera1 wrote:
| > what happens if they hit some complex production issue
|
| they learn Rust
|
| it takes a couple of years
|
| it's not that hard.
| drakythe wrote:
| I'm as anti LLM use as they come, but this appears to be
| migrating libraries from already funcitoning C++ code. In the
| case of your hypothetical I suspect the course of action will
| be "shelve this library port until someone with domain
| expertise and Rust experience can look at it". Its not like he
| chucked the whole codebase at the GenaI gods and said "Port it
| to Rust!".
| bgdkbtv wrote:
| This may sound stupid, but I wonder if using GPUI for a web
| browser could have some performance benefits...
___________________________________________________________________
(page generated 2026-02-23 23:00 UTC)