Live data from Hacker News

Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

twitter.com

701–710 of 754 posts

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#701

Earlier quoted context omitted.

Since the LLM craze started I have always assumed it would end up in a place where programming languages are dead and LLMs generate something more low level. Programming languages were always designed as an abstraction to allow humans to more easily instruct a computer than by writing binary or assembly. If humans write natural language and don't check the generated code, there's no reason to take the hit of generati…

If anything LLMs should use something higher level because it compresses the context and makes programming closer to natural language they are trained on. Forcing LLMs to do a shitty job of what a compiler can do deterministically is not a good approach IMO.

Low level was the wrong term for me to pick there. I was meaning more along the lines of "purpose built". I.e. I could see a language, potentially still an abstraction requiring a compiler, that isn't meant to be particularly meaningful or inspectable by humans. For LLMs your right, conciseness would be important and that would likely mean it would be compiled.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#702
post #695
post #630

Earlier quoted context omitted.

LLMs have no conception of time, unless you explicitly feed in timestamps to the context

It doesn't stop LLMs provide "this feature set will require 4 months to finish" (and then finishing it one hour)

Sorry yeah, I meant to say LLMs have no concept of time, so time estimates they give are almost always hallucinations

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#703

Earlier quoted context omitted.

zig is unmanaged memory. But rust also allows memory leaks, and they're not uncommon in large, complex programs. So this rewrite will not necessarily control for that.

What language doesn't allow memory leaks?

I suppose all languages allow them, depending on how you define a memory leak. Garbage collected languages generally prevent them, since you never have to explicitly free memory, but if there are reference cycles, that memory can never be freed automatically. Rust has the same problem, but since rust uses lifetimes to understand when to drop things, many people expect that this will mean there can be no memory leaks, but leaks are not considered a correctness or safety issue (oom is a panic and panic is safe!). Not only explicitly possible (through Box::leak) but also possible by mistake (again, usually through reference cycles).

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#704
post #576
post #262

Earlier quoted context omitted.

I’ve struggled to get Opus to not write the weirdest possible Rust, ignoring all idioms and so on. Any tips?

Be absolutely ruthless with technical debt. Opus is perfectly capable of producing idiomatic code in any mainstream language you please, but will seize on any opportunity to justify writing basically-python instead because that's "consistent" with the "convention". Deprive it of that excuse.

Yeah that’s basically what I mean! I have no issues wrangling it myself, but now I’m curious how those who are managing “fleets” of agents while shipping four features a day are doing it. They’re not, I’d assume?

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#705

Earlier quoted context omitted.

> Also their feelings are not hurt by what you or I think, they don’t care. Definitely not true, they tend to care more than most.

They generally care about what powerful/influential people think. I’m not powerful or influential, but I guess maybe the person I was talking to is. If so I apologize for the miscommunication.

They care. They are very sensitive to their public image and most cannot tolerate criticism or disapproval.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#706

Earlier quoted context omitted.

> they are not governed by multibillion dollar companies Every tech you mentioned is absolutely governed by multibillion dollar companies. Something like 75-85% of OSS code is contributed by employees doing their day job. Most Linux and Postgres contributions come from those same employees. HTTP and TCP/IP are managed by standard bodies and industry working groups that, you guessed it, are governed by multibillion do…

The usual model for OSS projects is that initially they are written for free. Then an inner circle forms and exploits the second generation of idealists who write entire large features without ever getting the same rights. Some of the inner circle move to corporations to increase their power and are joined by corporate developers (sometimes their bosses) to take over the project. A lot of corporate OSS development ar…

This is a nice fantasy, but that's all it is. Most of the code used by corporations is also mostly contributed to by other corporations. Contributions by volunteers is the exception for most of the projects in this context. I also don't think this is a bad thing.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#707
post #436

Earlier quoted context omitted.

I have seen, many times, code that has lots of tests but don't work. Why? Some of the patterns that I saw: * The code is only called from tests but never called in production * Tests are not testing the actual application logic, or the logic that matters. In some cases, the tests have nothing to do with the application code at all, because it does not even run any application code. * Tests repeat the same logic as in…

I think you and I don't share what is a "test". Are you thinking about unit tests? I'm thinking about unit tests, smoke tests, integration tests, e2e tests, functional tests, manual QA tests and probably even "the-product-works-as-expected-as-I-can-see-from-the-amazon-reviews-of-our-clients tests". I agree with your point of view in general, but "having tests" doesn't mean "having great tests". If I rewrite my code a…

I'm not interested in debating what "test" means. There is a standard definition in the software industry.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#708
post #408

Earlier quoted context omitted.

But usually companies are much more careful before even spending that half a million. (And most companies don't have that money sitting around.) They would do small PoCs, do comprehensive benchmarks and evaluations of those PoCs, and decide whether to actually go ahead, and, more importantly, stick to it. Being able to afford half a million doesn't mean you do it on a whim, or just throw all of that away if things do…

> They would do small PoCs, do comprehensive benchmarks and evaluations of those PoCs, and decide whether to actually go ahead Perfect, $1mil in salaries to spare the company $500k in spend :)

You seem to have some sort of misunderstanding of what PoC means or how it works.

Nobody is spending $1mil in salary on this kind of PoCs.

And I guess the word "small" is really difficult to grasp.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#709
post #407

Earlier quoted context omitted.

> Do you scrutinize the rest of your dependencies this way? You don't?

No, and I don’t really believe that you do to this degree either.

Sounds like a you problem.

Re: Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

#710
post #673

Earlier quoted context omitted.

> they are not governed by multibillion dollar companies Every tech you mentioned is absolutely governed by multibillion dollar companies. Something like 75-85% of OSS code is contributed by employees doing their day job. Most Linux and Postgres contributions come from those same employees. HTTP and TCP/IP are managed by standard bodies and industry working groups that, you guessed it, are governed by multibillion do…

The way I understood op is that we don't necessarily have to pay to use linux or postgres (when self hosting, for example). But we have to pay to use claude code... which sucks big time (also, open source models are behind private models)

Claude Code isn't OSS, so I fail to see the connection. You're paying for compute, not access to code. I'm personally more than happy to pay for access to that compute.
Post reply on HN