Comment by hendzen | Hacker News Reader

Comment by hendzen | Hacker News Reader

Not to be a curmudgeon but why would one want to use Rust for web development for a non-toy project?

I am a big fan of Rust, but as it aims to be a better C++, it is probably a better fit for OS development, game engines, embedded systems, databases, complex desktop applications (Photoshop/Word/Chrome), etc. While Rust is quite expressive for a systems programming language, its banner features are the borrow checker (+ lifetimes, etc) and powerful static type system. Rust emphasizes zero-cost abstractions with compiler-enforced memory & thread safety. The popular web development languages are dynamically typed and interpreted, with an emphasis on rapid development, which is a very different niche than Rust claims to fill.

Perhaps Rust could be used to build a highly optimized server for a large site, but at that point it would probably better to write the application to run on the JVM. Although the JVM may be slower (within a constant factor, and assuming Rust is eventually as fast as C++) and more memory-intensive than the optimized native code produced by Rust's LLVM based compiler, the JVM's extensive tooling and run-time profiling tools make it a natural choice for high performance web servers.

"Not to be a curmudgeon but why would one want to use Rust for web development for a non-toy project?"

Web development is horrifically, unbelievably bent around two facts:

1. There has been no convenient, highly popular and supported language for development that also has best-of-breed performance. You can have one or the other. (Yes, I've probably heard of your obscure fast-as-C language that has a great web stack... to a first approximation, nobody else has.)

2. Web development languages have been profoundly, deeply single-threaded, to the point that the web world began to take it as an unmitigated virtue that a page started with a request, generated a response, and dropped everything in the world that it knew at the end of the request. State is something that must be managed carefully, but especially in this era of people writing web applications that may literally have gigabytes available per concurrent user (obviously, not everybody, but this is a non-trivial use case!), the statelessness dogma has seriously broken people's mental models vs. what the hardware is actually capable of.

With Rust, you should be able to write fast, concurrent web applications that actually do something concurrently and aren't constantly marshaling across requests for the client to re-initiate AJAX calls or other such silliness, it'll be fast, and with its emphasis on memory safety, statically safe as well (something that you're not going to get very easily out of Java, and certainly not from a programmer just sitting down and pounding out some Java). It isn't going to be the solution to every problem, but it's going to be the solution to more problems than people realize right now, because we've so deeply internalized our essentially-PHP models of how the web works that we can't hardly even see how things ought to actually be working.

Rust isn't the only language biting at this apple. Go is obviously another one. But Rust has a pretty decent shot at taking a big chunk, if it plays its cards right.

You say the popular web development platforms are all dynamically typed... I'm increasingly coming around to the position that was an accident of history, rather than an immutable fact.

So I guess I'm gonna be that guy.

According to http://www.techempower.com/benchmarks/, the 2nd position is held by a Java framework, losing only 13,5% to the C++ overall winner. Granted, you need a 3rd party library to have something similar like goroutines / fibers / actor concurrency / whatever, but its all there if you want it.

Java is not regarded as convenient for web development. Fast when built, yes, but not convenient. And C++ is borderline unsuitable. (A well-chosen and carefully used subset, sure, but the exact things that Rust is fixing about C++ is also why you should think about a dozen times before using it to build web apps.)

And neither are as safe as Rust is/will be with multithreading. Doing really pervasive concurrency is possible, but not particularly easy with those languages.

Why isnt java convenient for web development? too many semicolons?

So... Scala, then?

"Yes, I've probably heard of your obscure fast-as-C language that has a great web stack... to a first approximation, nobody else has."

It's less obscure than Rust and among web developers less than Go as well. How is it obscure, really?

http://www.indeed.com/jobtrends?q=scala%2C+rust%2C+Clojure%2...

Scala is far from obscure

That's nonsense. Scala is pretty well known. (Apache Spark, Play Framework, Spray, Akka, Scalding, Kafka, etc...)

As for the web stack: Play, Scalatra, Spray, etc... It can also use the fairly mature Java libs as well: Jersey, Jetty, etc...

On the other hand, I don't know of any popular projects that are written in Rust, other than what Mozilla is doing with Servo.

I can name companies as well: Twitter, Airbnb, LinkedIn, Gilt, Foursquare, The Guardian, etc...

Github still probably runs mostly on Ruby as well, and for performance, you could use JRuby.

Will Rust really be that much more "convenient" than Java with all its tooling, libraries stack overflow examples etc? It seems to me it would be in the same class as Java at best when it comes to convenience with the likes of python and ruby being in a different class.

This is 100% speculation, but in a few years, I can see Rust as a language in which _those who code in it_ find it to be way more convenient, but those who don't find it more difficult.

Basically, the borrow checker double checks your work. As you get better at not screwing up, it'll become less and less of an issue. When you're just starting out, it can seem way harder, because you're not used to having those restrictions checked.

The benchmark page is interactive, you should check out all tabs and come to a conclusion.

Some of the top contenders:

* cpollcppsp (C++)

* go (Google)

* hhvm (PHP JIT by Facebook)

* openresty (LuaJIT on Nginx)

* undertow (Java)

* gemini (Java)

I would say Scala is convenient, popular, supported and with good performance. It also has the static safety and memory safety you desire. All the while with an excellent library collection which is a superset of Java's library collection. Clojure should get a mentiom too. Rust needs to get its game on to compete with that. It should at least beat JVM stuff on memory consumption, so it has that going for it.

As far as I know Scala can't have value types (aside from the single member which is useless from performance perspective) for eg. you cannot do things like "std::vector<point3f>" and have that allocate a flat array of size N * size of 3 floats, instead it will allocate a array of pointers to point3f type objects and then do allocation for point3f N times and will also allocate extra memory for each point3f object for bookkeeping which is really significant when you're dealing with such small objects in large numbers.

This is courtesy of JVM not having value types, and that's just one obvious performance dead end if you write code that deals with that sort of thing (both in memory usage and in access time/runtime). There's plenty of other stuff that makes JVM not suitable for performance sensitive work, as long as we aren't defining performance sensitive as "faster than Python and Ruby".

Web apps seem to be IO bound so runtime performance generally doesn't matter.

>There has been no convenient, highly popular and supported language for development that also has best-of-breed performance.

Haskell and Scala?

Neither are "highly popular". Haskell's web stack is not particularly fast, in spite of the fact that it is possible to get good performance from the language.

Is "faster than Nginx" fast enough for you?

http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask03...

In case somebody brings it up, the Techempower benchmark results for Haskell (GHC) are broken, they use an ancient (7.4) version of GHC. The paper linked uses the current (7.8.2) version.

Both Haskell and Scala are more popular than Rust right now. Scala is actually on its way to become a mainstream language (http://sogrady-media.redmonk.com/sogrady/files/2014/01/lang-...), followed quite closely by Haskell.

(Common) Lisp fits your bill. It's threadable, cross-platform, compiles to machine code, well supported, stable, and able to be molded to any domain (such as web development). In fact, there are already some great web/app servers and frameworks for it already.

It's not "highly popular" compared to something like Python, but has growing usage and attention. The implementations are converging on a standard set of modern features that are cross-platform. I routinely write code in one implementation/OS and run it on different implementations/OSes without a hitch.

>It's not "highly popular" compared to something like Python, but has growing usage and attention.

Let's not kid ourselves. CL will never get anywhere regarding adoption for web use (at least for values of "never" = in the next 20 years, and "anywhere" = several high profile companies use it, and there are at least 3 dedicated books about its web frameworks).

Almost all programming languages can claim "growing usage and attention", but it rarely amounts to much. Go has managed to have more usage and attention from high profile companies in 3 years of existence that CL or Smalltalk have had in the last 25.

Rust is certainly not ready yet, but I think you’ll be surprised how great Rust can end up; I believe it will end up superior to the options available, though its systems focus will certainly have certain cognitive burdens; it is not going to be superior in every way.

People typically associate web servers with dynamic languages. I am ready to challenge that notion; there are various things that people don’t think of that a language like Rust makes possible, and those sorts of things are the focus of my talk at Strange Loop this year, in September: https://thestrangeloop.com/sessions/fast-secure-safe-the-web...

Your Strange Loop talk description presents some good reasons for using statically typed languages, but why Rust specifically? Why not the JVM, using Scala or even Java 8? Sure, a Rust program compiled to native code can start faster, and be fast right away without any JIT warm-up. But is it worthwhile to optimize for those things? Especially since the JVM already has a much larger set of libraries and tools. And while Rust's lack of GC would probably yield impressively low memory usage figures, I wonder if that matters in server applications.

The idea of a server that starts up fast, is fast from the start, and has minimal memory usage is appealing to me, but I suspect that it's irrational to optimize for these things except in niche applications like web interfaces in routers.

I’ll be covering more about why Rust specifically in the talk; there are some really nifty things in its compiler and type system which allow for more than languages like Scala and Java 8. I’ve mentioned some of them in some of the other comments here; given the interest shown here, I think I’ll say more about what I hope for in the long term in a few weeks’ time. Oh, It also gives you a lot in the way of correctness which languages like Scala and Java 8 don’t give you.

I looked at your other comments but couldn't see anything enlightening. I really enjoy Scala's type system and would love an excuse to learn Rust; what can Rust's type system do that Scala's can't? (I saw you mention an ORM; what additional safety could Slick gain if it were using Rust's type system?)

Rust has data-race-free concurrency. The compiler won't let you compile code that has data races unless you write "unsafe {}".

So Rust would be able to figure out that some transactions might be prone to rollbacks? What's the name of Rust's database library which does that?

I am also skeptical about Mr Morgan's claim. I am, therefore, really looking forward to his talk!

For one he can stop worrying about nulls and start worrying about appeasing the compiler :P Rust compiler is a harsh, ever changing mistress.

Not to be a curmudgeon but why would one want to use Rust for web development for a non-toy project?

I am a big fan of Rust, but as it aims to be a better C++, it is probably a better fit for OS development, game engines,

If there was an easy way of using Rust as a websocket server, I would be using that for my project instead of Go. The option to use reference counting is a Big Win when it comes to high degrees of parallelism on multicore processors. When you have GC, the GC thread comes along and causes cache misses for all of the other threads running on different processor sockets. With reference counting, garbage is "collected" locally.

Ref counting is murder on caches. Every read will cause a rmw on the ref count cache line.

Modern generational GCs are reasonably nice on caches in most cases.

Every handoff, not every read, right? Of which there might be more or fewer.

This is not so much the case in rust because you only increment the reference count when you're passing around copied refs to an item. If you instead borrow a ref counted item, you don't need to increase the ref count - because rust will statically enforce that the borrow lasts less time than the item it borrows from (which is enough to keep the item alive). With good coding practices, you can eliminate the large majority of ref count increments/decrements.

Such cache line will (because it is adjancent to the refcounted data) almost always be in cache anyway. Rust's refcounting is much cheaper than C++'s refcounting because it doesn't need to be atomic. (There is a separate type for atomic RC, and it is enforced by the compiler that you use it when needed.)

Not everything is reference counted in Rust. Doing stack allocations in rust is actually really easy. Stack allocations in case your not aware are incredibly fast compared to anything else. The only thing faster is static allocations.

In Rust, from what I've seen, you basically have the option to avoid heap allocations almost entirely which is fantastic for performance. The only other languages that come close to giving you that ability in a very explicit and deterministic way that I know of are C and C++.

> In Rust, from what I've seen, you basically have the option to avoid heap allocations almost entirely which is fantastic for performance.

Not really. Any time you using a `Vec<T>` or a `String` type, you'll be heap allocating.

I suspect what you meant to say is that Rust does not force programmers to use some sort of garbage collection (whether it be reference counting or otherwise). That is indeed the case. I've written a fair amount of Rust code and haven't needed to use a GC at all.

> Not really. Any time you using a `Vec<T>` or a `String` type, you'll be heap allocating.

Well, we have the SmallVec type to avoid this if you can bound the size of your vectors. I would also like to introduce scratchpad allocators at some point, which should allow you to avoid heap allocations even for those.

Either way, there are many ways you can avoid heap allocations entirely. For example, my NES emulator does not call malloc() during gameplay, at all.

Oh cool, I didn't know about `SmallVector`! That's clever.

> Either way, there are many ways you can avoid heap allocations entirely. For example, my NES emulator does not call malloc() during gameplay, at all.

Definitely. Executing searches from `regex!` expressions won't heap allocate either. :-) (Sans the return value, but maybe that can be avoided too.)

Doing stack allocations in rust is actually really easy. Stack allocations in case your not aware are incredibly fast compared to anything else. The only thing faster is static allocations.

This is also the key to programming performant Go. However, you can't really entirely avoid heap allocations, just minimize them.

I managed to get Rust wired up to websockets pretty easily.

There are working zeromq bindings: so you can use mongrel2 to handle websockets (with or without TLS) and then service those requests with a handler written in Rust!

You have to write the handshake & protocol framing yourself; but there's a reference implementation in Python[1] that's only ~200 lines long and supposedly passed the Autobahn test suite.

Rust's model of concurrency also jives really well with mongrel2's architecture.

---

There's one gotcha: receiving on a zeromq socket through the C bindings blocks the OS thread. This will cause your program to deadlock if you're using Rust's green threading. (Native "1:1" threading is the default however.)

[1]: https://github.com/zedshaw/mongrel2/tree/master/examples/ws

Reply on news.ycombinator.com