15 ms·

Rewrite Everything in Rust

• mahyarm 11y ago
  How practical is rust for small processor IoT applications? Like the ESP8266 we saw recently? https://news.ycombinator.com/item?id=11148129 https://news.ycombinator.com/item?id=11148129 They often have horrible security, but are very small programs when you use them as wifi temperature sensors or similar. They are good targets for rewrites and greenfield applications. Right now it seems like ardunio C++ or some scripting language is the target.
  • pcwalton 11y ago
    Rust is a great choice in theory for anything with an LLVM target, but the libcore "bare metal"/"no standard library" ecosystem is pretty immature, and there are likely to be bugs (like the compiler generating binaries that are too large, etc). If you'd like, please try it out and file any issues you find :)
  • johnny22 11y ago
    I can't say how practical, but folks are working on it, as seen here: http://zinc.rs/ http://zinc.rs/
  • fabrice_d 11y ago
    unfortunately there's no LLVM backend for the xtensa cpu used by the ESP8266. There's a gcc backend though, so if someone has the time and skillset to port to LLVM, here's a way to become a hero ;)
  • doublec 11y ago
    There's a port of ATS programming language for the ESP8266. There's some slides on it here: http://www.slideshare.net/master_q/safer-iot-using-functional-language http://www.slideshare.net/master_q/safer-iot-using-functiona... ATS is a functional programming language that does not use a garbage collector and uses dependent and linear types to do safe system programming. It provides a similar level of safety to Rust with the ability to drop down to C: http://www.ats-lang.org/ http://www.ats-lang.org/
• stcredzero 11y ago
  If a given piece of software has been largely written using certain patterns or conventions, then it is often possible for a syntactic rewrite engine to be able to match those patterns, then output idiomatic code patterns in the target language. This may well be applicable to kernels and other constituents of an OS.
  • pcwalton 11y ago
    Isn't that just what a compiler is, where the target language is machine code?
    • TheCoreh 11y ago
      A compiler has more than syntax though, since it understands semantics and does a lot of checks. I think the parent comment refers to something a little more rudimentary, like a macro-based system to do a rough translation of code.
    • deleted 11y ago
      [deleted]
    • heywiseguy 11y ago
      yeah this is like a recipe for turning an N-pass compiler into an N+1 pass compiler
    • wspeirs 11y ago
      I realize something like glibc would be the LAST set of source code to run through a transpiler, but how hard do folks think it would be to make a C -> Rust transpiler? I'd think you'd go about it by making Rust a target backend for LLVM. This way you let LLVM deal with the all C stuff (macros, etc), and just focus on the internal representation to Rust conversion. In theory, you'd get C++ to Rust as well. Chances is successfully going from some not-so-obfuscated C code to equally not-so-obfuscated Rust code?
      • pcwalton 11y ago
        > how hard do folks think it would be to make a C -> Rust transpiler? Why do you want to do that? The only way to make it work short of doing years and years of static analysis research to automatically translate ad-hoc memory management disciplines into those of Rust (that I think will not succeed anyway) would be to compile to unsafe code. And if you compiled to unsafe Rust code, there would be no gain.
• dkhenry 11y ago
  I have actually started to do this to see for myself how much work it would be http://blog.dkhenry.com/2016/02/17/deciding-to-rewrite-getaddrinfo-in-rust/ http://blog.dkhenry.com/2016/02/17/deciding-to-rewrite-getad...
  • rtpg 11y ago
    Thanks for doing this... I think the way to tackle a rust glibc rewrite: Step 0 - write a code generator that just generates rust code that call the C versions of glibc symbols ( based off of the publicly exposed API in the library files). Get test suite to run Step 1 - Make that rust code generate a 100% drop-in replacement fro the C symbols (maybe this requires injecting version numbers) Step 2 - write the `getaddrinfo` replacement in Rust ??? Step 4 - have all of glibc ported EDIT: Does anyone know of any gotchas with linking that would cause this to happen? Seriously considering taking a day off to do step O.
    • JoshTriplett 11y ago
      For step 0, look at Rust's libc crate. For step 1, you'd need to carefully look at glibc's ABI, which is even more complicated than its API due to backward compatibility and symbol versioning.
      • dkhenry 11y ago
        Yeah ABI compatibility might be problematic, my currently plan is to LD_PRELOAD what I have to test it for speed. I have the feeling that rust could mock the ABI and serve as a general replacement, but first things first is it even fast enough to use at the lowest levels of the system.
        • steveklabnik 11y ago
          If it's not, please file bugs. It should be.
  • tayo42 11y ago
    This sounds interesting. I wouldn't even know where to start.
