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.

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.

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.

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.

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

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.

Some of the top contenders:

* cpollcppsp (C++)

* go (Google)

* hhvm (PHP JIT by Facebook)

* openresty (LuaJIT on Nginx)

* undertow (Java)

* gemini (Java)

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.

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.

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.

Haskell and Scala?

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

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

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

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

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

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.

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.

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

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

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