Live data from Hacker News

Writing a website in Rust

blog.viraptor.info

81–90 of 141 posts

Re: Writing a website in Rust

#81

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.

Bitfields are evil...the fact that the language designer left them out signals he/they have good taste...I have to get around to trying out Rust.

No, ill-defined non-portable C bitfields are evil.

If you can specify bit endianness, byte endianness, spans of bytes, and so on... bitfields are mighty nice.

Re: Writing a website in Rust

#82
post #72

Earlier quoted context omitted.

Crates.io is built this way: Rust serving JSON on the back end, Ember consuming it on the front end.

How mature could this setup be considered? Thanks for pointing it out.

As mature as anything for a language which just hit 1.0. Alex, the main developer, said he likes it a lot. https://m.reddit.com/r/rust/comments/2v1fe3/hows_rust_workin...

I think it's a pretty good architecture overall. We'll see how it all shakes out.

Re: Writing a website in Rust

#83
post #81

Earlier quoted context omitted.

Bitfields are evil...the fact that the language designer left them out signals he/they have good taste...I have to get around to trying out Rust.

No, ill-defined non-portable C bitfields are evil. If you can specify bit endianness, byte endianness, spans of bytes, and so on... bitfields are mighty nice.

But the thing is...the spec is ill-defined in C, and given the fact the C runs on almost any processor, you can't specify endianess in the abstract and pandemonium ensues.

Re: Writing a website in Rust

#86

Earlier quoted context omitted.

Refcounting and tracing are two different forms of GC, but you're right in the sense that most people mean tracing. At the same time, we're putting a lot of thought into how to properly add an optional tracing GC. It's important that it doesn't impact the no-GC case, which is still, of course, primary.

I'm glad to know there is ongoing work on a tracing GC. Rust has many strengths aside from lifetimes and ownership (algebraic data types, sane generics, strong module support, very strong type system), so a few features to make it more usable for use in contexts where performance isn't as important as expressivity would be very nice to have.

I don't think the primary use case for a GC in Rust would be "contexts where performance isn't as important" so much as another tool for lifetime management.

The current reference counted types don't just get used for convenience, they get used because they describe the actual life cycle of the data they contain. A tracing GC would be similar.

Re: Writing a website in Rust

#88
post #10

Here's something that most of you will probably learn the hard way: popularity and merit are not the same thing. Rust is very popular now. That doesn't mean it has a great design. One of the very first design decision/belief they made was "no code can perform with garbage collection". Well, garbage collection does cause quite a few performance problems, but that doesn't mean it can't work if you engineer it right. Pe…

You're getting downvoted because people who have spent a lot of time engineering and building don't like it when people drive-by with hypotheticals. You have some neat ideas; show us we're wrong by writing code and profiling. Not claiming that something that was published earlier this week (gittorrent) is how the web (going on 23+ years) should be rearchitected. Claiming you don't get along with others doesn't give you a free pass to shit on other people's work.

As a side note; it's really easy to see the wrong in things. It takes more work to try to find the good in things. You might find that you're better able to connect with people by being more optimistic.

Re: Writing a website in Rust

#90
post #51

Earlier quoted context omitted.

Super fast? More like Java ballpark: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

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 performancePlease 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.

Post reply on HN