HN user

pseudony

350 karma
Posts1
Comments110
View on HN

run by genuinely insane people who think type and memory safety are paramount societal issues

So. Rust evangelists ? :)

But yes, it is wild that people can honestly quote such drivel as evidence of the language and its philosophy being superior.

Each time I try to evaluate Rust, I do so on its own merits. Going online I am rapidly convinced that I don’t want to be in the same room as a large chunk of its userbase. Statements start to sound a bit like that one time I was dragged into a pentecostal meeting.

Sure thing :)

Just my opinion. It really depends. For systems- kind of software (low-level, DBs, file systems (also user-space)) no, I wouldn’t - if you manage memory with arenas and/or can plug in an allocator to tell you if you leaked memory (provided the codepath is triggered), I mostly get what I want with less mental overhead. Also, I very often want to interface with C libraries.

For games, again, I wouldn’t. I again strongly suspect I would and could organize my use of memory better.

I suspect Rust is best when you don’t want to interface with C code (except through bindings others wrote) and you’re maybe more doing applications development where C++ has also stood strong. I completely see how, theoretically, Rust can make a great language for an office suite, browser and so on.

That’s actually also when I tried Rust for a personal project. I wrote a desktop application and while I spoke to C code, I only did so through bindings others had written.

It was/is fine :) I still got a segfault bug though hehe.

Basically I liked Ocaml so I have huge appreciation for all that Rust tries to bring into the mainstream on that front. I am just not thinking that the borrow-checker makes it well placed to interop with C. It becomes much better for relatively isolated applications work.

- types rarely catch the interesting errors

- any GC'ed language can manage memory for you if you want

- My first rust project (a gui app in GTK) managed to segfault just fine in spite of Rust (no unsafe blocks on my part, not deliberately trying to break anything).

- I think the state of computer security has moved on still, we now rely on LLMs armed with various tools to pick apart and try to break our code AND to generate our code -- it is not at all obvious to me that banging your head against the borrow checker is a worthwhile tradeoff in this new world.

I program C for my day-job.

I see Rust encroaching in proposed transitions. It may even happen. That said, it is a poor match for it compared to something like Zig (or Odin). It's hard to make the new Rust code use existing allocator abstractions (so now you have two systems doling out memory, how do you reliably free composite objects with memory from both? How do they share?) and you increasingly have to either abandon any actual benefits of the borrow-checker, or invest increasingly heavily into sufficiently fat bindings to wrap your existing C/C++ in a way where the borrow-checker can assist you. That's before we consider the complexity of the language - I'd doubt a seasoned C programmer has much trouble deciphering Zig or Odin FFI bindings, but in the case of Rust? Yes, there is real friction.

Also if you really value predictable- and higher performance, being in more in control of memory allocations and cleanup is preferable. This is the direction both Zig and Odin cater to.

If you asked me what solves the most issues without adding too many new liabilities, I'd say Zig (or Odin). It would simply be much, much easier to transition a C codebase to either, and either would bring a much improved stdlib with pluggable allocators capable of leak-detection etc.

Look up a few comments, I do systems programming. I am aware, you are barking up the wrong tree, friend.

That said. You asked about C, which I use for my job. Most every large C code base end up abandoning the stdlib (such as it is) and inventing their own. Since they do, we aren’t as hurt by abandoning it as you would be in e.g. Rust - the rust stdlib is useful, the C stdlib is.. not great.

Once you abandon the stdlib, a likely first stop is writing your own routines for allocating and freeing memory. There are different approaches here, from glib’s or sqlite’s alloc and free routines to people writing an allocator abstraction (basically a struct with a vtable for allocating/realloc/free) and when you build your own “stdlib” around this abstraction, you are fine.

As for why you may want arenas vs other allocation strategies, that again deals with how often you are comfortable going across the user-space/kernel boundary and how clever you can be with your allocations or how much internal fragmentation you can accept.

As with all other stuff, it depends. But arenas are often great when you can assert that a series of objects share the same lifetime (death time, rather). In these cases, your amortize the syscall cost, have nearly no additional work to manage the memory (contrast to e.g. the complexity of jemalloc) and can free a series of objects in constant time.

Games ? Many have talked about it, but many also make their games work inside of Unity and so on, so, depends on the project.

My angle is systems programming, and there, it absolutely matter. If you are performance sensitive, then you try to avoid crossing the user-space -> kernel boundary more than you have to.

Eg, ask for lots of memory, manage with arenas.

Interestingly Odin and Zig both lean into this heavily. Rust went a different route but has tried later to bolt on pluggable allocators.

Having fun with this.

Never bought into rust (have studied, have a (mostly AI-generated app in rust).

Wrote some Zig but Odin is even less overhead for me. I first loved Zigs built-in build system but having tried to wrap/use C libraries from both, I must say I prefer Odin. Wrapping some sqlite 3 API’s for my first little Odin program - just because I need so little of the API that it seems easier this way - and speaking to C from Odin is a pleasure.

That is, imho, where Rust fails the most - the second part is the C++’ish approach to memory management (RAII) - that’s not how systems programming or games (I’m told) tend to work.

To each their own. I had some fun with Rust too, but for me, Odin seems the most appealing :)