• geofft 11y ago
  It's certainly possible to incrementally rewrite an OS distribution in Rust, or even smaller projects like glibc. Anyone want to set up the infrastructure so it's easy to take a library or a .c file and start hacking, and see if you still get a working OS in the end? I suppose part of the problem is defining "working OS" -- I'm not sure I know of any great test suites that check to see that a GNU/Linux distribution continues to in GNUy/Linuxish ways, which is usually what you want for a large-scale rewrite project.
  • cls59 11y ago
    How about a re-write of coreutils in Rust? https://github.com/uutils/coreutils https://github.com/uutils/coreutils
  • Elv13 11y ago
    > or even smaller projects like glibc. Umm, "smaller" > incrementally rewrite It is GNU LibC, even if your rewrite is GPLv1337, the toolchain isn't "free enough" for them. You will be "stopped by verbal force" in the sake of preserving an inferior, but "free" core library.
• alexnewman 11y ago
  I wish
  • alexnewman 11y ago
    Why -4 downvote?
• panic 11y ago
  I think this misses the real problem. So many pieces of foundational software like glibc and OpenSSL are understaffed, underfunded, and plagued by terrible code. Go read glibc getaddrinfo: it's a mess! Rewriting the software in Rust would not solve these problems any more than rewriting it in C++ would. A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that nobody has time to fix. We need to have incentives for maintaining this foundational software.
  • pcwalton 11y ago
    > A rewrite would clean up the code, sure, but then you're left in the same situation, only with brand new bugs that nobody has time to fix. The entire point is that you're not in the same situation regarding memory safety problems/vulnerabilities.
    • rubiquity 11y ago
      I think what GP is saying that you'll have problems in logic or other typical programming problems and that it isn't a lack of language features/safety but rather time/money being thrown at these libraries I imagine the top two reasons unsafe memory access happen is: 1) other complicated logic seeped into the memory sensitive area or causes programmer fatigue 2) memory management is hard Rust helps with #2 but let's not kid ourselves, what percentage of a library like glibc would be spent in unsafe blocks? Drawing attention to an unsafe area can help though. As you can see, I'm running around in circles. Just like every discussion about this does. Until an avid Rust user puts their money where their mouth is, we're all just playing Armchair Programmer.
      • pcwalton 11y ago
        I don't understand the difference between #1 and #2, or why Rust helps with one and not the other. If memory safety is enforced, it's enforced. > Rust helps with #2 but let's not kid ourselves, what percentage of a library like glibc would be spent in unsafe blocks? string.h is not as interesting as, say, the DNS resolver. Nothing about the DNS resolver needs to be unsafe.
• sdegutis 11y ago
  Off topic, but it's surprisingly refreshing to see someone put "Christian" next to their name in the same place they put "Mozilla hacker." The vast majority of programmers either aren't religious or hide it so well that you couldn't possibly tell if they were. (Not that being overt about it is better, either.) I understand that it's generally best not to talk religion in the professional workplace, but a person's own blog is a more neutral place to bring it up, so it's nice to see that here. It's also refreshing to see that there are other adult converts to Christianity in the programming world, as opposed to from it, which seems to be the norm in general but particularly in this field.
  • solipsism 11y ago
    Do you find it refreshing because he's Christian? What I mean is, if instead it said "atheist" or "Muslim" would you also find it refreshing?
    • sdegutis 11y ago
      Being a Christian myself, yes, I do find it refreshing specifically because he's another Christian programmer. It's very rare that someone is both, let alone an adult convert to Christianity.
  • b34r 11y ago
