Well, IMHO, "the right hammer for the right nail". Rust is a great systems language (besides the lack of bitfields) but I wouldn't use it as a web language. Just as much as I wouldn't use C++ to develop webapps. Sure you can do it but then again there are far easier ways to achieve your goal.
Some would say Scala is not a "web language" either, but I think Play Framework developers would disagree. The rules of the game are not as clear as they used to be. For instance - web frontend is being dominated by JS frameworks and all the backend does is handling REST calls. I would argue that when you need scalability/performance/reliability, when milliseconds start to count - static languages make very much sens…
Writing a website in Rust
91–100 of 141 posts
Re: Writing a website in Rust
#92Earlier quoted context omitted.
Super fast? More like Java ballpark: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
We've been focused more on language semantics than the Benchmarks Game for a while now. A few months ago, iirc, we were faster than C on some of them.
A couple of weeks ago you said -- "… optimizing performance hasn't been a focus, shipping good language semantics has been."
https://news.ycombinator.com/item?id=9565405
edit: Please provide a better response than downmods.
Re: Writing a website in Rust
#93Earlier quoted context omitted.
The benchmarks game 's results are not very correlated with real-world performance. In this context, Rust's semantics do allow C-level performance- they make it straightforward to describe the same machine code that C would. In some cases, they even enable more compiler optimizations than C does. Java, on the other hand, makes it hard or impossible to do that (straightforwardly at least). A more mature compiler will…
>>not very correlated with real-world performance Please share your measurements of "real-world performance" that are "not very correlated" with the benchmarks game's results. edit: Please provide a better response than downmods.
Re: Writing a website in Rust
#94Earlier quoted context omitted.
We've been focused more on language semantics than the Benchmarks Game for a while now. A few months ago, iirc, we were faster than C on some of them.
Let's not make this about the benchmarks game. A couple of weeks ago you said -- "… optimizing performance hasn't been a focus, shipping good language semantics has been." https://news.ycombinator.com/item?id=9565405 edit: Please provide a better response than downmods.
Optimizing the workloads tested on the benchmarks game has not been a focus.
Re: Writing a website in Rust
#95Very nice write up. As a Go programmer, Rust is really interesting. Can't wait until you can build web APIs with it.
Recently where I work we switched to Golang for any network facing daemons and it's been awesome. Rust was decided as 'too alpha' to try yet.
Re: Writing a website in Rust
#96The tooling for the web written in JavaScript is excellent, so I was curious, are there any options there are for calling JavaScript from Rust code? I know there is the ffi module for NodeJS that allows you to call Rust from JavaScript, but I was wondering if there is something that works well in the other direction.
There are two libraries that embed V8 in Rust, but all of them seem to be abandoned for now. However if there become enough interests, a new project will arise I think.
(FWIW, I ended up calling CommonMark library written in Python from Rust, because embedding CPython was easier than embedding V8. Unfortunately CPython's performance is worse than V8, but as I know Python better than JavaScript it was a reasonable choice.)
Re: Writing a website in Rust
#97Earlier quoted context omitted.
>>not very correlated with real-world performance Please share your measurements of "real-world performance" that are "not very correlated" with the benchmarks game's results. edit: Please provide a better response than downmods.
Servo layout, painting, DOM performance. JSON serialization in serde.
edit: Please provide a better response than downmods.
Re: Writing a website in Rust
#98Earlier quoted context omitted.
Out of curiosity (I've never done systems programming), what are some of the things that make a language more suited to systems programming rather than web (other than libraries and community support - I'm more interested in the intrinsic qualities of the language)?
For Prometheus's console templates (basically offering a html templating engine to end users to create monitoring consoles with), I used Go's own templating language as nothing else seemed mature at the time. Go is strongly typed, and so is it's templating language. This means that you need to take a much more rigorous approach to using them, as a single unhandled edge case value can break the entire page. Contrast t…
Do you have some examples of error that are easy to make with Jinja2? I personally find it to be a thing of beauty, but it's possible that I don't try to make very elaborate things with templating engines and thus might be missing out.
Re: Writing a website in Rust
#99Earlier quoted context omitted.
Let's not make this about the benchmarks game. A couple of weeks ago you said -- "… optimizing performance hasn't been a focus, shipping good language semantics has been." https://news.ycombinator.com/item?id=9565405 edit: Please provide a better response than downmods.
Optimizing language performance has been a focus. Optimizing the workloads tested on the benchmarks game has not been a focus.
https://news.ycombinator.com/item?id=9554676
edit: Please provide a better response than downmods.
Re: Writing a website in Rust
#100> Another bad part is Rust’s JSON handling. It badly needs macros which make things easier.
Actually this is not the end of the world. As you mentioned, Rust's JSON library supports `ToJson` for primitive types, but also provides compile-time code generation for arbitrary `struct`s. Quoting the code from my project:[1]
#[derive(RustcDecodable, RustcEncodable)]
struct Msg {
cmd: String,
id: i32,
x: Option,
y: Option,
speed: Option,
}
What the mystical `#[derive]` thing does is to direct the compiler to create the boilerplate for converting the `struct` to/from a string automatically. So, now you can do this: // Decoding a JSON string
let text = r#"{"cmd": "move", "x": 5, "y": 10, "speed": 200}"#;
let decoded: Msg = json::decode(text);
// Encoding a Msg object to JSON
let msg = Msg { cmd: "new", x: 10, y: 20 };
let encoded = json::encode(msg);
The `Msg` struct is full of `Option`s because my project allowed many fields to be missing, but if the JSON messages in your protocol are in fairly similar format, you can eliminate most of them.One more benefit of this approach is that it type checks. If the JSON you received is missing some fields that are not defined as `Option`, the decoding process produces an error! So you can be certain that you're handling a valid JSON after the decoding stage. This is analogous to schemaless vs. schema-enforced database design.
> Compared to many static languages, the handlers look tidy. Compared to dynamic languages, they’re terrible.
This is the property of the Iron framework, not of the Rust language itself! Another web framework for Rust, namely Nickel.rs[2], provides much simpler APIs.
I believe the author of Iron is trying to establish essential things first, and build more "user friendly" APIs on top of them. (FWIW, the Rust project itself follows the similar strategy.)
[1] https://github.com/barosl/pgr21-online-server/blob/master/sr...