Similarly, why should I be bothered reading this kind of comment in each and every discussion thread?

What does it contribute? I can read and discern this for myself, I can then stop reading or decide I don’t care.

Seriously, at some point all you “ai writing sleuths” should just get your own discussion thread together. It’s been months of this , we get it already.

(Not directly just at you, but anyone who feels the need to drop these comments in every thread)

Well India has a diverse set of languages spread across its regions. As I understand it, the degree to which English thrives there is largely because choosing any other administrative language would be seen as oppressive to the other languages. Again, only stuff I picked up from the various Indian colleagues I have had.

Point being; I don’t think that is any different really from Europe. If they can manage, so can we.

You are being very hostile and cherry-picking results- disregarding and denigrating those that don’t fit your narrative.

Wrt Linus - who knows? It is irrelevant; he is largely irrelevant. If he got ran over by a bus, the collective community (of whom quite a few are outside the US) will carry on.

As a third party I would rather be happy about the way Chinese labs are acting in the here and now while US labs first masquerade as a public good, then turn around, bail on all promises of open AI, turn into a corporation and attempt to own the world while its runner-up is trying to scaremonger people into buying their product.

I know most Americans are fed a steady diet of “evil China” and China MAY have issues. But on the AI front they are heaps better. Even if everything got closed tomorrow, we have a plethora of good models we can inspect and tweak while from the US labs we have… a single old 120b model ?

And with the way the US is treating its allies, maybe a bunch of us are quite content with a more even match rather than US hegemony.

GLM 5.2 Is Out 1 month ago

Course not :)

I use pi (pi.dev).

I suspect some of the issue id that some harnesses are over-optimized for particular models and their preferences (tool calling, instructions to soften their deficiencies etc).

Pi is much more minimalist - probably a fairer point of comparison.

A different suspicion of mine is that some people over-specialize in a given model - or maybe become lazy with their prompts or suffer from skill issues.

Fwiw - I generally maintain a specs/ folder as I code.

I never use “plan” mode - I just tell the LLM to make no code changes, but discuss design with me.

At some point I am happy (I typically ask it to summarize and write the actual spec), I review; correct misunderstandings, ask for follow-up questions, we incorporate the additional details into the spec and move on.

I often have TODO’s/tasks in those specs too and I regularly update progress on them. It also happens that I ask the LLM to review my code (actual) against the spec and search for differences- we then resolve them. Sometimes by modifying the code; sometimes by modifying the spec.

For starters, I write an overview spec - nail down the big concepts and architectural choices at a high level. Moderately complicated facets of the application get their own spec - we write these as and when it gets relevant.

I think it helps the model a lot because I can refer to specs I feel relevant in drafting new specs or when solving tasks. And LLMs are generally better at proactively consulting these specs when getting an overview of the application and its design ahead of implementation.

GLM 5.2 Is Out 1 month ago

You seem to forget that there is a rather large world outside of the US - and we very much would be better off with non-gated, open weights models.

GLM 5.2 Is Out 1 month ago

And what do you base this on ?

How does one objectively quantify how it stacks upnto another model ?

Or even, what is your subjective evaluation based on ?

I really wonder - because I have just finished a fully vibe-coded gtk/rust/lua application with me basically writing 7% of the code (all in one module) and GLM 5.1 writing the rest. We haven’t had regressions, confusion or anything else. And I am pretty damned sure I couldn’t manage this one year ago with claude code and Sonnet.

Congratulations :)

As a Dane, I would say yes. Especially among boomers there was always a genuine appreciation of the US and its role as guardian of a rules-based international order and western civilization more generally.

I think that sentiment has gone, even as younger generations have increasingly incorporated English words, music, TV and more into their own, but you seldom hear the same genuine trust in the US as a force for good.

Yes, it is all a conspiracy.

Or. Have you considered that the erstwhile closest military ally of the US increasingly diversifying AWAY from US programs actually is pretty noteworthy. You have had canadians boycotting US products, cancel trips to the US, their PM encouraging elbows up attitude and delivering a pretty noteworthy speech in Davos about charting a course for middle powers and you think it’s business as usual?

Magnifica Humanitas 2 months ago

Wrong - I am very far from a catholic, but this just doesn’t reflect history.

They did a lot to make the middle ages more tolerable. After that, maybe they overstayed their welcome.

Sure — we can play that game. Worked for a state org in an EU country too.

I disagree, I note that multiple countries have digital ministries drafting plans to drop Microsoft products or to begin a wholesale migration due to sovereignty and security.

Once something becomes policy at the highest levels, the individual orgs will have to follow, even if slowly.

I really think you are grossly misreading the last 12 months or so. There is a big difference between a municipality migration as a cost-saving move and the very state saying declaring a national security threat from foreign-based vendors.

I have built a relatively complete process supervisor in Go - cross-platform, http management API, separate actor-like goroutines for each process and the main supervisor. All using Minimax m2.1 on open code.

Sure, it needs steering, but I have actually preferred it to claude which is much too eager