• na85 11y ago
  Is there a "glibrust" or equivalent standard library for Rust, yet?
  • thinkpad20 11y ago
    Rust of course has a standard library[0] and it includes a libc, but (I might be wrong here) I think the libc portion is FFI into glibc or similar. I think the stuff written in rust is considerably more high-level, focusing more on data structures, concurrency, string manipulation, etc. [0]: https://doc.rust-lang.org/std/ https://doc.rust-lang.org/std/
    • deleted 11y ago
      [deleted]
    • steveklabnik 11y ago
      We use glibc by default but provide MUSL builds for some platforms as well.
    • na85 11y ago
      I guess what I'm asking is if the syscall wrappers are in rust or if rust just calls glibc wrappers.
  • CyberDildonics 11y ago
    rust relies heavily on libc as far as I know
    • steveklabnik 11y ago
      Some of the standard library does, but the core language does not. (libcore does not, and we've resisted putting libc specific things in core)
    • Manishearth 11y ago
      No, not heavily. libstd depends on it some (we allow both glibc and musl libcs). libcore (the baremetal library) and the language don't need libc at all.
• thinkpad20 11y ago
  I don't know much about glibc, but since you can call rust from C and vice versa, it seems like you could reimplement a few functions at a time, incrementally phasing out C code and replacing it with rust. Assuming, of course, that you agree with the author's thesis. This approach lets you reuse the same tests and do things like benchmarking etc to make sure the implementation is performant and compliant.
  • kibwen 11y ago
    This is exactly how Firefox is approaching it. Identify the most security-critical bits, wall them off into their own component, and rewrite it in Rust.
    • bjz_ 11y ago
      Yes! And the reverse has happened with Servo. Originally it was mainly a bag of C libraries with some layout code, then gradually they began swapping the pieces out for the Rust counterparts. This is how new software can be written - bootstrapping off the C infrastructure, then gradually transitioning more and more into Rust land.
• carussell 11y ago
  Do user studies. It's pretty much unheard of, but nearly every open source project would benefit far more from a week of watching potential contributors trying to get up to speed than it would from making sure the project roadmap is delivered a week sooner. That's my claim for projects in general, and what you're asking for re Rust is a little different, but the approach can applied there, too. Focus on everything from navigating the project website and other docs, to interactions with the tools that make up the "ecosystem", to programmer expectations that could shape the language (with the latter actually being the least important). Don't trust users to self-report. Don't overestimate your ability to make a combined diagnosis and prescription, and don't underestimate how much silent resignation is killing your adoption rate. Observe and work off real notes.
  • mattip 11y ago
    Has this been done for any project? I am interested in seeing the setup used, resulting reports, and changes instituted
  • charlieflowers 11y ago
    This is the most insightful comment in the discussion. It should have been obvious, but it wasn't until you posted it. First, design a sound language that solves problems other languages don't (done). Then, optimize for adoption ... because the world only benefits from that new language once adoption really takes off. Rust has done half the job really well. And a decent start on the second half -- mainly because the first half was done so well. But if the Rust team were to prioritze adoption the way the parent post espouses, they'd be changing their priorities significantly, and it's probably the most effective way to make sure Rust fulfills its potential.
    • steveklabnik 11y ago
      We have done a lot of things to prioritize adoption, though we could do better. We have done some almost-studies like this: we had a series of conference calls with companies using production Rust specifically to work on their pain points, for example.
• bitL 11y ago
  1: So a new generation, new rewrite of everything... Then hitting brand new problems (sometimes old ones avoided by previous designs) not foreseen by majority. A new language spawns with the coming of a new generation, addressing some of these problems. Rewrites everything. Hits another set of problems. Goto 1.
  • paulddraper 11y ago
    Iteration is not bad. Iteration without progress is bad. Which one do you think would happen?
    • bitL 11y ago
      I am suggesting that the problem is elsewhere - and more philosophical. I understand for many very young kids learning JavaScript was the only accessible way to do programming. Yet they are producing way worse stuff than previous generations unfortunately (remember Scandinavian demos in the 90s?), as their platform of choice is seriously limited. Now the article mentions horrible things in code developed over decades. I can guarantee you most of decade old code looks similar. And most likely decades old code in Rust will be similar. Here is a need for some simplifying meta-programming theory instead of slightly modified language constructs known since 60s. So what I see is iteration with some progress and some regress (wrt to empowering programmers and simplicity). It's good to have a new generation enthusiastic creating their own world, yet if they are as human as previous generation, most likely they would hit the same problems. Like a genetic algorithm, a slight mutation to current solution runs for a certain time and we see how the generation fares. But maybe we need completely different approach to get out of local optima technology seems to be right now. Quantum Rust? ;-)
      • paulddraper 11y ago
        "But maybe we need completely different approach to get out of local optima technology seems to be right now." So your problem is not that a Rust rewrite would be too much of a change. It's that it would be too little? ;) If there is any popular low-level language that is a "completely different approach", I'd say that language is Rust.
• latenightcoding 11y ago
  Not this crap again. C libraries are not pretty but they have been out there for decades, they have been reviewed and used in production. There is no silver bullet, just because you use Rust it doesn't mean your programs will be completely safe. A lot of these C libraries were written in more innocent times where a small bug would not affect as many people as it would today. We live in a C world and I don't see that changing any time soon.
  • pcwalton 11y ago
    > C libraries are not pretty but they have been out there for decades, they have been reviewed and used in production. The same was true of Fortran when C came around. I'm glad K&R didn't use this reasoning in 1978 to justify not rewriting things in their new language. > There is no silver bullet, just because you use Rust it doesn't mean your programs will be completely safe. Nobody is claiming that Rust eliminates all security vulnerabilities. > A lot of these C libraries were written in more innocent times where a small bug would not affect as many people as it would today. This isn't a positive!
  • Avshalom 11y ago
    >We live in a C world and I don't see that changing any time soon. Of course it won't because every time an out-of-bounds array access gives attackers free reign of a system and some one says "hey guys this whole C thing is clearly blatantly terrible" every one else says "Not this crap again. C libraries are not pretty but they have been out there for decades, they have been reviewed and used in production." As if the libraries have been utterly static for decades and aren't infact full of holes and bugs, which is exactly what brings on the call to rewrite things in Ada/Rust/SML/Lisp Then they always say "There is no silver bullet, just because you use Rust it doesn't mean your programs will be completely safe." As if there's no reason trying to improve things unless you can jump directly to perfect. they make excuses like "A lot of these C libraries were written in more innocent times where a small bug would not affect as many people as it would today." as if we still lived in those innocent times. And then they inevitably wave the call to action off by appealing to the status quo with some line like "We live in a C world and I don't see that changing any time soon." and so even though there's no reason we couldn't start re-writing things (especially in Unix an OS that constantly brags about being built from loosely coupled parts) in a better language we never get a critical mass together.
• cpeterso 11y ago
  So how soon will we see a new libc writen in Rust? Someone could fork a smaller libc like musl and incrementally rewrite functions in Rust.
• halayli 11y ago
  Then introduce a new set of bugs that will take years to iron out.
• _b 11y ago
  C++ is getting compile time checks for type, bounds, and lifetime safety, which steals nearly all of Rust's safety thunder. See Herb Sutter's talk at CppCon: http://herbsutter.com/2015/09/27/my-talk-at-cppcon/ http://herbsutter.com/2015/09/27/my-talk-at-cppcon/ For most applications, moving to modern C++ is going to be a better option than rewriting in Rust.
  • meowface 11y ago
    I love Rust, but I can't deny that this is a much more practical option for existing C++ projects.
  • dikaiosune 11y ago
    But the core guidelines are optional -- which means that you'll still have the entirety of C/C++ footgun hell to watch out for, and decades of outdated teaching and learning materials. And very large codebases which could not be easily ported to a compiler that enforced those guideines. I will be happy if Rust's main impact on history will have been to showcase how to get those safety features into a practical language, and by extension improvements to C++, but I still think that the steps C++ is taking seem a lot less safe than what Rust has achieved by completely ignoring backward compatibility with C++98. See, for example, the compiler-enforced concurrency safety that Rust provides. I haven't read the core guidelines recently or in depth, but IIRC that's not a stated goal of the project.
    • unscaled 11y ago
      Looking at the presentation it looks like you can borrow a non-const reference (in rust parlance) several times, so there's no concurrency guarantee. You would have to break compatibility with too much existing code to get the same level of strictness as Rust, so that's reasonable, but yeah, it's hard to imagine that C++ will be as safe as Rust. I'm glad these features are being pushed through though.
      • dikaiosune 11y ago
        Absolutely, I didn't mean to say that improving C++ is bad (we sure as hell need it, esp. given how much of the world runs on C++), and C++14 and 17 have many exciting things coming. I just didn't think it was fair to say that the new standard(s) "steals nearly all of Rust's safety thunder," when several core promises of Rust's safety model aren't possible in C++ if you maintain backwards compatibility.
• wangchow 11y ago
  Just gonna throw this out there: what if instead of working on creating the myriad of "better languages" we focus on actual mastery of simpler languages like C. And with that mastery: what about writing some machine-learning software that detects vulnerabilities as part of the build/release cycle. For instance: http://news.mit.edu/2016/faster-automatic-bug-repair-code-errors-0129 http://news.mit.edu/2016/faster-automatic-bug-repair-code-er... To detect vulnerabilities people need to be careful and follow best practices. If they can't do that well.. replace the people with software that's better and more efficient than the people. :)
  • dikaiosune 11y ago
    Why can't we do both? On the one hand, we obviously need better techniques to maintain and improve upon code bases in languages like C. They aren't going anywhere anytime soon. But why shouldn't we also pursue improvement to the programming language state of the art? And if we find improvements, why shouldn't we use them? I'd be very sad if 50 years from now C (or Rust, for that matter) is considered the final word in programming languages.
  • jeswin 11y ago
    >Just gonna throw this out there: what if instead of working on creating the myriad of "better languages" we focus on actual mastery of simpler languages like C. Relying on people being careful does not work for security, where one exploit is as good as many. OTOH, simpler languages can work well for performance, features and almost everywhere else; where even if you don't have specific language features to guard against common mistakes, the impact of an oversight is fairly localized or correctable.
    • wangchow 11y ago
      Hence why I followed up with: "what about writing some machine-learning software that detects vulnerabilities as part of the build/release cycle"
  • ubernostrum 11y ago
    we focus on actual mastery of simpler languages like C We've had 44 years for people to master the "simplicity" of C. Turns out, writing C is simple but writing safe, reliable C borders on the impossible even for the most masterful masters who ever mastered their mastery of the language. Better return on investment would be to work on killing C with something that doesn't have C's problems.
• daurnimator 11y ago
  Rust has major unsafeness around low memory that make it unsuitable in this libc type role. See: https://www.reddit.com/r/rust/comments/2mthq2/how_would_a_rust_application_be_able_to_properly/ https://www.reddit.com/r/rust/comments/2mthq2/how_would_a_ru... and https://lwn.net/Articles/644708/ https://lwn.net/Articles/644708/ Due to this issue that the rust authors seem unwilling to address, I fully recommend against rust for the precise roles it's intended to be good at.
  • hermanradtke 11y ago
    Based on my reading, only the std library has the behavior unsuitable for a libc type role. I would think a libc replacement would use #[no std] and have the finer grained control.
    • roca 11y ago
      Exactly.
  • kibwen 11y ago
    You misunderstand the role of Rust's standard library. For "libc type roles" you'd be using libcore, which is a subset of the standard library that does no allocation whatsoever, and allows you to define your own allocators and do whatever you like on allocation failure.
  • brandonbloom 11y ago
    From second link: > Obviously on OOM you usually want to abort _something_. It's just not always the entire thread or process. Surely you want to abort _some dynamic extent_. The fact that it's (currently) a full C thread is an implementation detail that can hopefully be improved. Requiring manual OOM handling on every single operation is not a scalable solution and will lead to bugs due to laziness or fatigue. Exceptions aren't necessarily bad/evil. A lot has been learned about the challenges of exceptions/conditions/effects. Language designs will evolve to have better versions of what is a foundational idea in the theory of computation. In the meantime, a try/catch block is only a small macro over thread::spawn, thread::join, thread::catch_panic away. It would be nice if the language supported that without the weight of a full thread.
• _greim_ 11y ago
  There's a perverse incentive in software, where toolsets requiring memorization of arcana not inherent to the problem domain but inherent to how the tool maps onto the problem domain, will generate irrational loyalty among its users. Our toolsets and the investments we make in them really do become a way of life, and fuck the world if it tries to get us to change.
• gnu 11y ago
  Rust is nice. But the article miss one important point. Modern software engineering is a collaborative effort (well, it has always been, afaik). I write code for others to understand. I find Rust code significantly hard to read (I am saying this as an experienced C/C++ programmer and as an intermediate haskeller). Yes, one can write write-only code in any language. I think it is extremely important to write code that others can understand and imho, it trumps all other reasons. Not trying to underplay the value of type safety. It is fantastic. My Haskell programs have much much less bugs and I tend to get it to work, much faster than when I do C/C++ code. I would expect some of that goodness to be in Rust programming as well. It would have been fantastic, if Rust took only a few steps further from Cyclone. I also wish that Rust authors stop adding more and more features. The target audience, namely low level system programmers, tend to work close to hardware and think along those lines, so bombarding them with type theory concepts is only going to shoo them away. Just my 2 cents.
  • kibwen 11y ago
    And as a Rust and Python programmer, I find C++ hard to read (I can never shake the feeling that the ampersands are always in the wrong place), and I'm nearly hopeless at deciphering Haskell. :P I suppose this is just something that comes with experience.
    • kyllo 11y ago
      Haskell syntax is really nowhere near as complex as C++'s or even Rust's. It's not indecipherable, it's just different and not C-like. It's in the same family as SML, OCaml and F# so if you learn one of those, the others come easily.
      • kibwen 11y ago
        Indeed, this isn't meant as a knock against Haskell in particular, merely an observation on unfamiliarity. :)
      • FreeFull 11y ago
        I suspect Haskell's syntax isn't as much of an issue as the typical style that Haskell code tends to be written in; really short, abbreviated variable names, and very high code density.
• jeffdavis 11y ago
  "[Other safe languages] require complex runtime support that doesn't fit in certain contexts (e.g. kernels)." Complex runtimes are also unsuitable for libraries. If you write a great openssl replacement in Haskell, it's only useful for Haskell applications. Because nobody wants to link the Haskell runtime into many of the applications that use openssl. For widespread libraries, the choices are basically C, C++, and now (hopefully) rust.
  • whyever 11y ago
    You can provide C bindings for you Rust library.
    • masklinn 11y ago
      Which is "for widespread libraries, the choices are basically C, C++, and now (hopefully) rust.": as in C++ you can use high-level constructs internally without relying on an extensive runtime, and expose and easy-to-FFI C interface. Rust still has insufficiencies though, the inability to customise the (library's) allocator is one I think.
      • steveklabnik 11y ago
        You can use a custom allocator on nightly.
        • masklinn 11y ago
          Does the custom allocator support allow for runtime customisation e.g. the library user calling it to set allocator functions then starting to use it? And I expect the custom allocator is global?
          • steveklabnik 11y ago
            Currently, it replaces the global allocator. Using multiple allocators is an interface that's still being actively worked on, it's in the RFC stage, so no code has landed yet.
• pjmlp 11y ago
  How I wish people understood this when we were comparing Ada, Modula-2, Modula-2+, Modula-3, Pascal dialects, Oberon, Oberon-2, Active Oberon, Component Pascal,... to C. Apparently we were the fools. But this will never happen in UNIX OSes. The culture is married to C, regardless how many memory corruption exploits per days might get a CVE entry. However I hope to be proven wrong.
  • dpc_pw 11y ago
    The syntax is killing these languages. Sure it's superficial, but programmers are human beings and I doubt most people find it appealing to voluntary stare at and type PROCEDURE BEGIN END and other LONGCAPITALIZEDWORDS...
    • pjmlp 11y ago
      Most programmer friendly editors for those languages supported formatting as you type, gofmt isn't the first of its kind. Also it makes very easy to recognize reserved keywords.
      • dpc_pw 11y ago
        BEGIN COMMENT No matter what editor does, programmer still has to look at this ugliness. :D END
        • pjmlp 11y ago
          Beauty is in the eyes of the beholder. :)
• throwawyr424415 11y ago
  Doesn't modern C++, with smart pointers, auto, and the rest, cover most of the same ground rust does, and isn't the Rust community somewhat toxic, with activists pushing "Codes of Conduct" and other non-technical agendas?
  • roca 11y ago
    With modern C++ you can still easily shoot yourself in the foot and trigger memory-unsafe behaviour. Whatever your opinion of Codes of Conduct, lots of projects have them now. And IMHO not having a Code of Conduct encourages its own sort of toxicity.
  • GolDDranks 11y ago
    It's the opposite; the Rust community feels very welcoming, well-behaved and indeed – non-toxic.
• mback00 11y ago
  IMO -- Better is to just write better tools for plain olde ANSI-C. We can build tools to check C as well as any other. Let's just not waste time on building further complexity into our toolset and look at building toolkits and best practice at the very flexible level of abstraction that Plain olde C provides. With the right tools and expertise, we can improve the world without the never ending whiz bang rewrite.
  • steveklabnik 11y ago
    > We can build tools to check C as well as any other. This is simply not true; language semantics determine the kinds of tooling you can build. Ruby is so dynamic that it's notoriously hard to build tools for, for example.
• progman 11y ago
  Don't waste your time rewriting almost unmaintainable legacy stuff. Perl actually died because the Perl 6 developers made the mistake to retain compatibility with Perl 5 which was not possible due to its unmaintainability. At first it looked promising but later on it turned out to be impossible. Rust could fall into the same trap by retaining dependency on C/C++. I would use Rust for a complete startover. Open source development should shift its mentality to support open hardware. This could ensure safety of both hardware and software in the future, and it would attract many developers who want to contribute. We already have the tools for open hardware: free IP cores, 3D printers, free CAD, equipment for DIY PCB/SMD boards, etc. ... and Rust for bare bone programming.
• wsha 11y ago
  How dependent is Rust on Mozilla for support now? Has it developed its own community of contributors? I like Mozilla and their mission, but with the way things have been going the past few years I wouldn't want to put a lot of time into porting my projects to something whose future was dependent on Mozilla.
  • steveklabnik 11y ago
    As of just now, we've had 1323 contributors to the main repository, not counting Cargo, some crates, or the website, for example. Mozilla is paying virtually all of the people who are working on it full-time, but there are a lot of people doing a lot of work in their spare time too. > with the way things have been going the past few years If you're referring to the projects which have been dropped over the past few years, I can see that. At the same time, Firefox is the core product, and Rust is already in Firefox, so dropping it doesn't seem likely. The amount will only be increasing.
• madebysquares 11y ago
  Sometimes I don't even feel the need to read the articles because the comments are so good. Good stuff guys.