8 ms·

Every project and programmer shouldn't feel they have to justify their choice not to use Rust (or Zig), who seem to be strangely and disproportionately pushed o

• alexpadula 10mo ago
  I get asked this all the time regarding TidesDB. Why didn’t you choose Rust? Well. Yeah this super common. Great comment.
• misnome 10mo ago
  > strangely and disproportionately pushed on Hacker News There is literally nothing strange or disproportionate. It's incredibly obvious that new languages, that were designed by people who found older languages lacking, are of interest to groups of people interested in new applications of technology and who want to use their new languages. > then those from outside the project shouldn't really have any say on it. It's their project. People outside the project are allowed to say whatever the hell they want, the project doesn't have to listen.
  • shevy-java 10mo ago
    I am pretty certain Rust is pushed more than other languages. Whether warranted or not is another topic, but I think the OP has a point here.
  • whatamidoingyo 10mo ago
    "having a say on something", in OP's context, means authority and influence over decisions... People can say whatever they want, yes, but not everyone can "have a say on something".
  • hu3 10mo ago
    I understand "shouldn't really have any say on it" as shouldn't expect to infuence the project. Not that they are not allowed to say anything. Otherwise they would have written something along the lines of "shouldn't say anything about it".
  • lelanthran 10mo ago
    > People outside the project are allowed to say whatever the hell they want, And? GP didn't say that they shouldn't.
  • coliveira 10mo ago
    > People outside the project are allowed to say whatever the hell they want What these people do is a disservice to the general open source community, by spreading misinformation and general FUD about critical software that uses C and C++.
  • arghwhat 10mo ago
    > People outside the project are allowed to say whatever the hell they want, the project doesn't have to listen. Within reason - don't be a dick and all that. :)
  • donkeybeer 10mo ago
    I think it's more than just the normal amount for advocacy of a new language. Rust isn't the only "newer" language. I don't feel this kind of mentally strung pushing of say Kotlin or Scala or Go or, etc from their fans.
    • bigfishrunning 10mo ago
      I think this is because of the gap in its target market -- Rust is firmly positioned to replace C and C++, which have a long history of safety issues. Kotlin is positioned to replace java, and besides a few quality-of-life improvements, it changes some syntax but very few semantics, so the gap is much smaller. Go was originally pitched as a C or C++ replacement, and it's very nice for deeply parallel programs like web services, but its big runtime and its GC rule it out for a lot of (especially very low level or latency-critical) uses -- you don't see Go ported to microcontrollers for instance. I can't speak for Scala, because i don't have experience writing software in it. To summarize, Rust provides a lot of compile-time discipline that C and C++ are lacking, and many people are tired of maintaining code that was developed without that discipline. Rust makes it harder to write low-effort software. As a programmer that picks up a new language every 2-3 years (and one that is privileged to have an employer that tolerates this) Rust is really a breath of fresh air; not because it's easier, but because it codifies and enforces some good habits in ways that other languages don't.
      • tonyplee 10mo ago
        Love to see an AI agent to auto transpile C (sqlite, apache, nginx, mariadb, etc) into rust and run all the regression associated tests and perf benchmarks and produce report on the porting processes and perf delta.
        • nindalf 10mo ago
          Sqlite's test suite is closed source, so no one other than the Sqlite authors can attempt that. That said, you may be interested in this attempt by Turso to rewrite Sqlite in Rust (https://turso.tech/blog/we-will-rewrite-sqlite-and-we-are-going-all-in https://turso.tech/blog/we-will-rewrite-sqlite-and-we-are-go...). They're not using AI, but they are using some novel ways to test their code.
  • ashtonshears 10mo ago
    Rust is pushed on the internet
    • guywithahat 10mo ago
      I definitely wouldn't say internet, I think it's popular on HN and a few other online forums. There are a lot of X/twitter circles which make are critical of rust, as well as other sites. In my mind at least there's a decent risk Rust is going to end up like the next Haskell, its benefits other than safety are not that clear and many of those features can and have been replicated in other languages.
      • josephg 10mo ago
        Many of its biggest benefits of rust come directly from other languages - including Haskell. Like, rust’s Option is identical to Haskell’s Maybe type. Traits are similar to type classes in Haskell, or interfaces in Go. In my mind, the thing that makes rust and zig nice are that they put modern language features in a systems language. Non-nullable pointers and match expressions in a language that runs as fast as C? Yes please. I love rust, but I personally doubt rust will ever be anywhere near as popular as Python, go, JavaScript and C#. It’s just so complex and difficult to learn. But its niche is pretty clear to me: I see it as a tool for writing beautiful, correct, memory safe, performant systems code. I used to love C. But between zig, rust and Odin, I can’t see myself ever using it again. C is just so much less productive and less pleasant to use than more modern languages.
  • metalliqaz 10mo ago
    And here I was just reading in another thread that HN was so much less toxic than other places...
    • alexpadula 10mo ago
      Where do you see people having toxic debates?
  • locknitpicker 10mo ago
    > There is literally nothing strange or disproportionate. It's incredibly obvious that new languages, that were designed by people who found older languages lacking, are of interest to groups of people interested in new applications of technology and who want to use their new languages. This is a disingenuous opinion. The level of militance involved in this propaganda push goes way beyond mere interest. Just look at people who actually enjoy Java, C++, Python, etc. These are the most popular languages that mankind ever developed,and countless people built very successful careers around them. Yet, you don't see even a fraction of the fanboys you see constantly pushing these experimental languages.
