3 ms·
With the large box flexibility you get with webdev, I don't know why you would want to use it except for specialized parts. Like a RAW -> jpg transcoder.
by mahyarm 11y ago
With the large box flexibility you get with webdev, I don't know why you would want to use it except for specialized parts. Like a RAW -> jpg transcoder.
- steveklabnik 11y agoOne reason: really, really low resource usage. Crates.io is reasonably complex, linking to libgit and such, and still uses roughly 25MB of RAM, constant. A Ruby process is ~30 MB off the bat last I checked, and Rails, well...
- mahyarm 11y agoBut how does it compare to go in this case?
- steveklabnik 11y agoI don't really program in Go, maybe someone who does can chime in. I'm not aware of any sort of recent direct comparison in this area.
- hobofan 11y agoHaven't made any direct comparisons (and that would be hard) but from my experience from working with both I would say that you probably won't notice a big difference in RAM usage (< 10% difference).
- akavlie 11y agoWeb library maturity aside, is the language inherently less suitable for webdev than Go?
- mahyarm 11y agoNot really suitable, more from a dev speed perspective vs Go. You have a GC for example, and the opinionated nature makes managing a large code base better. Also a GC pause isn't a big deal for web apps as far as I know. A reason why I would choose Rust possibly is because you can prevent data races although with it's memory management model.
- barosl 11y agoTwo points: - Performance is important even for web applications. For example, after migrating to HHVM, Wikipedia could buy less servers, serve pages faster, and reduce latency.[1] Rust is fast, even compared to other statically compiled languages. - Safety is also good to have for web development. I personally find it difficult to refactor my Python web applications. This isn't necessarily an advantage of Rust solely, statically typed languages tend to have this property more or less. But Rust does provide more guarantees than ordinary languages do. [1] http://blog.wikimedia.org/2014/12/29/how-we-made-editing-wikipedia-twice-as-fast/ http://blog.wikimedia.org/2014/12/29/how-we-made-editing-wik...