3 ms·

In my very uninformed, and novice opinion, which you should entirely disregard, it is my probably incorrect estimation that the Rust developers are in maybe ove

• rjbwork 13y ago
  > And worse of all in their mozilla IRC channel those guys said writing such things should be left to experts, that people should always use the C libraries with rust. >It's true security features should be vetted, and cryptography requires expertise, but on the other hand look at Go. They wrote a lot of their own cryptography code in go, and it seems to work pretty damn well. The issue here is that people who try to roll their own cryptography solution fail at it and introduce insecurities on their own almost all of the time. Think about the amount of bugs in any reasonably complex solution that the layman comes up with. Now imagine what happens when you set the layman off to implement a solution to a problem already solved by experts that can totally destroy your business if not written perfectly. If we wrote our own cryptographic algorithms for HIPAA compliance where I'm at, I'm pretty sure we'd eventually have to shut down the company due to mass violations due to improperly implemented complex algorithms.
• fauigerzigerk 13y ago
  I haven't made up my mind yet about whether or not I find Rust's memory management ideas convoluted. But the Rust people seem to be the only ones working on this important problem at all and contributing some innovative ideas. Looking at this long list of programming languages, I see two approaches used by the vast majority of popular implementations: Conventional tracing garbage collectors that cause pauses up to minutes, and naive reference counting which is slow, concurrency hostile and error prone. Obviously, don't know every implementation of every language on the list. So please tell me I'm wrong. I would love to be!
• portmanteaufu 13y ago
  I can't speak to the reference counting and garbage collection libraries (which are likely the items to which you are mainly referring), but I found Rust's approach to the more mundane memory management scenarios to be enormously refreshing. When writing Rust, you simply tag those variables that the current thread of execution is responsible for free()ing when they go out of scope. The compiler enforces correctness and can tell when you've tried to use a variable that's no longer available. There's no such thing as an invalid memory reference and so long as you avoid using a GC library, there's no overhead whatsoever. When the compiler's happy, you can rest assured that your program is free from entire classes of subtle bugs that can lie in wait for years before you get your first segfault. The Rust team has admittedly put very little time into optimizations at this stage. However, Rust's manual memory management combined with LLVM's existing optimizations have put its performance on par with C in several (simple) benchmarks. In others, it can be found somewhere between C and Go. That's quite a feat for so young a language. Forgive my gushing. I'm very excited to finally have C speed and high level language features without segfaults.
• pcwalton 13y ago
  > The multiple ways to manage memory seem completely messy to me, the various ways to box values and what not and what the implications are. It's not pretty, it's not elegant, but then sometimes things aren't. I'm complaining about prettiness over usefulness somewhere else in this thread. But the box memory model thing left me feeling like it was a convoluted solution that could end up in confusion. Rust is also the only industry language I'm aware of that gives you memory safety without garbage collection. We have some changes in the works to reduce the cognitive burden of the pointer types before 1.0 (most notably putting GC in the library). If you firmly believe either (a) memory safety is not worth it or (b) garbage collection is superior to manual memory management in all circumstances, then Rust is not for you. That's fine! I don't want Rust to be the end-all-be-all language for all projects, and I love language diversity. But it's precisely this feature—low-level, runtimeless programming without segfaults or memory-related security vulnerabilities—that makes a lot of people interested in Rust. > No SSL stuff. Not much encryption stuff. And worse of all in their mozilla IRC channel those guys said writing such things should be left to experts, that people should always use the C libraries with rust. The opinion of the security community, including tptacek on Twitter, has been unanimously in favor of this decision. We consulted with our security team before deciding this. There is literally no reason to write security code in Rust, except for memory safety; the FFI in Rust is extremely well-integrated and you can call C code like it's Rust code (in fact, there's even work being done to optimize across C and Rust!) > Being able to make HTTPS requests would be a pretty important feature for a browser like Servo I'd think. Servo will be able to do HTTPS requests, of course. The plan is to do it via NSS. > The pace of development. Given the state of the network io library, the many packages required to get to a useful state, it seems like it's going to be about a decade or so before Rust is even usable. The fact that it requires several packages to get useful things working is a deliberate design decision. Rust's philosophy is small, composable modules—it's like Node in this regard. We don't have SSL yet, and the I/O needs work, but the new scheduler, which involved a complete rewrite of the entire I/O subsystem, is literally 3 months old. I don't see how you can extrapolate from that to the idea that it'll take 10 years to make an SSL connection.
  • captainmuon 13y ago
    > Rust is also the only industry language I'm aware of that gives you memory safety without garbage collection. Python uses refcounting, and has a GC only for cycle breaking. You can turn it off in many cases and have deterministic behavior. Among compiled languages, Vala has no GC but safe references. It uses refcounting, too, but AFAIK also deduces when an object will not leak out of the scope (and thus the refcounting can be elided). But Vala is also somewhat a niche language, constructed around the GObject/Gtk object model. That being said, the way rust handles memory looks really interesting. I definitely have to try it out these days.
• WalterBright 13y ago
  > No SSL stuff. Not much encryption stuff. And worse of all in their mozilla IRC channel those guys said writing such things should be left to experts, that people should always use the C libraries with rust. Over in D language land, we've actively discouraged people from rolling their own encryption libraries. We strongly recommend people use standard, vetted libraries like openssl if they are serious about needing encryption. D can interface directly to C libraries. I don't see it as a language issue at all. It's more like there are so many subtle issues with doing encryption right that one should be standing on the shoulders of giants rather than starting over.