Implications of Rewriting a Browser Component in Rust • Hacker News Board

Re: Implications of Rewriting a Browser Component in Rust

#211

Post by steveklabnik » Fri, Mar 01, 2019, 6:00 AM UTC

steveklabnik wrote: post #42

Thaxll wrote: post #41

Earlier quoted context omitted.

Chucklefish made some buzz few month ago saying they were writting there new game in Rust, they now stopped and went back to C++. https://www.reddit.com/r/programming/comments/atyzz4/halley_...

They're still using Rust for some stuff, just not for the game itself. Wargroove's matchmaking server is still in Rust. That said, yes, this is a good example of what your parent is asking for. https://www.reddit.com/r/programming/comments/atyzz4/halley_... has some more context too

Even more context: https://www.reddit.com/r/rust/comments/avwxq1/comment/ehijdw...

Re: Implications of Rewriting a Browser Component in Rust

#212

Post by ahartmetz » Fri, Mar 01, 2019, 6:02 AM UTC

ianlevesque wrote: post #40

mrath wrote: post #2

I primarily use Java for my job. Security and memory related features of Rust are not an advantage compared to Java. But I like rust because it feels modern and produces efficient standalone binaries. Most of my hobby projects are in Rust now. But I would not rewrite any of my work projects in Rust even though they require ultimate performance. That would be a maintenance burden. It is great to see people rewriting i…

I use Java constantly in my job and recently tried rewriting a math & memory heavy component in rust to see what performance gains there might be. Surprisingly (to me) the naive rust version was ~15% slower than Java. There’s probably room for more rust optimization but it was interesting that “efficient standalone binaries” doesn’t automatically mean faster too when competing with HotSpot.

I remember reading an article about Java performance many years ago. It had an example for Java being faster than C++ and it was maths on arrays / matrices. I guess that kind of code least trips up HotSpot optimizations, so it wins due to availability of runtime information and a really good implementation of certain parts.

Though I doubt that Java usually wins against the Eigen C++ library. Eigen uses some template tricks to fold operations together (which can avoid intermediate storage and unlocks more types of restructuring optimizations) and uses SIMD extensively.

Re: Implications of Rewriting a Browser Component in Rust

#213

Post by pjmlp » Fri, Mar 01, 2019, 6:04 AM UTC

int_19h wrote: post #194

johnisgood wrote: post #126

Earlier quoted context omitted.

No, I was really curious. My bad if it looked like I was trying to lecture. I do not think that I have the necessary knowledge in this topic to do that. :) > a borrow checker What exactly do you mean? How does it differ from any other language's type system? > would also catch all data races at compile time In Ada/SPARK, you can formally verify tasks, too. Please take a look at https://docs.adacore.com/spark2014-docs…

Can you recommend a good book on SPARK in general? I've read one on Ada 2012 itself, and what it had to say about Ravenscar and SPARK got me interested.

"Building High Integrity Applications with SPARK"

There is also "High Integrity Software: The SPARK Approach to Safety and Security", I never read it, but it is written by a well known author in the Ada community.

Re: Implications of Rewriting a Browser Component in Rust

#214

Post by pjmlp » Fri, Mar 01, 2019, 6:07 AM UTC

Yoric wrote: post #142

johnisgood wrote: post #124

Earlier quoted context omitted.

I was responding to the issue I quoted, which really is just a matter of using a programming language with static typing. :) > some of which aren’t solved by other languages You only mentioned null pointers, so I will go with that. In Ada, you can have access types (pointers) that are guaranteed to not be null, and accessibility rules of Ada prevent dangling references to declared objects or data that no longer exist…

I will give you a few examples. My knowledge of Ada is insufficient, so I'll let you tell me whether Ada can solve that without using an external prover (note: being able to use an external prover is great and I haven't seen this done in Rust yet :) – but that's not the topic at hand). 1/ Consider a file `f` (or a socket, etc.). Using the standard library, Rust will statically ensure that, once the file is closed, yo…

SPARK is a subset of Ada 2012.

Your examples are possible with contracts.

Re: Implications of Rewriting a Browser Component in Rust

#215

Post by pjmlp » Fri, Mar 01, 2019, 6:10 AM UTC

galangalalgol wrote: post #189

henrikeh wrote: post #137

Earlier quoted context omitted.

>> [...] solves the same problems without a runtime, and about 3 times the performance. I think you should look more into Ada. The only "runtime" is for the exception handling and bounds checking, both of which can be turned off if needed. And I don't know where you got that "3 times" figure from? Do you have an example you are referring to?

I knew you could turn off the runtime but not about the formal verification lint tools that make it safe to do so. My reference for performance is the benchmark game. If you or someone else can mod those programs to beat rust I'd be thrilled. I like Ada.

Many planes, trains, rockets and medical devices run on Ada.