• alansaber 10mo ago
  We (especially management) are trained to always want shiny new thing. Also it's an easy line of dialogue.
  • brabel 10mo ago
    Funny how managers get blamed for both wanting new things and for not wanting new things. In the Java 6 days every dev wanted to upgrade to 7 and later 8… but the meme was that their manager wouldn’t ever let them.
• pie_flavor 10mo ago
  It should not be strange that a tool which is better in every way and makes your code less buggy by default has its praises sung by most of the people who use it. It would be odd to go around saying 'electric drills are strangely and disproportionately pushed at Home Depot over the good old hand auger', and even if I don't work at your contracting company I'd be slightly unnerved about you working on my house.
  • agentultra 10mo ago
    I’ve heard this analogy used to justify firing developers for not using GenAI: a cabinet maker who doesn’t use power tools shouldn’t be working as a cabinet maker. If only programming languages (or GenAI) were tools like hammers and augers and drills. Even then the cabinets you see that come out of shops that only use hand tools are some of the most sturdy, beautiful, and long lasting pieces that become the antiques. They use fewer cuts, less glue, avoid using nails and screws where a proper joint will do, etc.
    • pie_flavor 10mo ago
      Less glue and avoidance of nails and screws doesn't make it sturdier. Fastening things strongly makes your furniture sturdier than not doing so. Antiques suck as often as they don't, and moreover you are only seeing the ones that survived without a base rate to compare it to; they succeeded in spite of power tools, but power tools would have made the same object better. Comparing it to AI makes no sense. Invoking it is supposed to bring to mind the fact that it's worse in well-known ways, but then the statement 'better in every way' no longer applies. Using Rust passively improves the engineering quality compared to using anything else, unlike AI which sacrifices engineering quality for iteration speed.
      • quesera 10mo ago
        > Less glue and avoidance of nails and screws doesn't make it sturdier. Fastening things strongly makes your furniture sturdier than not doing so. No disrespect intended, but your criticism of the analogy reveals that you are speaking from assumptions, but not knowledge, about furniture construction. In fact, less glue, and fewer fasteners (i.e. design that leverages the strength of the materials), is exactly how quality furniture is made more sturdy.
