Mozilla's Servo Has Been Picking Up A Number Of WebGL Improvements

[ssokolow]

The problem in both cases is, the 'function' that deals with the data doesn't handle totality. These safer languages provide more tools to achieve that. Apparently you're not familiar with theorem proving languages. There you must react to negative values too.

I'm familiar with theorem-proving languages. They get mentioned periodically in /r/rust/. They're just not practical for the kinds of "quick Python script, but more robust" use cases I tend to turn to Rust for.

[silmeth]

I don't think anyone is claiming Rust will make something bugfree. What it's supposed to do is prevent memory leaks, buffer overruns, and user-after-free errors without adding any runtime performance or memory overhead.

Actually it does not prevent memory leaks, because that’s wasting resource, but in a safe way – you are free to leak as much memory as you wish by eg. creating cycles of counted references.

What it does prevent is uninitialized memory usage, double-frees, null pointer usage, etc. And it does prevent most kinds of memory leaks by automatically freeing things whose owner goes out of scope. And its type system allows one to enforce a lot of invariants in the APIs (guaranteeing that if a program compiles, the library’s API is used correctly), but of course one can also create a C-like library providing completely unsafe API.

It isn't. Certain crashes are even expected, since that's better than having security issues silently creep around. And since e10s it should only crash a content process anyways.

I think there is a misconception about Rust preventing crashes, because people tend to equal crashes and segfaults. Rust (or the safe subset thereof) is supposed to prevent segfaults (as it prevents memory errors) – so if one encounters a segfault in a Rust application that is either in unsafe code, in an external dependency, or a result of a compiler bug.

Rust of course does not prevent any controlled crashes – you can easily crash your application by using the panic! macro, unwrap() on a Result type, etc. In situations where the programmer made some wrong assumption about input format, network connectivity, etc. and explicitly coded the program to exit with non-0 status code, ie. crash, if their assumptions are not met, the application will crash when its user finds input that does not meet those assumptions.

[Azrael5]

When these new features will be implemented? which firefox release will get them?

[Pajn]

I don't see how the programming language Rust alone is supposed to guarantee bugfree software.

It doesn't. That's literally impossible.
What it does guarantee is safety and particularly memory safety as C++ is incredibly bad for that.

Rust never guaranteed that. It is a language that makes it easier to write multi-threaded code, that's all.

It does far more than help with multi-threaded programming but it isn't magic so it can't guarantee bugfree software but it does guarantee that some classes of bugs can't happen.

And while it's not guaranteed, Rust programs very seldom crashes unless the programmer itself writes a panic just because it does not allow null pointers, does not support exceptions and never segfaults.

[caligula]

You can create an infinite loop in any langauge. Same with some other bugs. What rust does it eliminate <i>some</i> bug types.

This isn't sufficient for the Rust haters. If you can only eliminate 950 of 1000 bugs, they won't switch. You need to eliminate 1001 or more.

[caligula]

I'm familiar with theorem-proving languages. They get mentioned periodically in /r/rust/. They're just not practical for the kinds of "quick Python script, but more robust" use cases I tend to turn to Rust for.

I just replied to your complaints. If you know theorem proving and the concept of total functions, it should be obvious to you what Rust can solve and how to get there. Rust is a practical language that tries to not get in your way all the time. It provides some safety nets, but in order to protect your application, you need to know how to apply types. Even a C programmer needs to know what's the difference between 8 and 32 bit types or the fact that a null pointer is a special pointer with platform/vendor dependent magic value. If you consider all these basic rules, it's much easier to produce robust code. Apparently a Rust coder incapable of handling UTF-8 input does not know / care how to use the language.

[caligula]

In my opinion, there isn't much Rust can offer compared to C++/Java in terms of solving hard problems.

That's probably true, but its type system, macros, and borrow checker can do things those languages can't. So, obviously it's a more capable in some ways. Having too many features is also bad.

[onicsis]

Even a perfect language can't STOP Mozilla to take bad decisions related to design to dumbing down UX, by oversimplification to much of user interface. It's not rust the problem here, maybe it's a bit to complicated compared to C or C++, but actually it's OK as programming language. An better integrated interactive debugger for analysis of crashed (core dumps) will be an ideal software tool, compared, this compared cu classic debuggers like gdb. I mean an whole SDK for investigation various thing like performance , memory/resource leaks detection, operating system load, profiling etc

[wswartzendruber]

In my opinion, there isn't much Rust can offer compared to C++/Java in terms of solving hard problems.

It has the safety of Java with the speed of C++. And it's type system is powerful. Insanely powerful.

[ssokolow]

I just replied to your complaints. If you know theorem proving and the concept of total functions, it should be obvious to you what Rust can solve and how to get there. Rust is a practical language that tries to not get in your way all the time. It provides some safety nets, but in order to protect your application, you need to know how to apply types. Even a C programmer needs to know what's the difference between 8 and 32 bit types or the fact that a null pointer is a special pointer with platform/vendor dependent magic value. If you consider all these basic rules, it's much easier to produce robust code. Apparently a Rust coder incapable of handling UTF-8 input does not know / care how to use the language.

What made you think I was incapable of handling UTF-8 input?

My problem is that, if you derive(Serialize,Deserialize)on a struct which happens to contain a PathBuf, serde_json just naively assumes that the underlying OsString will contain only characters which are valid in a String and the docs make no mention that using derive in such a situation opts you into a not-inherently-exploitable version of the same kind of "design optimism" as gets(3).

Now that I know Serde's developers aren't as rigorous about this sort of thing as I am, I'll be testing such edge cases every time I need to serialize a new type so I can catch these sorts of flaws earlier in the development process than full-scale integration testing on a near-complete program.