There is more to commercial compilers than winning the benchmarks game.

Re: Implications of Rewriting a Browser Component in Rust

#216

Post by masklinn » Fri, Mar 01, 2019, 6:55 AM UTC

int_19h wrote: post #193

masklinn wrote: post #128

Earlier quoted context omitted.

Except Rust's [] behaves like C++'s at (checks and aborts). C++'s [] is called `get_unchecked`.

C++ at() doesn't check and abort, it checks and throws a specific documented exception that you can catch. So it is, in fact, closer to get(), just using a very inefficient way of reporting.

> C++ at() doesn't check and abort, it checks and throws a specific documented exception that you can catch. So it is, in fact, closer to get(), just using a very inefficient way of reporting.

You can catch a panic, and you can compile C++ with -fno-exception. at() is not closer to get() than to [].

Re: Implications of Rewriting a Browser Component in Rust

#217

Post by masklinn » Fri, Mar 01, 2019, 6:56 AM UTC

barrkel wrote: post #177

masklinn wrote: post #117

Earlier quoted context omitted.

The "but" is where all the difference lies though, Result (or Either or whatever you want to call it) is the reification of the sum of a return value and an error, and as such manipulable without having to add dedicated tooling… (which java didn't have either, and still does not). Amongst other issues it's possible to pipe one through a generic wrapper without that wrapper having to care about it. e.g. let's say you…

Lack of parameterisation of exception signature is not the reason why checked exceptions are a bad idea, though. Failure is a function of implementation details; runtime errors are fundamentally an abstraction violation. There's no escape.

> Lack of parameterisation of exception signature is not the reason why checked exceptions are a bad idea

It absolutely is one of the reasons why they are a bad idea, and why reified results are so much more useable and useful.

> Failure is a function of implementation details

In the original intention, that's what unchecked exceptions were for, with checked exceptions for the reporting of errors rather than failure. That's why java didn't have only checked exceptions.

Re: Implications of Rewriting a Browser Component in Rust

#218

Post by woolvalley » Fri, Mar 01, 2019, 6:57 AM UTC

rwmj wrote: post #191

woolvalley wrote: post #190

Earlier quoted context omitted.

From my friends that have tried rust, creating a graph or doubly linked list without using some special structures is fairly painful or impossible. You can create a graph by using some sort of adjacency matrix or some other kind of structure that keeps ownership in some sort of tree without much pain, but that has it's own downsides.

This was also my experience. It's a fine language if you can't (or more usually "won't" for spurious reasons) use a garbage collector. However a lot of things are just easier to do using a GC, and I suspect in many, not all, of the use cases of Rust, a GC would be just fine. (Also I have to rant here a bit: Yes I know the GC you used in Java or Emacs in 1997 was terrible, but modern GCs are very good indeed)

Graphs are OK in reference counting languages like swift / objective-c, it doesn't have to be done with a GC.

I think you could use Rc in rust too if you want to solve it using rust, but then you have "swift with more boilerplate" as one friend said.

Re: Implications of Rewriting a Browser Component in Rust

#219

Post by masklinn » Fri, Mar 01, 2019, 7:01 AM UTC

barrkel wrote: post #183

neel_k wrote: post #149

Earlier quoted context omitted.

Semantically, returning a sum type like Result absolutely is the same thing as exceptions (ie, it's the exception monad). However, there's one very important language design difference between this and Java-styled checked exceptions: using sum type gives you effect polymorphism for free. This means you can write (say) a map function which says it has precisely the same exception type of its argument function, using t…

No, lack of static parameterization of the representation of failure is not the problem with checked exceptions. In fact the prison of being forced to construct a tunnel in the (static) type system to carry your error information, irrespective of how dynamic it becomes, is the torture that kills the idea. Errors are fundamentally the leaks in abstractions. They betray the implementation. The network error that makes…

> The network error that makes a mockery of pretending something is local. […] I'm in favour of error values for functions that return errors in normal circumstances.

Checked exceptions were intended for the latter, and unchecked exceptions for the latter.

Re: Implications of Rewriting a Browser Component in Rust

#220

Post by pjmlp » Fri, Mar 01, 2019, 7:29 AM UTC

masklinn wrote: post #216

int_19h wrote: post #193

Earlier quoted context omitted.

C++ at() doesn't check and abort, it checks and throws a specific documented exception that you can catch. So it is, in fact, closer to get(), just using a very inefficient way of reporting.

> C++ at() doesn't check and abort, it checks and throws a specific documented exception that you can catch. So it is, in fact, closer to get(), just using a very inefficient way of reporting. You can catch a panic, and you can compile C++ with -fno-exception. at() is not closer to get() than to [].

If you do that, you will be invoking nasal daemons, as at() is required by ISO C++ to throw.