• hmry 10mo ago
  Yeah, results are what matters. SQLite's process seems to produce solid bug-free results. My only complaint would be that there's many SQL features I want to use which aren't supported. Surely some part of that is deliberately restricted scope, but some might also be dev velocity issues. DuckDB (C++) can be used like an SQLite with more SQL features, but it's also a lot buggier. Segfaults from your database are not what you want. So still hoping for some alternative to come along (or maybe I'll need to write it myself)
  • chasil 10mo ago
    What isn't supported? After window functions were added, what else is missing?
    • hmry 10mo ago
      The ones that come to mind immediately are more ALTER statements (especially adding non-virtual columns), DATE, TIME, and TIMESTAMP types and their associated functions, and ARRAY types. Although I don't wish to disparage SQLite, they do support a lot of features. Just that I constantly run into the ones they don't, with my use cases. And beyond standard SQL, stuff like hashmap/bloom filter/vector indices, nearest neighbor search, etc...
• CuriouslyC 10mo ago
  OOP was always debatable, but with the rise of AI agents I'd go so far as to say it's objectively bad now. AI is much better at reasoning about pure function grammars than imperative classes with inheritance; abstractions that aren't airtight are bug factories.
• baq 10mo ago
  I mostly agree, but the OOP is most definitely not in vogue on HN for the past decade at least, arguably far longer than that (think Rust pre-1.0, Go 1.0 times).
  • Supernaut 10mo ago
    Absolutely. Our thought leaders have been pushing functional programming for a long time now.
    • ruszki 10mo ago
      Is it possible to have an OOP language which is also functional? Or is it impossible without imperative paradigms?
      • bigfishrunning 10mo ago
        There's some muddiness in the terminology here -- OOP is really a design style, and "OOP languages" are generally imperative languages that have sematics that encourage OOP design. It is very possible, even encouraged, to represent state as "Objects" in many functional languages; it's just not really enforced by the language itself. A good example of this are the object systems in Scheme and Common Lisp (which are less strictly Functional (note the capital F in that word) then something like Haskell).
        • ruszki 10mo ago
          I asked mainly because of the terminology. I read the primer of how to code OOP in plain C about a decade ago, so I knew that the paradigm definitely can be applied to “non OOP languages”, but I wasn’t sure whether the term “functional programming” allows this or not for some obscure academic reasons. How I coded when I encountered Haskell the first time, I would say it’s definitely possible, but I think, there are some features in Haskell which can be used to break pure functional programming, and if those are not considered FP, then who knows. But I used Haskell the last time a few years ago, so my memory is definitely not clear.
• runjake 10mo ago
  Context: Along with the never ending pressure to migrate a project to new shiny, there is a lot of momentum against C and other memory-unsafe languages. The US government recently called on everyone to stop using them and move to memory-safe languages. Regardless, there are practices and tools that significantly help produce safe C code and I feel like more effort should be spent teaching C programmers those. Edit: Typos and to make the point that I'm not necessarily defending C, just acknowledging it's place. I haven't written a significant amount of C in over 2 decades, probably, aside from microcontroller C.
  • titzer 10mo ago
    C was my first language, more than thirty years ago. I've heard (and probably myself made) the same arguments over and over and over. But those arguments are lame and wrong. C cannot be made safe (at scale). It's like asbestos. In fact, C is a hazardous material in exactly the same way as asbestos. Naturally occurring, but over industrialized and deployed far too widely before its dangers were known. Still has its uses but it will fuck you up if you do not use industrial-grade PPE. Stop using C if you can. Stop arguing other people should use it. There have always been alternatives and the opportunity cost of ecosystems continuing to invest in C has massive externalized costs for the entire industry and society as a whole.
    • coliveira 10mo ago
      Stop spreading FUD.
    • Koshkin 10mo ago
      > in exactly the same way C is not known to the state of California to cause cancer.
      • rascul 10mo ago
        Not yet
    • toxik 10mo ago
      Asbestos causes mesothelioma and gruesome death. C does not. Be serious.
• antirez 10mo ago
  It is also worth to note that the Rust design, in its theory, and the recent bug in the Linux kernel Rust code (the message passing abstraction used by Android), makes clear that: 1. With Rust, you may lower the exposure, but the same classes of bug still remain. And of course, all the other non memory related bugs. 2. With C you may, if you wish, develop a big sensibility to race conditions, and stay alert. In general it is possible that C programmers have their "bugs antenna" a bit more developed than other folks. 3. With Rust, to decrease the "unsafe" sections amount, you need often to build abstractions that may be a bit unnatural. 4. Rust may create a false sense of security, and in the unsafe sections the programmer sometimes, when reviewing the code, is falsely convinced by the mandatory SAFETY comment. Like in the Linux Kernel bug, where such comment was hallucinated by a human that sometimes (not sure in this specific case, it's just an example) may be less used to do the "race spotting" process that C learns you to do. 5. With Rust, in case of a bug, the fix could no longer be the one-liner usually you see in C fixes, and can make the exposure time window larger. Sometimes fixing things in Rust means refactoring in non trivial ways. 6. With C, if there was the same amount of effort in creating wrappers to make kernel programming safer at the cost of other things, the surface of attack could also be lowered in a significant way (see for instance Redis use of sds.c: how many direct strings / pointers manipulation we avoid? The same for other stuff of course). Basically things like sds.c let you put a big part of the unsafe business in a self contained library. So, is Rust an interesting language for certain features it has? Yes. Is Rust a silver bullet? No. So should Rust be "pushed" to others, hell no, and I suggest you to reply in the most firm way to people stressing you out to adopt Rust at all the costs.
  • tasn 10mo ago
    The recent bug in the Linux kernel Rust code, based on my understanding, was in unsafe code, and related to interop with C. So I wouldn't really classify it as a Rust bug. In fact, under normal circumstances (no interop), people rarely use unsafe in Rust, and the use is very isolated. I think the idea of developers developing a "bugs antenna" is good in theory, though in practice the kernel, Redis, and many other projects suffer from these classes of bugs consistently. Additionally, that's why people use linters and code formatters even though developers can develop a sensitivity to coding conventions (in fact, these tools used to be unpopular in C-land). Trusting humans develop sensibility is just not enough. Specifically, about the concurrency: Redis is (mostly) single-threaded, and I guess that's at least in part because of the difficulty of building safe, fast and highly-concurrent C applications (please correct me if I'm wrong). Can people write safer C (e.g. by using sds.c and the likes)? For sure! Though we've been writing C for 50+ years at this point, at some point "people can just do X" is no longer a valid argument. As while we could, in fact we don't.
• wat10000 10mo ago
  Every serious project should be able to justify its choice of tools. "Because I feel like it" is fine for hobby projects or open-source passion projects, but production-worthy software should have reasoning behind its choices. That reasoning can be something like "it's most effective for us because we know it better" but it should be a deliberate, measured choice. SQLite is an example of an extremely high quality software project. That encompasses not only the quality of the software itself, but the project management around it. That includes explaining various design choices, and this document explaining the choice of language is just one of many such explanations.
  • alexpadula 10mo ago
    Indeed, indeed.
• wy1981 10mo ago
  > Every project and programmer shouldn't feel they have to justify their choice not to use Rust Maybe writing about it was taken as an opportunity to clarify their own thinking about the topic?
• threethirtytwo 10mo ago
  Is there still pressure to use OOP? On Hacker News, at least, the trend seems to be moving in the opposite direction. There’s growing skepticism toward OOP, and that’s reflected in the popularity of languages like Rust and Zig, which are explicitly designed to push against traditional object-oriented patterns. That’s not to say OOP advocacy has disappeared from HN. It still exists, but it no longer feels dominant or ascendant. If anything, it feels like a legacy viewpoint maintained by a sizable but aging contingent rather than a direction the community is moving toward. Part of OOP’s staying power comes from what I’d call a cathartic trap. Procedural programming is intuitive and straightforward. OOP, by contrast, offers a new conceptual lens: objects, inheritance, polymorphism, and eventually design patterns. When someone internalizes this framework, there’s often a strong moment of “clicking” where complex software suddenly feels explainable and structured. That feeling of insight can be intoxicating. Design patterns, in particular, amplify this effect by making complexity feel principled and universally applicable. But this catharsis is easy to confuse with effectiveness. The emotional satisfaction of understanding a system is orthogonal to whether that system actually produces better outcomes. I’ve seen a similar dynamic in religion, where the Bible’s dense symbolism and internal coherence produce a powerful sense of revelation once everything seems to “fit” together. The feeling is real, but it doesn’t validate the underlying model. In practice, OOP often increases complexity and reduces modularity. This isn’t always obvious from inside the paradigm. It tends to become clear only after working seriously in other paradigms, where composition, data-oriented design, or functional approaches make the tradeoffs impossible to ignore.
  • f1shy 10mo ago
    In my circles, there is one part of OOP seen as positive: encapsulation. Everything else, specially inheritance and partly polymorphism are seen extremely negatively. The hype is over. BUT: I still hear more often as I would like, some manager stating “of course we will use C++, because is THE OOP language, and everybody knows OOP and UML are the only right way of doing software” this is an actual verbatim statement I had to listen 4 years ago.
    • threethirtytwo 10mo ago
• NuclearPM 10mo ago
  > a bit less in recent years, to use OOP. That’s an understatement.
• kristoff_it 10mo ago
  > Every project and programmer shouldn't feel they have to justify their choice not to use Rust (or Zig) You won't find easily Zig programmers that want you to use Zig at all costs, or that believe it's a moral imperative that you do. It's just antithetical to the whole concept of Zig. The worst that can happen is that Zig programmers want C projects to have a build.zig so they can cross-compile the project trivially, since that's usually not a thing C/C++ build scripts tend to offer. And even then, we have https://github.com/allyourcodebase/ https://github.com/allyourcodebase/ so that Zig users can get their build.zig scripts without annoying project maintainers.
• coffeemug 10mo ago
  Not always, but sometimes, new things are just better. One example is null-- a billion dollar mistake as Tony Hoare called it. A Maybe type with exhaustive pattern matching is so dramatically better, it can be worth switching just for that feature alone.
  • gf000 10mo ago
    This "new" thing could have grandkids now :D ML is not some new development, it just took this long to get some of its ideas mainstream.
• paulf38 10mo ago
  OOP is pretty much has-been. Value semantics is the hot thing now I'd say.
  • pjmlp 10mo ago
    That is why all major operating systems GUIs don't use it, yep.
• snvzz 10mo ago
  >justify their choice not to use Rust (or Zig) It's disingenuous to lump them together. It is the former that does the whole toxic, pushy advocacy routine.
• blank_state 10mo ago
  Rust programmers have this "holier than you" attitude that is so toxic. It's essentially wokeism for programming. No wonder it originates from San Francisco, from all places. The language itself features interesting ideas, many of them borrowed (pun intended) from Haskell, so not that new after all. But the community behavior proved consistently abysmal. A real put off.