someone post a link to the code github is cancer for navigating

There are probably 10 million javascript runtimes and literally trillions of javascript programs in the trainingdata

>>108790505
does Jared think Rust will stop him from leaking memory?

I truly do not understand people who have memory issues in "non-safe" languages in the year 2026. all you have to do is turn on the sanitizers and use region based memory management. that's literally it

but I don't like Zig either

I don't understand how memory leaks happen. Gotta be a language thing.

>>108790505
if i wanted a vibe-coded js runtime written in rust, there is one based on v8. but guess what? no one is going to use either.
and the fact that this doesn't even pretend to be an idiomatic rust code project makes this shittier and funnier at the same time. but not as funny and sad as the fact that "AI" companies hire jeets like you to talk them up everyday, everywhere, INCLUDING this /g/eeted space.
now, go COPE more and harder on your master's behalf here >>108789196
>t. rustacean

File: ick.gif (1.09 MB, 380x284)

1.09 MB GIF

>>108790505
>Rust

File: IMG_5602.gif (2.32 MB, 477x290)

2.32 MB GIF

>>108791154
I feel the same way about types. Everyone is obsessed with types and I'm wondering what kind of retard you have to be to have constant type errors and even if you get one it's the easiest bug to fix. The lowest of low hanging fruit but people seem to make their entire lives revolve around types. It's so strange.

File: 8dc.jpg (101 KB, 1231x1242)

101 KB JPG

Has a single factual argument against Rust ever been uttered ?

>>108791649
jeets (and people matching their level) tend to be genuinely filtered by it for some reason.
does that count as a factual argument against rust? well, it depends ;);)

>>108790505
>>108791649
to Jared and you, rust doesn't prevent memory leaks
>>108791638
you just sold me on Rust

>>108791815
i love how /g/eet nocoder "websearch experts" don't know the difference, or pretend to not know the difference, between manual memory management and
>a leak is not unsafe
>rust allows you to *explicitly* leak
>there are potential logical situations where a value could stay alive too long (an unsolvable semantic issue)

>>108790505
>The current state-of-art AI-powered coding assistant from Anthropic.
Ok ad bot.

File: IMG_5115.gif (3.95 MB, 400x300)

3.95 MB GIF

>>108791815
>you just sold me on Rust
Don't forget to buy your HRT and schedule your gender reassignment surgery!

File: HHrcCPcbAAA0Edz.jpg (442 KB, 1616x2048)

442 KB JPG

>>108790505
God will be written in Rust.
Repent.

>>108791649
>Crucially, unsafe code is not a way to skirt the various rules of Rust, like borrow checking, but rather a way to enforce those rules using reasoning that is beyond the compiler. When you write unsafe code, the onus is on you to ensure that the resulting code is safe.
>The compiler is smart, but bound by rules that might not be forgiving for what you try to do, while what you are trying to do is perfectly safe. The unsafe keyword allows you to take on that responsibility.

seems to me that a language which necessarily includes methods to sidestep its own reason d'etre is pretty fucked? no??

>>108790505
>you are now spending $$$1600+tax every month to write free software, for free, no income

The usual hackernews luddites are now turning into conspiratards. "He works for Anthropic! This must be fake! LLMs being useful can't be true!!"

>>108790505
I don't understand how these people can do this. I literally spent 8 hours last Friday with Claude trying to debug a simple issue in Perl and it couldn't figure it out. in the end, I had to switch to using a different function to make it work. I refuse to believe anything anyone says about how good Claude is.

>>108792747
>I don't understand how these people can do this.
I also don't understand how conartists do their thing

>>108792747
Perl is shit for vibe coding and you are probably bad at prompt engineering.

Another example from that hn thread: https://news.ycombinator.com/item?id=48077571

But this one took five months.

>>108792740
>luddites
(disclose which j are you, jeet or jew, before replying)
code conversion is neither novel, nor useful on its own. it can however be a useful starting point. in other words, nothing actually relevant happened yet.
as for orange tards, conflicts of interest, and a desire to appease an employer, are implied socio-economical predispositions. to assume their existence and role doesn't require entertaining conspiratorial thoughts.

>>108792747
AI is useless for niche languages, which Perl currently is.

>>108791036
still need a human for proofreading and polish

>>108792835
Lel you think that guy proofreaded +1 million lines in four days? We have test units for that.

>>108792835
Fuck poland

>>108792853
who writes the test units?

>>108792766
>prompt engineering
is this unironic

Hey guys, have you seen how you can translate French to Italian on the google? absolutely mind blowing

