Slashdot Mirror


Tor Browser Will Feature More Rust Code (bleepingcomputer.com)

An anonymous reader writes: "The Tor Browser, a heavily modified version of the Firefox browser with many privacy-enhancing features, will include more code written in the Rust programming language," reports BleepingComputer. In a meeting held last week in Amsterdam, Tor developers decided to slowly start using Rust to replace the C++ code. The decision comes after Mozilla started shipping Rust components with Firefox in 2016. Furthermore, Rust is a memory-safe(r) language than C++, the language used for Firefox and the customized Tor code, which means less memory corruption errors. Less of these errors means better privacy for all.
"Part of our interest in using safer languages like Rust in Tor is because a tiny mistake in C could have real consequences for real people," Tor developer Isis Agora Lovecruft posted on Twitter, adding "Also the barrier to entry for contributing to large OSS projects written in C is insanely high."

149 comments

  1. And the barrier for Rust isn't? by AuMatar · · Score: 3, Insightful

    I'm pretty sure the number of programmers who know C is several orders of magnitude higher than Rust.

    --
    I still have more fans than freaks. WTF is wrong with you people?
    1. Re:And the barrier for Rust isn't? by ljw1004 · · Score: 4, Insightful

      I'm pretty sure the number of programmers who know C is several orders of magnitude higher than Rust.

      I can't imagine that being a problem. Rust is a familiar looking language designed not to have shoot-yourself-in-the-foot holes. I'd expect a good developer, who's already familiar with other languages, to be contributing good PRs in Rust within a day.

    2. Re:And the barrier for Rust isn't? by Anonymous Coward · · Score: 1

      I'm pretty sure the number of programmers who think they know C is several orders of magnitude higher than Rust.

      There, fixed that for you.

    3. Re:And the barrier for Rust isn't? by AuMatar · · Score: 1

      You want an app that's supposed to protect your security online to be written by someone who hasn't studied or used the language but decided they could do well enough "within a day"? Yeah, no thanks.

      --
      I still have more fans than freaks. WTF is wrong with you people?
    4. Re:And the barrier for Rust isn't? by phantomfive · · Score: 1

      Try getting a hiring manager to believe that.

      --
      "First they came for the slanderers and i said nothing."
    5. Re:And the barrier for Rust isn't? by ljw1004 · · Score: 5, Informative

      You want an app that's supposed to protect your security online to be written by someone who hasn't studied or used the language but decided they could do well enough "within a day"? Yeah, no thanks.

      Honestly, yes. A clean language like Rust means that you won't get problems due to misuse of the language no matter how new you are to it; only due to misunderstanding of algorithms or architecture or security principals. The whole point of the comparison with C is that after a decade of experience in C you'll still find accidental security flaws due to unspotted buffer overruns or read-after-free.

    6. Re:And the barrier for Rust isn't? by WarJolt · · Score: 1

      You still didn't get it right...

      I'm pretty sure the programmers who know Rust are several orders of magnitude better programmers.

    7. Re:And the barrier for Rust isn't? by _KiTA_ · · Score: 1

      ITT: The Holy Wars begin.

    8. Re:And the barrier for Rust isn't? by IAN · · Score: 4, Informative

      Quick goggle tells me that rust compiler is written in C.

      That's why nobody seriously uses Goggle. Now if you tried Google, you'd get a snippet mentioning a "self-hosting compiler written in Rust" as the first result.

      (Yes, Rust's code generation backend is LLVM, written in C++. Don't try to build strawmen out of this.)

    9. Re:And the barrier for Rust isn't? by Anonymous Coward · · Score: 0

      Will Rust "protect us" like Java did?
      Or why people fall for the same bullshit talk decade after decade....bah
      Those who do not learn with history...
      Posted as AC not to undo moderation.

    10. Re:And the barrier for Rust isn't? by K.+S.+Kyosuke · · Score: 1

      Who makes more safety-related mistakes, ten C-niks or one Rustnik? Not to mention that you need a fixed small number of programmers for the project, you're not interested in luring the whole global community.

      --
      Ezekiel 23:20
    11. Re:And the barrier for Rust isn't? by DrXym · · Score: 2
      The Rust compiler is written in Rust, i.e. its self hosting. It was originally written in OCaml but has been ported to itself for a long time.

      However it emits bitcode which is optimized and transformed into machine code by LLVM. So after code has passed the multitude of safety checks in the front end it shares a substantial portion of its toolchain with Clang and other languages that make use of LLVM.

    12. Re:And the barrier for Rust isn't? by Raenex · · Score: 2

      I'd expect a good developer, who's already familiar with other languages, to be contributing good PRs in Rust within a day.

      Are you a manager? Do you actually code in Rust? Because while I don't code in Rust, I spent some time with it to understand what kind of guarantees it provides. There are several concepts that you have to wrap your head around and become familiar with before you can write code and know what's going on at a fundamental level.

    13. Re:And the barrier for Rust isn't? by Anonymous Coward · · Score: 0

      "No one sane will write web and server-side software in a language like that - especially considering that it doesn't offer any significant advantages over those languages for JVM. Even Go - with normal lightweight processes (not futures) - seems a way better choice for solving these tasks"

      ahem... Tor team excluded

      https://www.viva64.com/en/b/0324/

    14. Re:And the barrier for Rust isn't? by Anonymous Coward · · Score: 0

      Will Rust "protect us" like Java did?

      Compared to C? I'd suppose Java did a pretty good job.

      Or why people fall for the same bullshit talk decade after decade....bah

      Because.. see above.

      Those who do not learn with history...

      Apparently they did learn that memory management is best left to experts, and not the code monkey hordes, for one.

      Posted as AC not to undo moderation.

      Posted as AC for

    15. Re:And the barrier for Rust isn't? by BESTouff · · Score: 1

      I'm pretty sure the number of programmers who know C is several orders of magnitude higher than Rust.

      You don't get it. In every respectably-sized C project, there are lots of assumptions about "objects" lifecycles (who allocates, who has to free), concurrency access, etc. Unless you have spent a long time in the code it's difficult to know all the conventions used throughout the project, and you're pretty sure you'll shoot yourself in the foot the first time you'll try to modify the code.

      In Rust, all these conventions are encoded in the type system and are checked by the compiler. Which means that when your modification compiles, it already respects these conventions and you're pretty sure it won't break one of those subtle assumptions. At least not so easily than in C. So your patches are easier to review. So the barrier to entry is generally lower.

    16. Re:And the barrier for Rust isn't? by Highdude702 · · Score: 0

      what fundamental level? Its 2017! We dont care about how the shit works we just want it to work. you must be one of those stick in the mud "i want to be smart" people. Havent you noticed your kind are going the way of the do do bird..

    17. Re:And the barrier for Rust isn't? by bugs2squash · · Score: 2

      The barriers I've encountered are typically only coincidental to C. It's that half the code appears to be written in m4 or something equally impenetrable.

      --
      Nullius in verba
    18. Re:And the barrier for Rust isn't? by unrtst · · Score: 1

      Havent you noticed your kind are going the way of the do do bird...

      I wish the do do bird would go the way of the dodo bird.

    19. Re:And the barrier for Rust isn't? by Highdude702 · · Score: 1

      WAT?!?

  2. Well rust must be reallllly good... by Anonymous Coward · · Score: 1

    "because a tiny mistake in C could have real consequences for real people"
    Seems rust is an ai that churns out code which can never do evil.

    1. Re:Well rust must be reallllly good... by KiloByte · · Score: 4, Funny

      No one is suicidal enough to write critical code in C. What would happen if someone wrote, say, a kernel, in C!?!

      --
      The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
    2. Re: Well rust must be reallllly good... by Anonymous Coward · · Score: 0

      Windows and Linux are two famous swiss cheeses.

    3. Re:Well rust must be reallllly good... by Anonymous Coward · · Score: 0

      Right. A tiny mistake in C can be very important, so let's replace C++ with Rust.

      Wait, what?

    4. Re:Well rust must be reallllly good... by Anonymous Coward · · Score: 0

      That would never happen. Git out!

    5. Re:Well rust must be reallllly good... by Anonymous Coward · · Score: 1

      What is it with this perfect solution fallacy based Rust meme? No one is saying Rust can prevent all coding problems, except those of you creating strawmen. But solving some common mistakes is still a step forward, even if it is not solving all possible mistakes and problems.

    6. Re:Well rust must be reallllly good... by Waffle+Iron · · Score: 1

      What would happen if someone wrote, say, a kernel, in C!?!

      The users would probably be subjected to an endless treadmill of updating their kernel packages and rebooting each of their machines every couple of weeks.

    7. Re:Well rust must be reallllly good... by PolygamousRanchKid+ · · Score: 0

      "because a tiny mistake in C could have real consequences for real people"

      As opposed to, "because a tiny mistake in C could have virtual consequences for virtual people."

      C'mon . . . this is 2017 . . . nobody does anything real anymore . . . everything is virtual these days.

      Remember:
      If it's there, and you can see it . . . it's real.
      If it's not there, but you can see it . . . it's virtual.
      If it's not there, and you can't see it . . . it's gone.

      Virtual people have virtual problems on virtual TV shows.

      So, there!

      --
      Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
    8. Re:Well rust must be reallllly good... by Anonymous Coward · · Score: 1

      But that's really just it though isn't it? You write core functionality like a Kernel in C, but it's relatively small part of the overall code base - it's a part to which you devote a disproportionate amount of time relative to it's size because you absolutely must get it right and because hand crafting performance into it is incredibly important.

      You wouldn't then however go and take C all the way up to your web stack, because that would be fucking stupid - the cost and time to productivity and security ratio is just simply not acceptable.

      Similarly we've tried writing web browsers for decades in C and C++ now and time and time again they're the biggest source of client side vulnerabilities - it doesn't matter if we open source it or do it closed source, it doesn't matter whether teams are big or small, funded by large companies, or run by open source foundations, it's clear we just cannot build secure browsers in C and C++, we've been trying this experiment for nearly 25 years and it's been a consistent failure.

      We saw a similar change with web applications - sure they still get hacked left and right, but the types of attack (e.g. SQL injection) are far less harmful than the exploits that used to let you outright root a server via the web application because it was built on a CGI module written in C. Even if we haven't mitigated attacks completely we've at least drastically dampened their impact in recent years such that the threat is now data leakage, rather than outright hijacking of your system (which typically led to much more severe data leakage and way more on top)

      Trying something else is a good thing, maybe it'll work, maybe it wont, but we know for sure that the quality of browsers over the years can hardly be deemed as "good", so it's reasonable to try a different tactic.

    9. Re:Well rust must be reallllly good... by Anonymous Coward · · Score: 0

      Have you ever had about Unix? The folklore says it has *still* an huge C codebase...
      Now get out of my browser, please.

    10. Re:Well rust must be reallllly good... by K.+S.+Kyosuke · · Score: 4, Informative

      What would happen if someone wrote, say, a kernel, in C!?!

      The thing you observe around you right now: holes in kernels, servers, browsers, virtual machines, regular security announcements... (Because everyone decided to repeat the same mistake.)

      --
      Ezekiel 23:20
    11. Re:Well rust must be reallllly good... by K.+S.+Kyosuke · · Score: 1

      Yes, and its creators regret it.

      --
      Ezekiel 23:20
    12. Re:Well rust must be reallllly good... by DrXym · · Score: 2

      A tiny mistake in C++ can be just as fatal. Besides which C++ is mostly a superset of C so it can make all the mistakes that C allows and a whole heap of its own on top.

    13. Re: Well rust must be reallllly good... by Entrope · · Score: 1

      And Rust is famously corrosive. Once your product starts to Rust, it gets ugly and easily broken. Pretty soon even a toddler can punch holes through it.

    14. Re:Well rust must be reallllly good... by Anonymous Coward · · Score: 0

      Tin roof...... Rusted!

    15. Re:Well rust must be reallllly good... by Anonymous Coward · · Score: 0

      So where are all of the kernels, servers, browsers, virtual machines, etc., etc., etc., etc., written purely in "safer" non-C/non-C++ languages?

      I'm not talking about small weekend projects or impractical/unusable academic projects, either. I'm talking about widely used, full-featured, production-grade software.

      Java has been around for over 20 years. JavaScript has been around for over 20 years. C# has been around for over 15 years. Haskell has been around for over 25 years. Python has been around for over 25 years. Go has been around for over 7 years. Rust 1.0 was released almost 2 years ago. There are many other "safe" languages that I haven't mentioned.

      So given all of this time, and all of these different non-C/non-C++ languages, why have we seen almost none of the types of software you listed be successfully implemented using them?

      The best we've seen are things like Tomcat and Jetty, written in Java. But even then, they see almost no use compared to web servers like Apache and nginx. And they haven't been free of security issues either.

      Web browsers written in non-C/non-C++ languages have all been failures. Xena/Javagator was a failure. HotJava Browser was a failure. Grails was a failure. Servo is shaping up to be a colossal failure.

      Face it, C and C++ have proven themselves to be the only languages capable of being used successfully for the types of software that you listed. Despite having had allegedly "safer" languages for decades and decades now, we haven't seen anyone come up with anything to successfully replace the software written in languages like C or C++.

      The only "mistake" would be not using C or C++.

    16. Re:Well rust must be reallllly good... by Anonymous Coward · · Score: 0

      Five years from now, machine learning will do most of the coding, leaving programmers looking for work.

      I know this because I read it in Wired.

    17. Re:Well rust must be reallllly good... by Anonymous Coward · · Score: 0

      (Because everyone decided to repeat the same mistake.)

      Google is still repeating it, sorta. They are writing Magenta in a mix of C++ and C, when they could have used L4 instead of LK to eliminate the C bits, or they could have used Rust for the kernel and solved this mistake once and for all.

    18. Re:Well rust must be reallllly good... by erapert · · Score: 2

      Java has been around for over 20 years. JavaScript has been around for over 20 years. C# has been around for over 15 years. Haskell has been around for over 25 years. Python has been around for over 25 years. Go has been around for over 7 years. Rust 1.0 was released almost 2 years ago. There are many other "safe" languages that I haven't mentioned.

      If you knew anything at all about software you would know the implications that garbage collection has on performance. It's a good thing you posted as AC because otherwise you would have just embarrassed yourself to the point that you'd probably be down-modded for the next fifty years.

      So given all of this time, and all of these different non-C/non-C++ languages, why have we seen almost none of the types of software you listed be successfully implemented using them?

      To reiterate: because performance.

      Web browsers written in non-C/non-C++ languages have all been failures. Xena/Javagator was a failure. HotJava Browser was a failure. Grails was a failure. Servo is shaping up to be a colossal failure.

      Servo was never intended to be actually used-- It's just an experimental prototype for research.

      Face it, C and C++ have proven themselves to be the only languages capable of being used successfully for the types of software that you listed. Despite having had allegedly "safer" languages for decades and decades now, we haven't seen anyone come up with anything to successfully replace the software written in languages like C or C++.

      I like C++. But you're mistaken in thinking that Rust should be compared to JIT languages like C# or Java or Javascript or to automatic garbage collected languages like Go or D. Yes, the details matter and Rust does have promise.

      Time will tell whether C++ evolves and outpaces Rust or whether Rust's standard library and general ecosystem are better.

      At this moment, though, it looks like Rust is roughly equivalent to C++ for performance which is not too surprising since rustc uses LLVM as its backend for compilation. I also think Cargo and crates are superior to the C++ way of handling libraries-- in the sense that a package manager is superior to manually finding libs and installing packages.

    19. Re:Well rust must be reallllly good... by Anonymous Coward · · Score: 0

      On OpenBSD that's happened exactly once.

    20. Re:Well rust must be reallllly good... by Anonymous Coward · · Score: 0

      ... and how many of them are really caused by the language, and not the developer in case being and idiot/ignorant/sloppy? Bad design/sketchy logic can basically always do you in.

      It's not like C is the only language you can write unsafe code in, which the discourse commonly could make you believe. Hardly surprising though, since it's a lot more easy to blame your tool, C, than admitting to having screwed up.

    21. Re:Well rust must be reallllly good... by K.+S.+Kyosuke · · Score: 1

      So where are all of the kernels, servers, browsers, virtual machines, etc., etc., etc., etc., written purely in "safer" non-C/non-C++ languages?

      Probably in the same place where there are non-brainwashed programmers, like those who grew up with C since their very childhood? It's a vicious circle you're dealing with here.

      Java has been around for over 20 years. JavaScript has been around for over 20 years. C# has been around for over 15 years. Haskell has been around for over 25 years. Python has been around for over 25 years. Go has been around for over 7 years. Rust 1.0 was released almost 2 years ago. There are many other "safe" languages that I haven't mentioned. So given all of this time, and all of these different non-C/non-C++ languages, why have we seen almost none of the types of software you listed be successfully implemented using them?

      They're not quite old. C began around 1970. That's pushing fifty years of age now! And it took twenty years for many software systems to even start adopting it as the system language. Some, like MacOS, had an affinity towards Pascal before they started getting their first bits of C. Lots of those you mention are not suitable for it anyway, so you won't see an OS in Javascript. But give Rust another fifteen years and you might see an operating system in it.

      I'm not a Rustnik, though. But, e.g., Oberon worked quite well whenever it was applied - except that it never got really popular even in Europe, and was virtually unknown elsewhere, because C/Unix/Windows were already choking the world of computing by that time.

      --
      Ezekiel 23:20
    22. Re: Well rust must be reallllly good... by Blaskowicz · · Score: 1

      I can't wait for Rust to run on big iron.

    23. Re:Well rust must be reallllly good... by Blaskowicz · · Score: 1

      If it's there, and you can see it . . .
      If it's not there, but you can see it . . .
      If it's not there, and you can't see it . . .

      We should ask Donald Rumsfeld about this then.
      Also, for the case of "If it's there, but you can't see it".
      Alternatively you might have something to teach Rumsfeld about!

  3. Uh-huh by 93+Escort+Wagon · · Score: 2, Interesting

    "Part of our interest in using safer languages like Rust in Tor is because a tiny mistake in C could have real consequences for real people," Tor developer Isis Agora Lovecruft posted on Twitter[.]

    This line of thinking seems eerily similar to the arguments people make when they choose to roll their own encryption rather than rely on a pre-existing project like openssl.

    --
    #DeleteChrome
    1. Re:Uh-huh by phantomfive · · Score: 1

      tbh if you did roll your own encryption instead of relying on openssl, there's a reasonable chance your code would end up being more secure. Your chances of success entirely depends on how good you are at programming.

      --
      "First they came for the slanderers and i said nothing."
    2. Re:Uh-huh by Anonymous Coward · · Score: 0

      Compared to the people who did openssl, who started out (and to an extent still are!) laypeople rolling their own encryption. Of course, by now they have a large body of work and presumably learned a thing or two from their sometimes very public mistakes. But the sheer size leads to problems too, witness the rationale for "libressl" (a project in turn run by self-styled "experts" in securing C in specific ways but who aren't that great with crypto either, o delicious recursive irony).

      On a similar-but-different note, I can get why mozilla is "doing" rust and why torbrowser is following suit. Have you looked at their code? rust may well end up an improvement for them. Which is not to say that using rust is a good idea, just that them using rust is a better idea than them using the "C/C++" bastard mix they've been using so far. Even with rust being a safe space language with a code of conduct against microaggressions and all that.

      Compare with this line of thinking:

      Is anyone working on porting PostgreSQL to Rust? [...]
      My motivation is primarily I don't want to learn all the over-complicated details of C, but at the same time I would like to be productive in a safe system language, a category in which Rust seems to be alone.

      In other words, "please someone else please do lots of hard but pointless work for me so that I may pretend to be productive."

      But who knows? Maybe something good will come out of throwing rust at the torbrowser project. I for one, etc.

    3. Re:Uh-huh by phantomfive · · Score: 2

      In other words, "please someone else please do lots of hard but pointless work for me so that I may pretend to be productive [postgresql.org]."

      It's actually amazing to me how maturely and respectfully the Postgresql guys responded to that. They are truly a mellow bunch.

      --
      "First they came for the slanderers and i said nothing."
    4. Re:Uh-huh by Anonymous Coward · · Score: 1

      From a code quality point of view, absolutely. OpenSSL is a horribly written, poorly documented codebase with a long history of coding mistakes.

      From a cryptography point of view -- beware. There are a huge number of gotchas. It's not enough to implement the TLS and PKI specs to the letter. You have to make sure that your code is resistant to side-channel (timing) attacks, oracle attacks, workarounds for buggy clients/servers, workarounds for weaknesses in the spec, etc. Most of that comes about through trial by fire, where security experts poke holes in your library over a number of years. You can't just replace openssl overnight. If you find a SSL library that doesn't have any CVEs, it probably isn't popular enough for security experts to try to crack.

      TLDR; being good at programming is not enough. You have to be good at crypto, and even then, sometimes the experts get tripped up or forget something.

    5. Re:Uh-huh by Anonymous Coward · · Score: 1

      I've been doing 'C' for a _long_ time (and I remember and used the =+ and =- operators).
      I haven't run into these over-complicated details of 'C'; maybe I've missed them. Elegant,
      yes, but over-complicated - no!

      It all comes down to testing - coming up with unit tests to ensure new code and/or changes
      you make don't regress. Look at git hub - you can count (probably) on one hand the number
      of projects that have a serious test suite built in to their code base - you know gmake test.
      It's not the language, but the process of (modern) development that's an issue. Everybody
      wants to code the happy case.

      I remember being asked by a mamager "what happens if I cat /kernel into your code
      as input? What an eyeopener. So after that, if I worked on an PoS project (say) for 60,000 items,
      I'd test with 120,000 items (this was back when ram was tight, too). And so on. Made the code tough as nails.

      Yes, it's possible to write sound code. These "secret" techniques just aren't taught anymore.
      What is taught is being lazy - let the language do all of your thinking (although I can't explain what
      happened to C++ - I think it's more of a nerd world building pointless ego-power enviornment -
      look at how little its developers document their wonderful creations - the exception rather than rule).

      CAP === 'parapet'

    6. Re:Uh-huh by K.+S.+Kyosuke · · Score: 1

      It might not necessarily be pointless. Chances are that PostgreSQL could benefit from it hugely (see the outcome for Servo), but it's a leap that would take a long time with little outward-visible progress for users.

      --
      Ezekiel 23:20
    7. Re:Uh-huh by Anonymous Coward · · Score: 0

      I've been doing 'C' for a _long_ time (and I remember and used the =+ and =- operators).
      I haven't run into these over-complicated details of 'C'; maybe I've missed them. Elegant,
      yes, but over-complicated - no!

      You don't see it. Perhaps you're simply too familiar with the thing to see what's right under your nose. The kid does see it. Or maybe he's being a special snowflake. Who knows?

      Personally I think C is by no means perfect, there's UB in every nook and cranny, but on balance it's a useful tool for the knowledgeable. If you want overcomplicated, look at PHP. It doesn't have the trickiness that comes with the industrial power simple tools like C sport (and Unix famously has), but it does borrow drawbacks from every idea it incorporates, mainly by failing to understand wtf they're trying to do at every opportunity. And yet the thing is massively popular with a certain class of users. None of whom are very bright when it comes to writing programs, because if they were they'd've ran away screaming long ago. As have the good language developers, and yes, to those in the know, it shows.

      Anyway, the "overcomplicated" argument is bunk and obviously reaching. It makes no sense to rewrite in another language the entire code base of a high quality project just because it makes one special snowflake feel safer. Especially not when said snowflake is probably only marginally trustable writing the thing, leaving contributing code so far in the mist it is funny in and of itself already. So the real reason is likely something different. Which it is, in this case. The question is a slur and a political one at that. Notice that rust has become a rallying point for a certain crowd with certain political views and outlooks. So the quoted question was really about politics, and it's fairly safe to say that anyone embracing rust is thereby making a political statement. Just like embracing poetteringware is a political statement, even if many in the scene are incapable of discerning that they are making a political statement by embracing poetteringware, since they got into computing exactly because they wanted nice and predictable things to play with, not those pesky humans and their politicking. The politicking came calling anyway; you can see it because of the fantasticallly poor quality of the code and the design and its mysterious success at adoption in the face of better quality alternatives being readily available. All those technical merit discussions weren't about technical merits. The opposition had lost before they started because their technical arguments weren't about what was really being discussed. And so we're stuck with fantastically bad code doing far too much for comfort and making itself artificially indispensible at a sensitive spot, where it really has no legitimate business being in the first place.

      Likewise, the one bid to rust fame so far is in things done by mozilla. The torbrowser project is not mozilla, but heavily dependent on mozilla, so they more or less have little choice to acquiesce. The big thing is that they're not just standing by and have it happen, no, they're going big on embracing rust. So they're convenient poster children that aren't mozilla, making them good propaganda material. They also happen to have quite a strong strand of SJW going on, see the ongoing Appelbaum spat. Politics and code, what could possibly go wrong?

      What is taught is being lazy - let the language do all of your thinking

      "Well, what else is a computer for?"

      This is a common theme in computing. Pervasive, even. Not limited to programming either. The whole "app" fad has shades of this, and so do political attempts at "progress" through "digital transformation", or whatnot. That scourge from that racketeering marketeering company, "windows", is a fine example. "N

    8. Re:Uh-huh by Anonymous Coward · · Score: 0

      Excellent points. Only point I strongly disagree with is --

      "Well, what else is a computer for?"

      Computer are not for thinking; they're good at performing repetative task;
      but a program written to solve a problem cannot solve its own problems.
      So, too much reliance is placed on a "higher" level language to solve the
      programming problems a developer is too lazy / unresourseful enough
      to solve or understand themselves.

      Fine, if you don't understand pointers and how they work, be a script kiddie.
      You'll only be able to go so far in a language like Rust if you don't become
      fluent in some of the basic concepts of 'C'.

      CAP === 'libelous'

    9. Re:Uh-huh by Anonymous Coward · · Score: 0

      Excellent points. Only point I strongly disagree with is --

      "Well, what else is a computer for?"

      Computer are not for thinking;

      You don't have to agree with it. In fact, I don't think the notion was ever a good idea. But it is a strong and recurring theme in computing-land regardless. Compare this little old gem:

      On two occasions I have been asked, — "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" In one case a member of the Upper, and in the other a member of the Lower, House put this question. I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

      —Passages from the Life of a Philosopher (1864), Charles Babbage.

      Evidently, most of us are still in that confused state.

      You'll only be able to go so far in a language like Rust if you don't become
      fluent in some of the basic concepts of 'C'.

      *cough* I did mention PHP was quite popular, didn't I? *cough*

      Though in a sense rust has to go there, for, as mentioned earlier, it is a political statement with a strong "no child left behind" sentiment going, so you can't have your "overcomplicated" C, it has to be "simpler" and "more robust" and "easier to use" and whatnot. On its face they're not even bad sentiments, though tried before (java, its political contender ceehashdotnet, lisp in all its variant glory, you name it) yet never managing to decisively oust "unsafe" languages, but the underlying reason in rust's case is very much political. Maybe it was built in from the start, or maybe it got hijacked before it got out the door. It doesn't really matter, it is now a politicial statement. Even if it turns right 'round and belies all that by building on a llvm and thus written in C++ backend. And if C is "overcomplicated", then what might C++ be, hm? But as you can see elsethread, basing any argument on that contradiction is "building strawmen", so it's all good. No looking behind the curtain, dear believers.

    10. Re:Uh-huh by Anonymous Coward · · Score: 0

      PHP is, like C++, a language people love to hate,
      except in PHP's case, people can actually agree
      upon and understand what it is that they hate in PHP

      CAP === 'flamebait'

    11. Re:Uh-huh by phantomfive · · Score: 1

      PostgreSQL code is dramatically cleaner than Mozilla code, and any benefit would be correspondingly smaller. Certainly though, I don't expect project maintainers to be calm when random outsiders come in and tell them to rewrite all their code in a different language.

      --
      "First they came for the slanderers and i said nothing."
    12. Re:Uh-huh by K.+S.+Kyosuke · · Score: 1

      I'm pretty sure it is! The thing I had in mind mostly was the relative difficulty of introducing highly threaded code. But chances are that the most painful spots have already been addressed, and database servers are mostly highly specialized compilers these days, so the performance of the meta-program (a large part of the server code) may not matter all that much.

      --
      Ezekiel 23:20
    13. Re:Uh-huh by phantomfive · · Score: 1

      btw, you mentioned Servo, how is that going? Are they having good success?

      --
      "First they came for the slanderers and i said nothing."
    14. Re:Uh-huh by K.+S.+Kyosuke · · Score: 1

      I'm not up to date but it seemed to be progressing nicely the last time I checked. Especially on mobile devices where comparable performance was achieved on four threads with just 60% of the power that was required by a single, higher-clocked thread to do the same job. It's going to be a big change for Firefox/Gecko, though, and I'm not sure all the improvements can be integrated incrementally.

      --
      Ezekiel 23:20
    15. Re:Uh-huh by phantomfive · · Score: 1

      Yeah, with all the improvements coming up, I think Firefox has good potential to leap to the top browser here in the coming year or so.

      --
      "First they came for the slanderers and i said nothing."
    16. Re:Uh-huh by Anonymous Coward · · Score: 0

      It all comes down to testing - coming up with unit tests to ensure new code and/or changes
      you make don't regress.

      No. It's completely impossible for unit tests to definitively prove a C program can never contain undefined behavior, that may or may not have any actual effects, unless your continuous integration testsuite happens to every possible architecture and compiler version that exists now or ever will exist in the future. Undefined behavior bugs could hide for years and only be exposed by some new aggressive optimization pass added to GCC or Clang/LLVM due to some corner case of C that 'worked fine' before.

  4. The budget per US federal case by AHuxley · · Score: 1

    is able discover the origins of onion routing users. A change in code is nice but does not change the ability to track and find.

    --
    Domestic spying is now "Benign Information Gathering"
  5. What a time to live in by Anonymous Coward · · Score: 0

    Isis agora lovecruft

  6. Mixed-up priorities by Anonymous Coward · · Score: 1

    " for real people," Tor developer Isis Agora Lovecruft posted on Twitter, adding "Also the barrier to entry for contributing to large OSS projects written in C is insanely high"

    This is completely orthogonal to designing a secure browser.

    1. Re: Mixed-up priorities by Entrope · · Score: 1

      It's hard to add productive code to a large existing project. Large existing projects are mostly written in C. Therefore it's hard to contribute to C projects.

      If this is what passes for logic among the Rusty Firefox set, I'll avoid it.

  7. Social Justice Warrior Blockbot user by Anonymous Coward · · Score: 0, Interesting

    Yeah, you should totally trust someone who runs Randi Harper's industry blacklist of "problematic" people in tech. Problematic... like White people. Or Male Identifying Penis Carrying Humanoids. Or the more than three quarters of the US who didn't want to follow the faux-left Clintonites down the drain.

    Hell, the "they/them" madeup bullshit pronouns on his twitter profile is enough to stop paying attention to him, but the fact that he joined in on or even spearheaded the Jacob Applebaum lynch mob which was later proven to be a hoax created by 3 white knights who refused to even ask the supposed "victims" (who rejected it outright) they decided to speak on behalf of is enough: https://twitter.com/isislovecr...

    (Personal rule: Someone who claims to have made up bullshit pronouns is male. Since gender is a social construct and men and women have equal rights, this is not transphobic because gender doesn't matter, right?)

    Also, what's the "insanely high" bar for C? Knowing how to code? Yes, yes. Very problematic. Why would you want to require people to know how to code to contribute source code to a browser that millions rely on to keep themselves safe from being killed to actually know how to... contribute source code.

  8. If it's scary, then you don't know C. by Anonymous Coward · · Score: 0

    That's to say: the difference between knowing C and not knowing C is like that between being able to find your arse with either hand, and not.

    Those for whom C is the main hurdle shouldn't be let anywhere near the design of a critical piece of software such as Tor, let alone its implementation, regardless of language.

    1. Re:If it's scary, then you don't know C. by Anonymous Coward · · Score: 0

      Have you ever looked at GNU code for the shell commands? It's unbelievably crufty with macros piled on top of macros. I suspect the maintainers like it that way, that sharply limits the pool of coders who would have time to learn the codebase well enough to make a serious contribution. But another reason is that C is a fairly low-level language, with limited facilities for abstraction.

    2. Re:If it's scary, then you don't know C. by Anonymous Coward · · Score: 0

      Those for whom C is the main hurdle shouldn't be let anywhere near the design of a critical piece of software such as Tor, let alone its implementation, regardless of language

      And yet people who have decades of experience with C and critical software still occasionally make memory bugs.

      That's to say: the difference between knowing C and not knowing C is like that between being able to find your arse with either hand, and not.

      Most people can find their own ass with their hands, yet still back into things with it from time to time.

    3. Re:If it's scary, then you don't know C. by phantomfive · · Score: 1

      With a decent string library and buffer library, the vast majority of security bugs in C are easily fixed.

      --
      "First they came for the slanderers and i said nothing."
    4. Re:If it's scary, then you don't know C. by Anonymous Coward · · Score: 0

      So why hasn't it happened? It's naive to say C is secure if you just do it properly. There's been plenty of opportunity for plenty of people to write decent C and it has never happened. It's too easy to make security mistakes in C and so they will always happen.

    5. Re:If it's scary, then you don't know C. by phantomfive · · Score: 1

      So why hasn't it happened?

      It has happened. There are plenty of such libraries.
      Your real question, I think, is why don't more people use those libraries (or write their own)? I don't know the answer to that, but it's why I commented, so more people can know the way (or a way).

      --
      "First they came for the slanderers and i said nothing."
    6. Re:If it's scary, then you don't know C. by Anonymous Coward · · Score: 0

      Where are the examples of significant pieces of software written in C using these libraries? Where is the track record that these libraries solve the problem? If the libraries aren't practical to use then they're irrelevant.

    7. Re:If it's scary, then you don't know C. by phantomfive · · Score: 1

      Well, OpenBSD uses their own set of string libraries. It's a little too limited for my taste, but it works well for them. Microsoft cleaned up a lot of their security problems by disallowing unsafe string functions, and making their own. Again, this is too limited for my taste, but it cleaned up quite a bit.

      --
      "First they came for the slanderers and i said nothing."
    8. Re:If it's scary, then you don't know C. by roca · · Score: 1

      Nonsense. Use-after-free and double-free bugs are common sources of exploitable security issues, and "a decent string library and buffer library" doesn't help at all with those.

    9. Re:If it's scary, then you don't know C. by dunkelfalke · · Score: 2

      And yet there is no good reason to use C for anything outside certain special fields like drivers or operating system kernels, and even in these fields usage of C becomes more and more questionable.

      --
      "It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
    10. Re:If it's scary, then you don't know C. by Anonymous Coward · · Score: 0

      OpenBSD

      Whoops. Better make sure you're patched.

      Microsoft

      Yeah, because Windows 10 has no problems parsing strings or managing memory safely or anything.

    11. Re:If it's scary, then you don't know C. by Anonymous Coward · · Score: 0

      There have been wrappers/libraries to avoid that, and give asserts or runtime warnings for *decades* now. Actually, since the 90s.

    12. Re:If it's scary, then you don't know C. by Anonymous Coward · · Score: 0

      Have you ever looked at the Linux/BSD/GNU userland utils?

    13. Re:If it's scary, then you don't know C. by dunkelfalke · · Score: 2

      Matter of fact, yes. And this only drives my point home harder. I had to port a few of these for a proprietary embedded system. Ultimately it was easier to rewrite them in clean C++ and maintain the result than to maintain the original mess of code (and I am not really a C++ fan). There is no good reason to use primitive tools if advanced tools can do the job in a safer and more comfortable way. Only use primitive tools when advanced tools are unfit for the task on hand.

      --
      "It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
    14. Re:If it's scary, then you don't know C. by Anonymous Coward · · Score: 1

      And yet use-after-free and double-free bugs continue to exist. Your approach isn't working, even though it's had since the 90s to deliver. We plainly need better languages than C.

    15. Re:If it's scary, then you don't know C. by roca · · Score: 2

      Using some wrapper library to force dynamic checks on all pointer accesses would mean giving up all the advantages of using C in the first place.

    16. Re:If it's scary, then you don't know C. by DrXym · · Score: 1
      Then why isn't such a thing part of the standard? Or at least in such common use that it is a defacto part of the standard?

      If you were writing a real world application that pulled in half a dozen libs, then each of those is going to do different things with varying degrees of rigor plus your own code. Even the most scrutinized code in the world contains buffer overflow vulns so chances are your application does too. That probably doesn't matter for a game. It matters a lot for a system process or something facing the internet like a browser or an anonymizing protocol.

      An entire class of problems in C simply don't exist in Rust because it has proper intrinsic types for strings and arrays. Static info is enforced at compile time. The length of strings / arrays is enforced at runtime. Lifetime / borrow checking means you can't inadvertently read or write to garbage either. Rust is no panacea but it shuts down a pile of problems that plague C and C++. It's not hard to see why some people are beginning to advocate its use.

    17. Re: If it's scary, then you don't know C. by Entrope · · Score: 1

      OpenBSD's use of C is scary because one obscure function that is only normally used to format data structures provided by the kernel had a bug that may or may not be exploitable?

      And we're supposed to instead trust people who think the right syntax for a method that panics unless a result is good is ".expect(failure_message)"?

    18. Re: If it's scary, then you don't know C. by Anonymous Coward · · Score: 0

      And we're supposed to instead trust people

      No. You're supposed to recognize that C makes it easy to make mistakes that lead to security flaws, no matter how good a programmer you think you are. You're supposed to understand that when it comes to security a language premised on helping the programmer avoid those mistakes is a better option than one that isn't.

    19. Re:If it's scary, then you don't know C. by Anonymous Coward · · Score: 0

      Well, the lack of better alternatives would be a very good reason.

    20. Re:If it's scary, then you don't know C. by Anonymous Coward · · Score: 0

      We plainly need better languages than C.

      Yes. But Rust ain't it.

    21. Re:If it's scary, then you don't know C. by Anonymous Coward · · Score: 0

      An entire class of problems in C simply don't exist in Rust because it is not possible to write a lot of things in Rust.

      FTFY.

    22. Re:If it's scary, then you don't know C. by ArchieBunker · · Score: 1

      Try and compile any newly written C code on a platform other than Linux. Chances are it won't work.

      --
      Only the State obtains its revenue by coercion. - Murray Rothbard
    23. Re: If it's scary, then you don't know C. by Anonymous Coward · · Score: 0

      Yeah, who cares if it actually works at all or not, never mind fulfilling its purpose; good intentions should come first and foremost when choosing a language.

    24. Re:If it's scary, then you don't know C. by phantomfive · · Score: 1

      It's not part of the standard for the same reason hashes and queues are not part of the standard: there are systems where they are not needed, they can easily be acquired where they are needed, and no one wants to add more bloat to the language.

      --
      "First they came for the slanderers and i said nothing."
    25. Re:If it's scary, then you don't know C. by phantomfive · · Score: 1

      #define Free(m) free(*m); *m = NULL

      Or you can make it a function.

      --
      "First they came for the slanderers and i said nothing."
    26. Re:If it's scary, then you don't know C. by phantomfive · · Score: 1

      There's a really good reason to use C: because it's portable. Not only between systems, but also between languages. If you write a library in C, it can be used from almost any language, and bindings can be generated automatically for all of them. Not so with Python.

      But let's talk more specifically why C is better than C++: C is a clean design from the beginning. It works very well in what it is designed for, and even its critics agree on that point. Whereas C++ is the opposite of a clean design, it is a pile of garbage, and each generation adds more garbage to the pile, as the fans of the language tell you, "Don't use last year's garbage, this standard finally got it right!" No, it still didn't, C++ is still just a bigger pile of garbage. But you know, maybe a few standard's from now it will finally be a good language. What a work in progress.

      --
      "First they came for the slanderers and i said nothing."
    27. Re: If it's scary, then you don't know C. by Anonymous Coward · · Score: 0

      "
      The full impact and severity depends on the method of exploit and how the library is used by applications. According to analysis by FreeBSD developers, it is very unlikely that applications exist that utilize link_ntoa() in an exploitable manner, and the CERT/CC is not aware of any proof of concept. A blog post describes the functionality of link_ntoa() and points out that none of the base utilities use this function in an exploitable manner. For more information, please see FreeBSD Security Advisory SA-16:37."

      Seems like it's not that big of a threat at all.

    28. Re:If it's scary, then you don't know C. by dunkelfalke · · Score: 1

      a design that allows undefined behavior is as dirty as they come.

      --
      "It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
    29. Re:If it's scary, then you don't know C. by phantomfive · · Score: 1

      Oh, and you are using that to defend C++? You think C++ doesn't have undefined behavior?
      Please, come up with something better.

      --
      "First they came for the slanderers and i said nothing."
    30. Re:If it's scary, then you don't know C. by Anonymous Coward · · Score: 0

      Yes. But Rust ain't it.

      Then what is? Again you don't deliver.

    31. Re:If it's scary, then you don't know C. by dunkelfalke · · Score: 1

      I don't use it to defend C++, I use it to disprove your quaint notion that C is supposed to be clean and not an ugly hack of a language that should have died out twenty years ago. C++ is the lipstick that is used to make C look less like a pig - surprisingly with some success, especially since C++11.

      --
      "It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
    32. Re:If it's scary, then you don't know C. by phantomfive · · Score: 1

      Nah dude, look, almost every language since 1980 has copied C syntax. If it were a bad language, Java wouldn't have copied the syntax.
      Also, "undefined behavior" isn't an ugly hack, it's just reality in language design. Every language has undefined behavior except a special few like ML. Complaining about undefined behavior in a language is generally a sign that someone has no idea when it comes to language design.

      --
      "First they came for the slanderers and i said nothing."
    33. Re:If it's scary, then you don't know C. by Anonymous Coward · · Score: 0

      Nah dude, look, almost every language since 1980 has copied C syntax.

      What, you mean except for languages like Python and Ruby and Object Pascal and Visual Basic and Swift and so on?

      If it were a bad language, Java wouldn't have copied the syntax.

      You're trying to argue that C is a good language because Java uses curly braces? If C is a good language then why is Java more widely used than C?

    34. Re:If it's scary, then you don't know C. by dunkelfalke · · Score: 1

      Nah dude, look, almost every language since 1980 has copied C syntax. If it were a bad language, Java wouldn't have copied the syntax.

      "People, eat more shit. Billions of flies can't be wrong". Seriously, though, that was only done so people can feel a semblance of familiarity with the syntax. I personally can't stand C syntax, it is very awkward to type on any keyboard that differs from ANSI. All this letter salad is seriously uncomfortable on my German keyboards and even worse on keyboards meant for other languages.

      Also, "undefined behavior" isn't an ugly hack, it's just reality in language design. Every language has undefined behavior except a special few like ML.

      Yeah right, it's not a bug, it is a feature. That is a seriously weak excuse.

      C# has this specification: "A program that does not contain any occurrences of the unsafe modifier cannot exhibit any undefined behavior."
      Java also quite similar in this area (completely defined inside a single thread, multithreading may be non-deterministic).
      I develop for embedded systems that are in the field and aren't easily accessible if something goes wrong. Thanks to all those shitty quirks of C I have to program in an overly defensive way.
      If I had a say in it, I'd rather develop in Ada, but I haven't, so I had to spend two years converting old C code in modern, readable and much safer C++ code. The application is somewhat slower now, but much more stable and with half the amount of source code.

      --
      "It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
    35. Re:If it's scary, then you don't know C. by phantomfive · · Score: 1

      Yeah, I respect your loyalty to Ada, and I'm sorry you can't develop in it. The world would be better if you could.

      C# isn't completely defined. It has undefined behavior as well. It was so much effort to completely define ML that few people have wanted to go through the effort of completely defining a language since then.

      Also, since you are a better programmer than average, if you had spent two years converting old C to C, it still would have been much safer and more readable code. That is not because of the language, that is because of you.

      --
      "First they came for the slanderers and i said nothing."
    36. Re:If it's scary, then you don't know C. by Anonymous Coward · · Score: 0

      if you had spent two years converting old C to C, it still would have been much safer and more readable code.

      What a waste. Could have achieved the same thing in less time with better safety and readability in another language.

  9. Rust never sleeps by Anonymous Coward · · Score: 4, Funny

    This is a browser for Johnny Rotten

  10. I am all for it by Anonymous Coward · · Score: 4, Interesting

    I am all for it. I know there will appear a group of people here bragging how they are good programmers and never do memory bugs in C. Maybe it is true, maybe not. Still, show me even one bigger project written in C that never had any memory management related bug!

    In a bigger project, you will not have just have programmers belonging to this elite. You will also attract less skilled developers. This could partly be solved by having more peer-review, but the more peer-review you have of the code and the more checks you do before committing, the slower the development process becomes. And even high class projects with amazing history of C usage like, OpenBSD, occasionally have their bugs.

    My opinion is that it is better if the peer-review time and development time is spent on getting the algorithms correct rather than hunting around for memory handling issues.

    My biggest concern about this move is the state of Rust. It is still somewhat "unstable" as it is a young language with heavy development.

    1. Re:I am all for it by Anonymous Coward · · Score: 1

      Still, show me even one bigger project written in C that never had any memory management related bug!

      Show me one bigger project completely written in Rust.

    2. Re:I am all for it by Anonymous Coward · · Score: 0

      My opinion is that it is better if the peer-review time and development time is spent on getting the algorithms correct rather than hunting around for memory handling issues.

      In *my* opinion, not thinking about memory handling when designing algorithms is, almost always, an error in itself. YMMV.

    3. Re:I am all for it by Anonymous Coward · · Score: 0

      This is what I wanted to reply, you beat me to it.

    4. Re:I am all for it by Anonymous Coward · · Score: 0

      Rust looks like Objective C with some Pascal type casting (on globals) and Perl type sensing (on locals) tossed into the mix - a perfectly harmless ALGOL dialect.

    5. Re:I am all for it by Anonymous Coward · · Score: 0

      The release date for O'Reilly's Rust programming book keeps slipping. That should tell you something about the state of the language.

  11. Barrier of entry? by Anonymous Coward · · Score: 0

    The barrier of entry for contibuting to large OSS projects is high, but that is because those projects are large and complex, not because they are written in C. There is no shortage of C programmers and the language itself is simple. Moving to Rust will make the barrier of entry higher, not lower, since there are few programmers who know Rust or are willing to learn your favorite pet language of the week in order to submit a patch, regardless of its merits.

    1. Re:Barrier of entry? by ledow · · Score: 1

      I would actually think - given the privacy and security of the project in question - that you'd WANT the barrier to entry to be high.

      I'm not suggesting artificially raising the barrier, but if the people contributing don't understand type-safety, pointer-safety, etc. then does stripping all that out so they can contribute actually make better code? I would suggest that it actually achieves the opposite, long-term.

      That's not to say that C is the ideal language here, or that Rust is any better or worse, but in the same way that contributing to the engineering of a new space vehicle is difficult and subject to understanding a lot of fields, and only available to a handful of specialists, surely there is a factor of capability here.

      If they were having problems MANAGING the C code, that's reason enough to move everything to Rust. But having a high barrier of entry because you use C? That just sounds like they're dumbing-down because they're short of contributors - something that I wouldn't want to see in such a project.

    2. Re:Barrier of entry? by Tranzistors · · Score: 1

      I'm not suggesting artificially raising the barrier, but if the people contributing don't understand type-safety, pointer-safety, etc. then does stripping all that out so they can contribute actually make better code?

      Why would you assume that good pointer/type safety skills makes a “better programmer” in a situation where type/pointer safety is a non-issue? I don't see how a SQL script writer would benefit from understanding pointer arithmetic or tracking of resources.

      As for argument that this is an artificial barrier that would discourage “bad programmers” from even trying, a) rust has quite a steep learning curve and b) if need for understanding type safety was any deterrent, JavaScript would not be popular by any metric. It seems that enforced type safety is hostile to novices.

    3. Re:Barrier of entry? by DrXym · · Score: 1

      I'm not suggesting artificially raising the barrier, but if the people contributing don't understand type-safety, pointer-safety, etc. then does stripping all that out so they can contribute actually make better code? I would suggest that it actually achieves the opposite, long-term.

      It doesn't strip out type safety. It is a strongly typed language. In some ways more strongly typed than C or C++ because it doesn't allow you to cast things except some numeric types. What the language does allow you to do is skip the type declaration if the compiler can infer it from your code but it still enforces that type. So you couldn't assign a variable to be a bool or an int from two branches of a conditional for example.

      Pointer safety isn't an issue because you don't use pointers in safe programming. You can use a reference, a bit like in C++ but not a pointer. And the thing you hold a reference to is guaranteed to be there thanks to compiler lifetime checks. In a sense it forces the programmer to think more carefully about who creates and owns objects and their lifetime because they're not going to get past the compiler until they do.

      BTW Rust does support pointers and casting but you have to use them from explicit unsafe blocks. So if I absolutely knew some chunk of memory was a kind of type I could force the compiler to trust me. Likewise if I had to talk with a C-library which returned NULL or took NULL as an arg I can do that too. However Rust is safe by default..

    4. Re:Barrier of entry? by ThosLives · · Score: 1

      'Safe' vs 'unsafe' I think is the wrong dichotomy.

      Consider that the world actually needs 'unsafe' tools - for instance: knives, saws, fire. But what you want in tools like this is they always act in a nice deterministic way so, if you treat them with respect, you can obtain useful work from them.

      Code is essentially the same thing. What is necessary is the proper amount of respect for the damage your tools can inflict, not suggesting everyone to use safety scissors (except where it's appropriate of course).

      --
      "There are a dozen opinions on a matter until you know the truth. Then there is only one." - CS Lewis (paraprhase)
  12. Said my piece on Hacker Nudes by Anonymous Coward · · Score: 0

    Comes down to "we have a community of people who are excited to build it in Rust and that's that"

    So there it is.

  13. Is Rust really better? by Anonymous Coward · · Score: 0

    Every time someone says this is better than that it doesn't stay that way very long. Since Rust is new and pretty much running on Firefox and Tor and their cousins. Which is great but hardly catching on as replacing C++. Even if it does become popular, what's to say exploits won't be found in Rust considering that recent hacking competition had no trouble with Firefox. The other question is, will Rust even become popular other than with Firefox?

    1. Re:Is Rust really better? by Dagger2 · · Score: 1

      Of course exploits are going to be found in Rust code. It's not like it magically makes it impossible to write exploits. It's just that those exploits won't be memory safety bugs, buffer overruns or the like, because the Rust compiler rejects code with those. No point spending programmer time dealing with those when the compiler can handle it.

  14. FTFY by Anonymous Coward · · Score: 0

    > Also the barrier to entry for contributing to large OSS projects written in C is insanely high

    There, FTFY:

    > Also the barrier to entry for contributing to large projects is insanely high

    Programming is Hard. And Complex Systems are... uh Complex.

    Every language has its specific difficulties, and may be Rust is "better" than C in many respects (then maybe not, I just don't know, and I tend to distrust excited evangelists a bit).

    An old project always carries a considerable baggage of technical debt, so maybe Mozilla looks way better after having been rewritten to "whatever". I sure hope so. There are always risks, like shedding the old contributors (and therefore important knowledge) over a community-splitting design decision), second system syndrome and others. There are enough success stories out there, though.

    But assigning (nearly) all to the language choice is to me always a sign of inexperience.

    When growing a huge application, you're creating a big building of languages anyway: being aware of those and carefully managing their growth, their interaction and their teachability is much more important than the "base" language.

    As once a (Balinese) craftsman said to me "don't improve your tool: improve your craftsman" (OK, a bit extreme, but it does help to broaden the focus, doesn't it?)

  15. And does it work properly? by SCVonSteroids · · Score: 1

    Isn't that all that really matters? Who cares even if it's 100% written in binary code? (I mean my hat off to whomever would be fucking crazy enough to do something like that)

    Am I getting my point across?

    --
    I tend to rant.
  16. Compilable then I'll change... by Anonymous Coward · · Score: 0

    As I understand it, Rust is yet another language with arguably good features, but still runs on some sort of virtual machine, akin to a JVM.

    If the Rust creators made it so it wrote *native* code then I'd have more warm feelings. I don't care what's said about optimization. Until then, I'd rather use the devil you know JVM where I'm stuck with it.

    1. Re:Compilable then I'll change... by DrXym · · Score: 1

      Rust compiles to native machine code. Performance is comparable to C or C++.

  17. What about Rust's SJW culture? by Anonymous Coward · · Score: 0

    I've read that there is a strong feminist movement that is associated with Rust, and that just makes me think that the technical aspects of Rust will suffer.

    1. Re:What about Rust's SJW culture? by Anonymous Coward · · Score: 0

      What do you program in, COBOL?

      (Yeh, I know about Grace Hopper ;)

  18. Firefox is a project without a system engineer by Big+Smirk · · Score: 4, Insightful

    Is it so hard to write code that compiles with 0 errors and 0 warnings that will pass valgrind with with 0 warnings?

    Firefox (and by extension Tor) need to figure out why with 70+ threads they still have deadlocks. Perhaps they need a language that doesn't do threading?

    Actually I exaggerated, currently Firefox is only using 68 threads to display this page...

    Project without a _REAL_ system engineer?

    --
    TODO: create/find/steal funny sig.
    1. Re:Firefox is a project without a system engineer by gtall · · Score: 1

      This sounds like the same sort of mentality that gave us Java. Sun created Java in its own image, so it encouraged extra threads and creation of lots of objects because they figured it would run on big machines. They sold it though as something that would run everywhere. The threading and objects made it run like a dog on small machines.

    2. Re:Firefox is a project without a system engineer by Anonymous Coward · · Score: 1

      Wonder what you'll think about Chrome and Google when you realize it needs even more resources to do the same job without much benefit, and still with the same warnings, memory leaks, deadlocks and other crap that we know and love.

  19. Rust's implementation is buggy, buggy, buggy! by Anonymous Coward · · Score: 0

    For a language that's supposed to make it so much harder to write buggy code, Rust's implementation (which is written in Rust, like you point out) sure is buggy! Right now there are over 3,000 open issues and over 17,000 closed ones.

    If the people who developed the language itself, and who presumably know it best, can't even reliably use it to create bug-free code, how are normal programmers supposed to be able to?

    And don't waste our time trying to compare Rust's implementation to GCC by saying "But GCC has bugs, too!". GCC is massive compared to Rust. It includes front-ends for numerous languages (C, C++, Objective-C, Objective-C++, Fortran, Ada, and Java, among others), plus numerous back-ends for a variety of platforms, plus a lot of other code. Rust is tiny in comparison. It's just a simple compiler front end for one language, and a limited standard library.

    Ignoring the bug problem, it's not like Rust has helped the Rust developers themselves develop their product faster, either. Rust 1.0 was very much delayed. It isn't just the Rust implementation that was affected by this. Servo, which is also developed by Moz://a and which features some of the same people who are working on Rust, is taking forever to product something usable. Even IE 3 gives a better experience at this point.

    When we look at the evidence, Rust doesn't fare well at all. It just doesn't live up to the hype. It doesn't help avoid bugs. It doesn't increase programmer productivity. It puts you through a lot of pain for no gain.

    1. Re:Rust's implementation is buggy, buggy, buggy! by Anonymous Coward · · Score: 0

      It's a young language still. Most of the bugs are feature requests, TODO's, clarifications, or weird source code that triggers an assertion in the compiler.

      These are more fair lists of very real problems:

      https://github.com/rust-lang/rust/labels/I-unsound
      https://github.com/rust-lang/rust/labels/I-crash

      As long as you don't run into these and don't shoot yourself in the foot with unsafe or C bindings you will never get a segfault in Rust.

      The rest of your post appears to be complaining that creating a new programming language and HTML renderer is a lot of work. Well, duh.

  20. Can somebody mod down ljw1004's disinformation? by Anonymous Coward · · Score: 2, Informative

    I'd expect a good developer, who's already familiar with other languages, to be contributing good PRs in Rust within a day.

    This is not true at all.

    Can somebody please mod down ljw1004's disinformation? I don't think he's ever even used Rust. Anybody who has actually used it would never make the claim that he just made.

    Rust is not an easy language to learn.

    Even people with extensive academic experience, years of industry experience, and an excellent understanding of a complex language like C++ will find Rust's learning curve to be steep. "Lesser" programmers will have a much, much more difficult time with it.

    Based on my experience and that of a number of very experienced and skilled programmers that I know, it would take at minimum of 2 weeks for a talented programmer to become barely proficient with it. Two or three months is a more reasonable time frame for an average programmer.

    Rust is not a language like Java, C#, Python, or Go, where a good C++ programmer can be writing high-quality code within a few days. It's much more like Haskell, where even experienced practitioners need a lot of time (measured in weeks or months) to truly understand its concepts and nuances.

    Anyone who claims that Rust can be learned well "within a day" is full of bullshit.

  21. Reflections on Trusting Rust by tepples · · Score: 1

    A language with only one compiler written in that selfsame language can't be trusted very easily because all available binaries might have trojans that self-replicate using the technique that Ken Thompson demonstrated in "Reflections on Trusting Trust". The usual way to detect a "Trusting Trust" trojan is David A. Wheeler's diverse double-compiling, which starts by bootstrapping a compiler's source code on three independent implementations of a language and seeing if the process of compiling a compiler with itself converges to identical binaries. But you can't do DDC if the only available Rust compiler is written in Rust. Sure, you can use OCaml to compile the old Rust frontend and use old Rust to compile the new Rust frontend, but then you'd need multiple independent OCaml compilers so that it can be verified using DDC.

    1. Re:Reflections on Trusting Rust by DrXym · · Score: 1
      The same could be said for gcc, clang or a bunch of other non-C++ languages. Most toolchains are produced by compiling themselves with previous iterations. Yes, perhaps you could potentially devise a test to prove that gcc wasn't doing something nefarious by comparing the output of gcc compiled with gcc to gcc compiled with evilcc but does that happen? And even if it happens for gcc, does it happen for every language that forms part of a modern distribution.

      That said I think it would be beneficial to see another implementation of Rust. A single impl does increase the risk of allowing problems to slip through and a separate impl could catch some problems. At the end of the day the two should be interchangeable.

    2. Re:Reflections on Trusting Rust by tepples · · Score: 1

      The same could be said for gcc, clang

      No it can't because there are multiple independent implementations of C++ available to the public. A licensee of Microsoft and Intel C++ can use those, Clang, and GCC for a four-way DDC test to ensure that the resulting Clang or GCC executable is free of self-replicating binary trojans.

      or a bunch of other non-C++ languages. [...] And even if it happens for gcc, does it happen for every language that forms part of a modern distribution.

      If the compiler for a non-C++ language is written in C++ or another language supported by GCC, you can do due diligence on GCC and then use that trojan-free executable as the first step in making reproducible builds of toolchains for the other languages. Building CPython with a GCC executable that is free of trojans, for example, will produce a Python interpreter free of trojans.

      but does that happen?

      Some of the more privacy-paranoid projects are taking serious effort to ensure reproducible builds, and this starts with due diligence on the executables in the toolchain.

  22. Shitty Programmers by Anonymous Coward · · Score: 0

    Sure it's safer, for idiots that don't know how to code in the first place.

  23. Do you hear that? by gerald.edward.butler · · Score: 1

    Better duck. That whooshing sound is loud!

  24. Why not actually research before commenting? by gerald.edward.butler · · Score: 1

    You wouldn't look like a fool if you bothered to read up on Rust before commenting on it. Your understanding is completely erroneous.

  25. Fewer, Not Less by Anonymous Coward · · Score: 0

    "...which means less memory corruption errors. Less of these errors means better privacy for all."

    I think you meant: "...which means fewer memory corruption errors. Fewer of these errors means better privacy for all."

    There. Fixed.

  26. There is a second rust compiler! by Anonymous Coward · · Score: 0

    mrustcc or something. Look it up on github.

    *HOWEVER* the problem, based on what I've read, is that a 'blessed' compiler is needed, which is signed by each successive compiler in the chain (in 'mozilla' rust's case, this was first the ocaml version as a bootstrap in a now incompatible version of rust, then a series of further incompatible rust compilers that were self-hosting in the interim, and now the current rust compiler binary required to bootstrap current rust versions.)

    This is the same concern I have with ada, or I would just use that instead! The only serious non-commercial compiler available is GNAT and in order to trust it you have to trust *EVERY BINARY* used to compile it in the past 20+ years to not have inserted something malicious, or even just a mundane and difficult to verify output code bug.

    IMHO having a self hosting compiler is fine, but having a bootstrap compiler that can be compiled up from a C toolchain (meaning whatever language its prereq compiler is in, it can be bootstrapped from C, as a lowest common denominator compiler option) Do this and you can verify up to the current compiler version. Claim a user has to just 'trust us' and use a binary bootstrap, because the alternative is compiling 15-30 old revisions to get up to a compiler written in the modern language, and you're just being ludicrious. Rust isn't safe until the compiler can be audited, and even then without a second source compiler, trust issues will remain.

  27. for real people by Anonymous Coward · · Score: 0

    For a real people, "Isis Agora Lovecruft" sure sounds like a fake name.