Hacker News Reader

Comment by hit8run | Hacker News Reader

Hey Tom, did you also consider googles golang? Currently I'm building my backends with golang and I am pretty satisfied with the performance and the whole flow. Maybe it is sometimes a bit cumbersome to check on errors like a paranoid but in the long term it helps to predict what happens in error cases. How about rust? Is the workflow comparable to golang? Is there an equivalent to gofmt and some ide support for code completion? Thx and regards Bijan

View on HN

I don't speak for tomdale/wycats, but embedding a language with a GC (Go) inside another GC'd language (Ruby) only leads to worlds of pain, especially when trying to efficiently transfer data between them.

In languages without compulsory GCs (like Rust, which doesn't have one at all) this works because it's easy to have complete control about when memory is freed, but a GC'd language may free memory that was passed back into Ruby since the GC can no longer find any references to it.

I'm sure there's ways around this (e.g. using unsafe/raw pointers), but this control is the default in Rust, and there are a pile of language mechanisms (ownership, in particular) that make making this safe much easier.

(Also, AIUI, Go's FFI story is relatively inefficient, and, has some rather bad bugs; apparently https://code.google.com/p/go/issues/detail?id=7978 is the Go GC trying to free FFI memory.)

From what I understood, it's a Rust agent communicating protobuf structs over IPC, not embedded into the gem.

In such a case, memory safety and GC is less of an issue.

Memory safety is still good for long term code maintenance and refactorability. wycats also mentions that these processes are reasonably long lived - memory leaks can become a big problem over time if you are not careful. These can be mostly purged by static analysis and Valgrind, but are still a headache to deal with. I would also add that Rust is much easier to hack on safely if you don't have a great deal of prior systems programming experience.

I believe there is a Rust library embedded in the gem to serialize and communicate with the outside agent (IIRC, this is actually the most important part to be in Rust, it needs to be efficient to avoid interfering with the normal operation of the main program as much as possible).

I've never looked at it too closely, but wycats has talked about how the Ruby code calls Rust code through the FFI and how Skylight doing some special things to make that work especially smoothly by directly calling some internal functions of Rust's failure handling bits, and about how the Rust code crashing shouldn't take down the rails process. That seems to suggest it's not just an IPC thing.

Actually, that Go bug is the scanning code getting confused about an incorrectly stored stack pointer value during a very small race between returning from a FFI call into Go and generating a traceback for scanning. I'm not familiar enough with the internals to comment on if that can lead to freeing FFI memory, but I don't think so. Not that crashing the process is much better. :)

There are some work-in-progress code completion tools https://github.com/phildawes/racer).

No format tool yet, but its often talked about and Id be surprised if it doesnt happen.

The biggest infrastructure difference to go at the moment is that its tricky to cross compile binaries in rust.

From time to time I use "rustc --pretty normal <file.rs>". Not a real formatting tool, and it has a tendency to produce some funny results at times, but it's better than nothing.

Reply on news.ycombinator.com