>>108790505
lmao... what is even the point in the retarded postgres "rewrite"? I read the dude's blog and I don't get the impression there is any reason to believe this guy could ever deal with the pathological bugs that are bound to surface with this kind of thing.
Who is this for? Why burn $1,600 USD a month on tokens to churn out pointless AI transpilation slop?
It's also really funny to me that all these luddite btfo threads always have a recurring theme: someone using AI to do something entirely non-novel; wow, yes, some adderall-snorting silicon valley spastic with more money than sense can launder your open-sores project through an LLM, provided it's a well understood topic and there is a mountain of extremely well-written tests to use as a harness (hmmm, reminds me a lot of the Anthropic "C compiler", Cloudflare's Vinext shit, etc).

Anyway fuck you jeet or jew

I'm not pretending like there isn't value in this.
But at the same time the aspects of praise are actually the aspects of concern for me.
I believe that it wrote the code, and the tests pass, and that it at least builds and runs.
But you are not going to convince me that code has been verified to actually be good, and I mean that in multiple senses.
Did anyone actually review the code. Touch it up. Etc. or did it just produce a technically working variant and now everyone has to polish it by hand anyway and actually vet the gaurantees the AI claimed to have made.

>>108792944
Claude

>>108793146
what checks the AI test code for correctness?

>>108793223
look, they are not ready for this conversation yet.

>>108792974
https://en.wikipedia.org/wiki/Prompt_engineering
https://cloud.google.com/discover/what-is-prompt-engineering

Were you living in a cave the past four years?

>>108793223
They test the implementation with JavaScript standard test suite.

>>108790505
All this could've been avoided if they just used C++ instead of some memelang.

>>108793363
dont get your big boy shorts in a knot, mr sanitation technician

>>108790505
why not just use deno at this point?

>>108793502
Anthropic bought Bun, they use it for Claude code.

>>108793371
who writes that blackbox test suite?
who checks its validity and completeness?
and is blackbox testing sufficient in your evident experience?

>>108793502
deno uses v8, which is c++.
there is already a meme vibe-coded rust project based on v8.
>t. rustacean

>>108790505
Rust needs to be banned globally.
Fuck them troons.

>>108790505
How the fuck is it basically 1m (S?)LOCs though? For just a runtime (that sucks ass and nobody uses anyway)?

>>108791154
Yeah, ass number but I estimate that at least 95% of memory-related issues are due to abuse of dynamic disordered memory. Rely more on static memory and use region-based memory management for cases where dynamic reservations really are reserved (very rare in practice, surprisingly so). Suddenly memory issues go away like magic. I tested these kinds of approaches since around 2015 and successfully applied them to embedded projects but also to ~200k sloc game engine projects I'll never use for anything or never release... anyway, I'm not a fan of zig but zig also has defer so there really shouldn't be any excuse for memory issues in zig.

>>108791638
I also agree with this. There is no evidence that types help anything beside "I feel it does".
The fact is the real issue is static analysis, not types. And types are, I ~feel~, the wrong device to express the analysis fixtures you would like to happen, though that does not exclude the notion that maybe some other kind of annotations provided by the programmer could help static tools perform analysis more easily.

>>108792703
he is an anthropic employee. he has free unlimited access to opus and mythos.

>>108791649
Many times. Here's one: rust borrow checking makes extending existing code bases that were not planned in the waterfall style onerous due to small changes to types possibly requiring propagating annotations throughout the entire codebase in non-obvious ways. As a result, in practice, virtually all extant codebases rely extensively on boxed types, which mitigates rust's initial design advantage regarding speed + safety through borrow checking as opposed specifically to reference counting which is known to be slow, especially in pathological cases.

>>108792804
Actually code conversion is insanely useful on its own. It potentially trivializes the development of new languages, and allows converting complex software written in languages more suitable for prototyping into languages more suitable to production. It also implies we only need 2 languages: your platform's assembler language depending on the program of your choice, and any high level language of your choice. Alternatively, a 3rd language to serve as a lingua franca intermediary layer for code sharing/versioning/etc.

The problem is that it doesn't work. I have personally been keeping track of and testing code conversion from the beginning of the llm craze. Even the simplest code conversion attempts still fail dramatically to this day. The only progress that's been made has been through better orchestration (e.g. better agents and tools) and not through better llm's.

I also argue that while code conversion is not novel in and of itself, universal code conversion sure is.

>>108792808
I typically try my conversion gauntlets (see >>108794051 ) between python and javascript precisely because they should be the easiest possible case. Still can't hack it. Only long after it's cracked that problem can we get anywhere with this.

>>108790505
There seems to be a reoccuring theme with these rewrites. Existing codebase with extensive test suite to iterate LLM churn against. The useful part is the test suite, which essentially acts as a spec.

>>108792835
Yeah, same with everything AI, a human still has to be involved. But it lets fewer people accomplish much more, basically working as supervisors for the AI wageslaves

>>108793909
Bun uses JavaScriptCore, which is C++ (and not ported)

>>108793990
Are you saying to use arenas instead of random heap allocations? Doesnt any reasonable implementation of malloc do this under the hood?

>>108794051
i was referring specifically to code conversion that works, for some meaning of works, which doesn't involve LLM's. like converting C to low-level unsafe Rust that is not idiomatic.
this can be a useful starting point.
"fancy" conversion, like the one you describe in the start, and what is to an extent marketed by LLM's is not workable, simply because it's not possible.
languages don't represent semantics with the same logic blocks, patterns, paradigms, and abstractions. so the best you can get is a non-idiomatic logical approximation that you can start from, not treat as an end result.

>>108794380
>Are you saying to use arenas instead of random heap allocations? Doesnt any reasonable implementation of malloc do this under the hood?
No, it's more pervasive. For example if you're working on trees (as is common if you're parsing something complex for example), you may want to use linear regions for allocations, because
>you don't know how deep your trees are in advance
>it's not practical to estimate accurately
>once you're done with a node, all its children are irrelevant as well
It's tied to how the program itself is logically structured and is not about the implementation so much as the interface you use to interact with memory. That is a stack model instead of a graph.

If you are parsing something of small bounded size (like you know there can be at most 3 nodes or you are at liberty to reasonably reject entries that are deeper than that), then you can do even better and statically allocate (e.g. in bss or data depending on details).
(Obviously there are ALWAYS cases where "graph" models, i.e. the malloc/free interface, is the only reasonable approach. I merely claim that such cases are a small minority, and thus this is the wrong default interface).

Most malloc implementations don't do arenas by default because it is not a good default for performance eitherway (it has pros and cons depending on allocation patterns: consider fragmentation patterns especially), but it is good to point out that indeed, many software classes default to arena allocators now. While this doesn't really help fix the user-side memory errors like a better interface does, it strongly suggests that the model used by default is wrong, doesn't it? There's a reason why arenas perform better and exhibit few downsides for these programs!

>>108794430
Any turing complete language can be reduced to a turing-equivalent program which can be expressed by any other turing complete language, the vast majority of languages use identical basic components and the few that don't have straightforward mappings due to the above, and idioms are just a differing set of preferences to the exact same patterns that emerge due to the structure of these languages. Not only is your claim false for any practical use (e.g. ignoring the ease of translation between paradigms) but it is demonstrably false since there are many deterministic tools that transpile in human readable ways and follow the right idioms (as well as tools that transpile in non-human readable ways, which is not the topic here).
Even worse, plenty of code generators from non-code sources (e.g. low-code and no-code tools) exist that produce idiomatic code as outputs.

In the end, if you personally can't transform a for loop in C to the equivalent in python, despite such grand idiomatic differences as for;; vs range-type loops, you are unironically doing worse than these LLMs today.

>>108791036
you didn't make a victory, retarded poser.

>>108790505
its strange how good they are at translating meanwhile I only want a basic recreation of noita in c++ with multithreading and claude shits itself every fucking time.

>>108794808
>turing complete
stopped reading. i didn't realize i was talking with a sophomore.

>>108791972
dios mio.... el antichristo......

>>108792747
Once you go off the beaten path AI coding generation starts falling off.
Cursor style predictive autocomplete is always useful ofc, but trying to get coding models to write good VBA code is always like pulling teeth

>>108792747
Claude isn't that good and its all astroturfing.

how many bombs do we think are in the ai version of the codebase?

>>108795171
haven't you heard? code quality doesn't matter anymore. Even if it gets pwned, who cares?
IBM, like retards, said we shouldn't let computers do things since they aren't liable. Modern Silicon Valley GODS realized that not being liable is the entire point.

>>108790505

im just waiting for the slop to cause issues (cuz obviously no one reviewed it) and the using that as an arugment against rust. thats you, thats how you rok

>>108790505
Isn't Rust notorious for memory leaks?

>>108795281
that's the joke

>>108795007
I accept your surrender.
t. 24 years professional exp including FAGMAN

>>108795370
>FAGMAN
would explain a lot if true

>>108790505
Good. Now there will be zero reason to even bring up their embarrassing Zig fork.

>>108795548
It's true, but I quit after just after a year because the people were the dumbest "programmers" I had ever worked with, and the politics were insane.
I've been mostly in startups to small companies with a stint in a mid-sized one in my career so far. Startups is also where I met the most brilliant (but also the dumbest) people I've ever worked with. Can also be rocky (including with politics) but much better mileage there.

>>108791236
>keep adding elements to a dynamic array
>forget to clean it up
Total mystery

looks like none of these are complete lol

>>108791236
Yes. It's a language thing. A thing that happens when you use a language. Try using a language, whichever you prefer, and you'll understand.

File: '(zun-sneed).jpg (269 KB, 512x496)

269 KB JPG

>>108791638
>>108794014
Types are good for compiler inference in general, not to mention at lot of optimizations you can achieve just by having a strong typing system.
>lowest of low hanging fruit
Not really. If your language has weak/duck typing, on a fairly large codebase, it will be very common to face situations where the fucking compiler/interpreter doesn't catch shit and you're on your own to navigate all the flow until you get what's wrong.
A 2 million LOC Clojure project taught me that strong typing is always welcome. I hate Lisp because of that btw.

>>108794014
>I also agree with this. There is no evidence that types help anything beside "I feel it does".
Then why has every single relevant and even semi-relevant dynamic lang eventually added type hints or static types?

>>108792804
goal posts shifting again

>ai hallucinates
>ai cant code
>ai cant work on big codebases
>ai cant do non-coding tasks
>ai cant work autonomously
>ok ai can do all that, but w-we could do that before too

lmao

its over
ludites lost

>>108790505
>there will be a blog post on this. on what this means for bun ...
It means absolutely nothing for bun because nobody in their right mind would switch their system over to a barely tested vibecoded reimplementation by some rando
I don't even want to know how many subtle bugs and logic errors were introduced in the process. I'm sure there are plenty.

>>108795958
For speed/compiler optimization there are 2 main ways to go: data annotations or function annotations. Function annotations is what happens in languages that have no types, like forth or low level assembly languages, where you have to specify 1 + 1 but 2.0 f+ 3.5 and so on.
However, I debate the notion that the specific annotations we need to use are type annotations. Ultimately, types are a shorthand for the byte layout of what you're placing and the register set to use to interact with the object, but as previously hinted at, assembly language HAS no types (neither does, obviously, machine code), so the notion that type annotations are required for fast code is, of course, wrong (simply write in asm!)

>>108795958
>it will be very common to face situations where the fucking compiler/interpreter doesn't catch shit and you're on your own to navigate all the flow until you get what's wrong.
And that is totally wrong. This is language specific. Some languages check in advance (typically in the source -> bytecode phase). Except in cases where you use actual dynamism (e.g. hasattr in python), it can be inferred without any annotations. Furthermore, weak and duck typing are orthogonal concepts. Many strong dynamic type systems, also with and without duck typing, exist.

>>108797157
The really funny implication here is that, because a vibecoded mountain of shit passed 99.8% of Bun's tests, most of those tests are probably worthless, which tells you all you need to know about Bun.

>>108795978
As I said, "because I feel it's good" cargo culting. That is the objective truth about that part by the way: these decisions have never been based on data of any kind, not even on experience.
One can ideate all kinds of potential advantages to static types or type hints: it discourages use of dynamism, which could be a strong advantage in big corpo settings when you want pajeet to write your code without making everything explode too hard. It could also help pajeet communicate intent so that pawel can fix the code easier. It could even act as rudimentary unit tests for pajeet to shit on the sidewalk instead of the street. But again, there is no evidence of any of these, type error rates in very large production typeless codebases are estimated to be around 3% (and a large amount of these is not about lack of types but lack of verification by the interpreter before running), unit tests are still needed for anything even remotely serious even in the typefullest language, Any/void* abuse is a common thing, etc.

File: IMG_5512.gif (1.81 MB, 298x301)

1.81 MB GIF

>>108795978
Because retards keep demanding training wheels so more brahmin and dalit has less errors saar, types are important and every language most have them, do the needful and add types to you langauge.

File: IMG_5581.jpg (89 KB, 650x650)

89 KB JPG

>>108797694
Or it tells you all you need to know about test driven development... but most people here are not ready for that conversation

>>108797698
Static types aren't the magic bullet that webshits think they are but they absolutely prevent more than 3% of errors during development. In any large enough project, if you don't carefully avoid the pitfalls of dynamic types like Lisp weenies do, changing the codebase without breaking things becomes extremely annoying.

If you are an idiot, dynamic typing improves dev speed because the big meanie compiler isn't bullying you. If you are not an idiot, dynamic typing (outside of Lisp) just slows things down.

>>108797752
>they absolutely prevent more than 3% of errors during development.
There are typically a lot of mitigating factors that make measuring the exact value hard. The 3% figure I quote is the best estimate I've seen and yes, it is a sketchy estimate. But it is based on an analysis of large python codebases and estimation of errors from there.
The problem is that the shape of the language ITSELF (irrespective of types) can lend itself to easier or harder bug finding, as per my previous mentions of mechanisms in some dynamic languages to check things like name typos BEFORE any execution (you point out lisp: common lisp systems do precisely this). I will also point out that lisp is strongly typed and that type annotations are natively supported and commonly used, though largely for optimizations and not checking. In fact, if type annotations helped against bugs so much, why WOULDN'T lisp programmers use them more especially in larger codebases?
Changing things in a codebase without unit tests (again, regardless of types) is always annoying. After that, some languages have better facilities than others to do that. Lisp is especially well-suited for refactoring because parens naturally lend themselves to factoring. Forth is also very good at this because stack-oriented operations are idempotent to operation ordering (but beware parsing words!). Python makes refactoring hell not because it's dynamic, but because of some horrible design choices such as using the same syntax to introduce a new variable and to change its value, and significant indentation without "structural cues" (in the sense of ML-family languages). I submit that the shape of the language, rather than the type annotated vs non-annotated status, determines ease of changes in a codebase.

On the flipside I also want to preemptively point out that static typing does not prevent the use of duck typing with ML types.

>>108797883
Additionally, I also have not seen any evidence that dynamic languages make programming faster/easier than static types when amortized over a long project (but it is a clear win in e.g. small scripts).

I posit however that it allows small experiments with much better turnaround time, though some modern (and not so modern: see lisp) languages with types can go a long way, especially with better incremental compilation and type inference.

So where's your proof about static types preventing bugs, especially more than 3%?

>>108790505
aside from uv and "I hijacked your project" is there any other selling point to rust?

>>108797926
>So where's your proof about static types preventing bugs, especially more than 3%?
Mainly personal and colleague experience. Supposedly there are also studies that prove it solves about 1/5 of bugs, but they're mainly about frontend webshit so I'm not sure how universal they are. If dynamic typing was JS's biggest issue, that would be a profound improvement, frankly.

The big problem with dynamic typing is that every language that uses it has to deal with the pitfalls, but few of them try to reap the benefits. Usually the only tangible upsides are interpreter speed and being able to hack shit together as fast as possible. Python in particular is a language that has no other reason to be dynamically typed, and imo, dynamic types have a tendency to take a language's flaws and exacerbate them.

This isn't really about type annotations either. In Python they're a bandage on a bullet wound because they are not enforced by the language, so it's possible to incorrectly annotate something. I've rarely seen this happen but holy fuck you will want to kill someone when it does.

Lisp is very unique in how it makes effective use of dynamic typing. It and Smalltalk are the only languages I think would be lesser with static types since they make interactive development practical, which in turn makes catching runtime bugs a lot easier. In their cases you actually WANT the language to be less rigid at runtime.

>>108798059
>I just feel it's good
Called it.
> Supposedly there are also studies that prove it solves about 1/5 of bugs,
Link please. I have never seen any such studies and I've tracked this for years. The highest figure I have ever seen was 15%, which comes from 'code complete', but the estimation method was just not very good. The 3% figure is also consistent enough with studies where the investigators rewrote a few popular python codebases in haskell to use the type discipline to identify bugs, where we can estimate a 4% or so bug rate that could be caught that way, but hard to tell if it's purely due to types also (there's also always the confounding question of types vs "sufficiently powerful types"). I don't care if the findings are not universal, so long as they're not bogus (e.g. pretending that a non-type bug like off-by-one or memory errors could totally be caught by types alone -- I deliberately don't care about linear + dependent types as they're not practical in any current implementation, or comparing highschoolers' code, or similar contrivance). At any rate, I'm always very interested on the subject.

>>108790505
Zig is a very simple language with few high level abstractions. Just structs, functions and pointers. If you're fine with using unsafe everywhere, you can program in that same basic style in Rust as well. So what's supposed to be the hard part? You could probably do this with a transpiler. Anyone who is impressed by this is an idiot

>>108798006
In theory it was supposed to be C speed without the safety risks, while also being less of a pain than full proof systems. In practice it gets the worst of most worlds: java-tier verbosity, C++-tier token soups, pre-clang C++-tier errors and compile times, reference counting speed (because it's the only way to go after your system needs to be expanded unless you want to rewrite your entire codebase for every tiny change you make), and javascript-tier supply chain weaknesses. It does get rid of typical memory errors of C programs though.

There is a reason why the only thing rust is known for is 'rewrite it in rust' efforts, and that's not because rustfags are getting funded to MITify existing GPL software only: it's also because the only way you can be productive in rust is if you have a preset exact spec to implement, and the spec never changes. That is, it's not that there are no other efforts in rustland, only that these are the only efforts that survive to become sufficiently complete to be discussed.

>>108798059
smalltalk people invented Test driven development to avoid static typing. their argument is that tdd > static typing because the tests will catch type errors but also logic errors and thus once you have tests, static typing become an useless annoyance.

>>108796612
>(disclose which j are you, jeet or jew, before replying)

>>108790678
https://github.com/oven-sh/bun/tree/claude/phase-a-port
its quite hard to read bun seems like a complete clusterfuck

File: 781px-Vespula_vulgaris_po(...).jpg (204 KB, 781x720)

204 KB JPG

I hate Rust trannies. This whole field went to fucking shit. Every normie learning to "program", AI, jeets. Fuck my life. Zig and Odin are two good things that came out in this field since a decade but of course it's muh "unsafe". Rust trannies produce "safe" bugs a lot more anyway. And obviously a fucking MIT license. Trannies love to help corpos steal code. But it's that zigger fault he licensed it that way

>>108798374
what zig and odin have brought to and from plt?

>>108798117
>>I just feel it's good
>Called it.
Sometimes a common opinion exists for a reason other than cargo culting. In this case I'd argue that trying to exactly quantify a rate of bugs prevented is stupid because these sorts of experiments don't reflect how actual software development works.
In the case of whatever Haskell experiment you're talking about, the premise is flawed because an existing codebase that's been thoroughly tested is obviously going to have less type errors. Dynamic typing usually bites me in the ass when I'm trying to refactor something and the tests are screaming bloody murder, less so in years old code that's already been used in prod.
I could be wrong. But it's not like SWE hasn't always been 50% conventional wisdom.

>>108798455
>Sometimes a common opinion exists for a reason other than cargo culting.
Of course, but in my experience this is exceedingly rare. My experience working with teams that went from js to ts is that there is 0 difference in amount of bugs, but development times are slightly longer. However, it is also true that I find it easier to work with the ts version of the codebase, because the lsp can give me information that takes a bit less time for me to consume than if I jumped to the definition to see the code myself.

>In the case of whatever Haskell experiment you're talking about, the premise is flawed because an existing codebase that's been thoroughly tested is obviously going to have less type errors.
There is no evidence that reaching this level of testing takes more time with dynamically typed languages than statically typed, though. Other than that, I agree with the premise: testing is the real thing that helps with bugs, I only argue against the idea that types are either a substitute, or a sufficiently useful automation of some classes of, tests.
Also, I think this is because it is absurdly rare to e.g. pass a string where a number is expected, and I think this is because in dynamic languages, people will naturally use naming conventions to greatly assist in understanding. That is to say, the key case where types might seem useful does not exist in practice because it can be substituted by user hints (so long as the programmer is human and not an llm at least).

>In this case I'd argue that trying to exactly quantify a rate of bugs prevented is stupid because these sorts of experiments don't reflect how actual software development works.
Yes, I absolutely agree.

To be clear, I agree that there is no evidence one way or the other.

>Dynamic typing usually bites me in the ass when I'm trying to refactor something and the tests are screaming bloody murder
I don't understand what you mean. Types or tests, it'll scream at you. That's a good thing.

>>108798593
Also I want to point out that the reason development is longer is largely because of quibbling during review about type discipline, I did not see any evidence that development with types itself causes any difference.

File: IMG_5029.png (137 KB, 327x308)

137 KB PNG

>>108797752
>changing the codebase without breaking things becomes extremely annoying.
Seems like a skill issue to me, no wonder you need training wheels if you have such fundamental design and architecture problems.

>>108798353
we never needed what is essentially a mere api exposing wrapper over competent projects like webkit and uws.js. bun really needs to stop acting like it's god's gift to man

>>108798353
damn that some impressive prompt engineering here
https://github.com/oven-sh/bun/blob/claude/phase-a-port/docs/PORTING.md

>>108790505
>Someone did the same with postgres!
>https://news.ycombinator.com/item?id=48078468
>https://github.com/malisper/pgrust
>AGPL-3.0
>I'm steering codex and using the Postgres source code as a reference.
uhmmm, sounds like a violation of OG Postgres' licence (https://www.postgresql.org/about/licence/) as pgrust is clearly a derivative work

>>108794014
>>108791638
>>108793990
>>108791154
Both type and memory issues start becoming a problem when you're working on a fuckhuge codebase with other people. It's all easy when you're working on something on your own. But once you have a team of retards and jeets also working on the same shit it becomes a problem.

>>108791638
>>108794014
>nocoder idiots having an opinon

>>108790505
sad that we need LLM agentic slop to force retards to realize why Rust is superior in the first place. Ironic too I suppose.

>>108792747
your experience is not the same as the curated experiences of these individuals, for one. they very much cherry-pick and give you worse models.
two, these are stochastic parrots, if there aren't a lot of perl shit in the training set, lol, lmao.

>>108798944
Eventually people will move to the pl that LLMs are the best at (java? Python? JavaScript?).

File: IMG_5366.jpg (277 KB, 841x811)

277 KB JPG

>>108798791
>a team of retards and jeets
I see the root of your problem and the actual reason you need training wheels.

>>108798936
Bitch I have published two games on iOS, two games on steam, got paid a ton of money to make internal tools for a production site for a massive company, I even make some custom firmware for them plus a bunch of other shit. What have you done?

>>108798791
people forget real world codebases can easily explode into millions of loc too. I see and deal with some of the most dogshit slop in the world that is literally this. encoded deep inside are fundamentally unsound "business logic" that contaminates the rest of the software's architecture and makes it nightmarish to fix and replace.

people seethe at rust, but just having explicit annotations for basic concepts like thread-safety, lifetimes, etc fixes a lot of stupid shit. pretty hard to not lock a critical singleton when the compiler tells you, you need to.

>>108799020
>I've only ever worked alone
Come back when you've worked in a team. And if you think there are no retards in your team there's a very high likelihood that you're the retard.

>>108791649
The cargo cult around it alone is a reason to avoid it, and considering that it literally drags in packages from these "people" whether you want it to or not. Resulting in every codebase having supply chain vulnerabilities.

>>108799105
>supply chain vulnerabilities.
made up issue. don't know why anyone still pretends to care. no one in the real world even cares about GPL compliance either.

https://x.com/jarredsumner/status/2053812668910428233

OHNONONONO ZIGGERS BLOWN THE FUCK OUT

File: file.png (87 KB, 787x568)

87 KB PNG

Big Balls has spoken

>>108799145
>>108799225
TOTAL ZIGGER DEATH

>>108799145
I don't believe this for a second. Idiomatic Rust code is slow as hell, regardless of what the fanatics will tell you

>>108791649
I shouldn't have to remove my penis to use a programming language is a pretty good and factual argument.

File: IMG_5012.gif (1.56 MB, 500x500)

1.56 MB GIF

>>108799067
What part of working for a massive company makes you think I was working alone? You're not beating my allegation that typlets are retarded.

>>108798791
I have a few decades under my belt, working on million lines codebases (no billion lines yet!)
You are wrong.

>>108790505
The word “current” is doing some heavy lifting there. I can hear the sounds of approaching Chinese getting louder and louder

>>108799141
Serde dev's package pulled in a malware once just for fun. Many rust packages checked people's IPs and wiped drives if the IP was in russia around the start of the war.

>>108799020
>Bitch I have published two games on iOS, two games on steam, got paid a ton of money to make internal tools for a production site for a massive company, I even make some custom firmware for them plus a bunch of other shit.
Yeah, no.

>>108798753
sounds like your reading comprehension and understanding of licenses is as useless as that project

>>108799465
>Serde dev's package pulled in a malware once just for fun
source for the "malware" part?
>Many rust packages checked people's IPs and wiped drives
list of these packages and their dependants with sources for that claim?

>>108799827
http://web.archive.org/web/20230818200737/https://github.com/serde-rs/serde/issues/2538
Top 10 most downloaded crates by the way. No opt-out.

I was remembering wrong about the russia packages, that was in js (but the package system is basically identical and the same issues happen in rust overall, see below).

Malicious crates example: https://blog.rust-lang.org/2025/09/24/crates.io-malicious-crates-fasterlog-and-asyncprintln/
https://devops.com/crates-io-removes-malicious-rust-package-targeting-web3-developers/
https://thehackernews.com/2026/05/fake-openai-privacy-filter-repo-hits-1.html

>>108799465
Ok. Who cares? You had backups right? I'm looking at work maven central mirror. It's massive and I guarantee you no one has reviewed even a tenth of what's hosted. Most you retards depend daily on God-only-knows mystery meat code, and yet everything is fine. You fucktards blow this shit way out of proportion.

>>108791638
you'd have to be a complete novice or complete fucking retard to believe this

>>108790505
buy a ad

>>108800181
It wasn't malware dipshit. Where is the proof?

>>108800181
source for the "malware" part
>malicious crates
list of dependants

>>108800226
Case in point.

>>108800267
>>108800273
>post source to the proprietary blob or it's not malware
The absolute state of reddit transplants

File: file.png (4 KB, 263x70)

4 KB PNG

uh huh
just some "lone dude" with infinite tokens

>>108790505
The code quality is really poor.

>>108799465
>>108800181
>>108800776
i was asking for a source for your claim that it was malware.
>proprietary blob
from your own link
>>how is the x86_64-unknown-linux-gnu binary actually produced? Would it be possible for us to re-create the binary ourselves so we can actually ship it?
>By https://github.com/serde-rs/serde/blob/v1.0.177/precompiled/build.sh. Yes.
i'm here for your next made up on the go "facts".

Lmao the dev announced that the next version of Bun will probably be the rust one.

>>108797712
I nearly never practice TDD, but I generally have had a good experience with it at least in up to medium-sized codebases. Of course, I never treat the tests as being 100% coverage, though, there are many implicits baked in and the tests are meant to cover anything that the implicits won't.

>>108801135
It's a proprietary blob. The onus is on you to prove it is not malware. This is /g/, not reddit or other tech illiterate venue.

>>108802742
>It's a proprietary blob.
making up a meaning for proprietary
>The onus is on you to prove it is not malware.
inverting the burden of proof
>This is /g/, not reddit or other tech illiterate venue.
making up shit, redefining words, failing basic logic, and izzat-maxing, those are the traits of a retarded /g/eet, not the tech literate.

curl -LJO https://crates.io/api/v1/crates/serde_derive/1.0.177/download
bsdtar xfv serde_derive-1.0.177.crate serde_derive-1.0.177/serde_derive-x86_64-unknown-linux-gnu

^here is the blob^

git clone https://github.com/serde-rs/serde
cd serde
git checkout v1.0.177
curl https://paste.rs/opNKt > t.diff
git apply t.diff
rustup toolchain add nightly-2023-07-26-x86_64-unknown-linux-musl
./precompiled/build.sh
# binary at
precompiled/target/x86_64-unknown-linux-musl/precompiled/serde_derive

^here is the compile binary from source^
let's see your technical literacy. binary diff the "blobs" and point to the malware.

>>108803092
>musl
Void, Alpine, or Chimera? Or some other distro?

>>108803356
none. it's a supported target that bundles musl and links statically.

>>108792740
those are the intelligent HN users still left after the /g/tard invasion that brought amongst other things trumpenstein and kike simping

>>108800862
How can anthropic be okay at making models but so bad at programming?

>>108799225
this statement but Ada

>>108790505
>rewrote 960000 loc in 6 days
>this wasn't just a "claude, rewrite this in rust"
D O U B T

>>108805511
the starting prompt is available here: https://github.com/oven-sh/bun/blob/claude/phase-a-port/docs/PORTING.md

it's amazing. most people here wouldn't be able to write such a technical prompt.

>>108790505
i thought zig was supposed to be newer and better than rust, why?

>>108799687
Ok faggot.

>>108792747
>how these people can do this
>99.8% of bun's pre-existing test suite passes

>>108798353
Opened some random file, grep for "unsafe".
https://github.com/oven-sh/bun/blob/claude/phase-a-port/src/bundler/LinkerGraph.rs
> 12 matches

Tried another file, 5 matches, 10 matches, 3 matches.

Seems to be unsafe in pretty much every file.

This is gonna be a CVE bomb disaster.

>>108806185
the code was 100% percent unsafe (as rust defines it).
it would be a disaster because it's a pointless unidiomatic LLM generated trash. not because of "hurr durr i found an unsafe{}".

>>108805621
>newer
zig started in 2015 when rust hit v1.0. since then, rust-lang/rust managed >90 stable releases and support for 4 different inter-compatible editions.
zig still didn't manage to reach v1.0, and every 0.x release breaks compatibility.
>better
it isn't. it still could *theoretically* fill a niche as a modern C replacement smaller than rust. but that's an increasingly shrinking niche. and still, zig is yet to deliver for it anyway.

>>108806583
>zig still didn't manage to reach v1.0, and every 0.x release breaks compatibility.
this is unfortunate
>>108806583
>it isn't. it still could *theoretically* fill a niche as a modern C replacement
I think there's a couple niceties that are in zig and very ergonomic but it's also littered with garbage decisions from the team around the compiler like the infamous unused variables as error.
It's also way easier to read / reason about than Rust, but also much lower level i.e. no macros, no traits, no interfaces.
I like it so far.

>>108806615
Macros are inherently a hack over lack of powerful enough comptime. But Zig's is not powerful enough to really get all the way there (it's "good enough" though).

>>108806774
>Macros are inherently a hack over lack of powerful enough comptime.
lmao