Is Rust web yet? Not really
arewewebyet.com
arewewebyet.com
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.
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.
We can also end up with things like HTML templates compiled into your binary and the HTML validated at compile time. Even things as precise as type checking on something like <time datetime="{{ time }}"> can be managed with Rust. And I intend to.
I’ll be talking about how some of these sorts of things can work out at Strange Loop this year: https://thestrangeloop.com/sessions/fast-secure-safe-the-web....
These things are already done in several of the Haskell frameworks. There's even Blaze, which is a Haskell DSL that allows you to write HTML entirely in Haskell. Personally, static verification of HTML doesn't seem that necessary, but I suppose it has its merits (possibly for security?).
I'm not ready to say that Rust's type system lends itself perfectly well to ORM's, as I haven't really seen an ORM as convenient as ActiveRecord in any statically typed language. (This is one of the reasons I like both statically and dynamically typed languages.) But I'm happy to see people try, of course, and I'd love to be surprised.
http://ocharles.org.uk/blog/posts/2013-12-06-24-days-of-hack...
More in-depth interactive tutorial:
https://www.fpcomplete.com/school/starting-with-haskell/libr...
That talk looks really nice too, a shame it's in several months.
Continue the good work !
I’m definitely in with Rust and HTTP for the long haul. Hang round, things will get better.
OTOH, I'm not particular fond of ORM as a universally right solution for dealing with DBs (its a solution which makes sense for some DB-related issues in some OO languages, but isn't something that should be reflexive "deal with DB, need ORM"), and its probably not a solution I would reach for for any problem in Go even whether or not you could reasonable do it in Go.
Extensive use of reflection (in Go, this takes the form of type assertions) proceed to make it fundamentally possible again, but they have lost a lot of conciseness, certainty of safety and correctness in the process.
Personally, though, I've been migrating to "SQL calls" and "some support code to manage the rows coming back" even when not using Go. ORMs are this enormous pile of complexity, and it's amazing how easy it is to recover the vast bulk of their utility just by writing a bit of SQL. Use a decent SQL generator (as opposed to bashing strings together) and you're even closer. By no means is it a "full replacement", but I'm increasingly of the opinion that the costs of ORMs tend towards the staggering and the benefits minimal, for any nontrivial project. Possible exception for the really good ones that have been developed for a long time, but most of the ones used in the open source world are pretty dubious, IMHO.
That said, could you explain how Go's type system is weaker than Rust's?
I don't understand what the type system has to do with building a fancy ORM. Do you mind elaborating?
However, due to the JVM nature, one could use some of the well-tested and well-defined Java Web Framework from Clojure (with a lightweight wrapper, of course). I'm not really sure if people are actually doing that in production, though. [6] [7]
[1] http://caribou.github.io/caribou/docs/outline.html
[3] http://www.luminusweb.net/
[4] https://github.com/pedestal/pedestal
[5] https://news.ycombinator.com/item?id=7472841
[6] https://github.com/apache/tapestry-5/tree/master/tapestry-cl...
Clojure has Korma[0], Common Lisp has Crane[1] and Integral[2].
[0] https://github.com/korma/Korma
It's fast, expressive, and the modern Mono+ASP.Net web-stack is open-source (older stuff is still proprietary).
EDIT: I said not Go, because I don't like its type system, and whenever I have to cast something to interface I have a strong flashback from the old Java 1.3 days. On the other hand. It's purely personal opinion.
(I also love have fallen in love w/ how mongrel2 handles websockets. I find it fits very well w/ Rust's message passing between tasks.)
So it's not like writing a webservice in Rust is completely impossible. I will admit that "we aren't web yet," but I'm glad to see the community working on it.
Mongrel2 is a really good way to have all the nitty-gritty of http handled while you worry exclusively about two ZeroMQ sockets (from and to Mongrel2). It makes it a whole lot easier and safer.
Discovery of Rust projects is super hard right now. I'm quite into both REST and Rust and didn't know about your framework :/
Good point! But I'm not sure of any other way to get projects noticed besides word of mouth and posting about them on sites like Hacker news and such. In fact that is where I first heard about rustful.
> didn't know about your framework
My framework is actually at https://github.com/jroweboy/oxidize/tree/incoming (master branch is sorely out of date) and I feel I still have a long way to go before I get that finished :)
As Go and Rust share a lot of similarities, what is it about Go that's so unappealing for this use case?
It seems to me that Go and Rust are much more different than alike. Go has GC, Rust has lifetimes. Go has a simplistic type system, Rust has a sophisticated one. Go allows shared mutable state, Rust does not. These are pretty deep differences.
Absolutely, but it's not a reason to not use Go. The web is probably the platform with the least possible damage caused by GC.
It's OK if people like the language and want to use it for web development, though. I'm personally pretty excited about it, because I'm not a huge fan of Go and Rust looks pretty neat.
My experience has been that Go has very lightweight GC. The compiler intelligently turns a significant number of allocations into stack allocations (the same allocations would be heap allocations in .NET and Java, by comparison). It, by design, minimizes the amount of work that the GC needs to do, and in most real projects it just becomes a complete non-issue.
There are many domains in which GC is a deal-breaker, simply because you lose the fine-grained control over memory that you require: for example, games, embedded systems, kernels, and browser engines. (Go does not give you control over memory in the same way that C++, for example, does; consider map elements or closure upvars.)
> The compiler intelligently turns a significant number of allocations into stack allocations (the same allocations would be heap allocations in .NET and Java, by comparison).
No, .NET and Java do escape analysis as well.
The difference is that the JVM and CLR have generational garbage collectors with a copying nursery, so heap allocations are essentially as cheap as stack allocations: just a pointer bump. In the JVM (in contrast to Go) escape analysis is mainly used for eliding locks; allocation is so cheap that promoting heap allocations to stack allocations barely matters.
Sure. That encompasses a very small set of code. Indeed, it's interesting that you mentioned games given that most game engines now are a relatively small non-GC engine, layered atop with GC technologies.
You are a rather heavy advocate of Rust, and for whatever bizarre reason the Rust crew has decided that they need to aggressively attack Go (I'd recommend you maybe focus on delivering a production product first?), but it's interesting that you did exactly what I said -- it's just a checkmark.
"GC baaaaaaad".
Having developed a number of solutions with Go, and been involved in the solutions of others, interestingly the GC has never -- literally never -- been an issue with the platform. It has never, once, come up as a weakness with the language.
Now I'm not using Go to make a real-time nuclear power plant controller, nor would I ever use Rust for that.
No, .NET and Java do escape analysis as well.
.NET does not do escape analysis: Every reference allocation starts as a generation 0 heap allocation, and every collection is just as complex as any GC collection. Java mostly performs it for, as you mention, lock eliding.
so heap allocations are essentially as cheap as stack allocations: just a pointer bump
When comparing stack versus GC heap, the allocation is irrelevant. It's the clean-up that is the difference: The fundamental mechanism of how GC works guarantees it cannot possibly even come remotely close to approaching the speed of stack freeing.
It's natural he's a heavy advocate, he is part of the Rust development team. Would be weird you are developing something you wouldn't advocate.
They attacked Go how? They responded to your reply that was about GC, rarely if ever mentioning Go. This is a thread about Rust and people hijacked it with Go comparison, saying server are better suited for Go, etc. Like if I was working on developing some language X and people started making talks about competitor Y, I'd want to address any such claims, simply out of pride of my own work.
> Now, I'm not going to make a real-time nuclear power plant controller (minor edits)
Good.
I wouldn't trust anyone that has dabbled in Java/Go/.Net and made various servers/web-applications to look upon schematics of a real-time nuclear power plant controller, let alone be in same room with the code. Neither would I trust their opinion on whether language X is suited for that need. They are about as competent to make that decision as a bull is competent to make judgement of quality of fine Chinese porcelain. With his feet.
This set of people includes myself.
NOTE: I'm merely mirroring your dismissive stance about authors focusing on releasing and not talking (seriously, you have no idea how much effort went and still goes into Rust). Also programming RT systems of critical importance is on the complete opposite side of developing GC web application/servers. While your argument about GC on web apps might be considered valid, you haven't shown any knowledge of critical RT nuclear components, that would merit a different comment.
They used a checkbox, blanket argument against GCs, where the discussion was specifically about Go. It is just something I've noticed about the Rust team -- they overwhelmingly hold Go as their foe, and most if not all advocacy seems to be targeted at Go.
EDIT: I should add that a quick perusal of their comment history finds them engaged in many, many Go threads, always dismissive of Go. Again, to be active in Rust seems to be some sort of call-to-arms against Go.
Good.
In a past engagement I developed the real-time, QNX Neutrino-based control systems for power plants (not nuclear, but a very large power facility all the same). I certainly don't expect you to know that, but it does make your dismissal rather humorous.
However literally you decided to take that comment, the point of it is that certain benefits are very important in certain domains, and unimportant in others. GC as a simple checkbox is something that matters in hard real-time systems, for instance. It matters when every cycle is important.
In many other domains it needs to be analyzed, and there are no hard and fast rules. As I mentioned, the overhead of GC in most real-world Go solutions is close to if not completely irrelevant. Simply pointing it out as a checkbox, especially compared to what is effectively vapour right now (meaning you can't coherently compare solutions because one player is entirely unequipped to do so), is vapid laziness.
No they didn't. You just perceive it this way because fans of Rust often post in threads adding 'What about Rust'.
Fans non withstanding, I haven't really seen pcwalton or others (top 10 Rust contributors) behaving as you said they do. They comment on GC and various Firefox related technologies. Once the talk comparing Rust/Go starts, but I don't think they are as dismissive as you paint them.
But hey, prove me wrong, cite some messages.
--------------------
> In many other domains it needs to be analyzed, and there are no hard and fast rules. As I mentioned, the overhead of GC in most real-world Go solutions is close to if not completely irrelevant. Simply pointing it out as a checkbox, especially compared to what is effectively vapour right now (meaning you can't coherently compare solutions because one player is entirely unequipped to do so), is vapid laziness.
I offered no checkbox, just an explanation why people are excited about Rust. To me the greatest power comes not so much lack of GC, but concurrency, safety (no nil, compiler errors on unassigned variables) and zero cost abstractions.
I certainly don't see it that way. I comment in Go threads occasionally because I have experience in the areas people are discussing (for example, garbage collection). Again, I think Go is a really practical language for the kinds of things people are doing with it, like Docker and Camlistore.
> In many other domains it needs to be analyzed, and there are no hard and fast rules.
Sure, I agree with that. The question is what you do when it becomes a problem. That's where having precise control can help.
I ask because I'm the moderator of the Rust subreddit, and I have a strict rule against bashing other languages there. Not even Rust devs are exempt, though thankfully this has never been a problem. I'd like to encourage a culture of respect, rather than letting us get bogged down in holy wars. The constant comparisons of Go and Rust that I see on HN and the like are quite dismaying in my eyes.
Sharing my thoughts on language design as it relates to other languages seems to be doing more harm than good, so I'll stop.
> EDIT: I should add that a quick perusal of their comment history finds them engaged in many, many Go threads, always dismissive of Go. Again, to be active in Rust seems to be some sort of call-to-arms against Go.
I've written a ton of Go code and a bit of Rust code and I love both languages.
FWIW, I disagree that the Rust team is dismissive of Go. I've always found their comments to be well balanced and cognizant of the relevant trade offs involved when comparing two languages like Go and Rust.
Umm, no, they didn't. This thread started with someone whining about Go's type system.
> I wouldn't trust anyone that has dabbled in Java/Go/.Net and made various servers/web-applications to look upon schematics of a real-time nuclear power plant controller, let alone be in same room with the code.
How deliciously condescending of you!
And I guess, C++ people are somehow more competent for this particular task of working on nuclear power plants?
Count me skeptical.
I meant the entirety of this discussion, see the name of thread - Is Rust web yet? Not really.
> How deliciously condescending of you!
> And I guess, C++ people are somehow more competent for this particular task of working on nuclear power plants?
Yes, yes it is.
I didn't say that anything about C++. I'd assume that whatever C / Ada / Assembly /Machine code variant people working on critical embedded software use. C++ has exceptions, that alone disqualifies as critical performance language.
My point is that you were being condescending.
I'll be more direct: please don't be condescending.
(I really don't know how to deal with the fact that you're seriously talking about who is and who isn't qualified to work on nuclear operations based on languages they've used.)
You don't take a fork to drink a soup and you don't take a spoon to cut meat (unless the knife is duller than the spoon). Sure sometimes is fun to improvise by using knife as a fork, but that's a silly way to eat.
With that in mind a different language operates with a different set of limitations and a different mental model of execution.
Most people that program in Java don't have to worry too much about memory footprint, whether GC pause will kill performance, etc. Fact that they are using GC means they accepted non-deterministic pauses as part of the programming. To move from that frame of mind to a really performance sensitive where frequency and voltage matters requires a radical shift of thought.
You didn't say, "Don't use Go for nuclear operations."
You said, "I don't want people who've ever used Go to work on nuclear operations."
The former is perfectly reasonable. The latter is a gross over generalization and extremely condescending.
> Most people that program in Java don't have to worry too much about memory footprint
Here's a novel thought: not every programmer who uses Java has only used Java.
Artistic license/ Rule of Funny. Using a correct form, wouldn't have been as funny.
Also yeah, it's supposed to be condescending. I was mocking the author, mirroring his condescension towards the Rust team (to paraphrase said - stop checkmarking GC, get crackin' on Rust; Wouldn't use Rust in a nuclear power plant).
Ask major game developers whether they would be OK with pervasive GC. (We have, and the answer is near unanimous.) You simply need control over each and every allocation.
As a browser developer, I would certainly not be OK with pervasive GC in a browser engine, which are millions of lines of code at this point. The performance competition is just too brutal.
> You are a rather heavy advocate of Rust, and for whatever bizarre reason the Rust crew has decided that they need to aggressively attack Go (I'd recommend you maybe focus on delivering a production product first?)
I'm not attacking Go; I think it's a fine language. I'm taking issue with the idea that GC doesn't matter. The fact that this is happening in the context of Go is a side effect of the unfortunate fact that half of the comments on any Rust thread are about Go, and I would have the same arguments in the context of Java (since I don't think Java and Go are fundamentally that different in their reliance on GC anyhow).
> The fundamental mechanism of how GC works guarantees it cannot possibly even come remotely close to approaching the speed of stack freeing.
Sure, but minor collections are really, really fast. In a proper generational copying garbage collector I doubt this matters; the JVM looked at escape analysis for promoting heap allocations to stack allocations and found it didn't help very much.
FWIW, when Xcode (on OS X) switched from GC to ARC (automated reference counting), it got a massive performance boost.
I haven't seen an AAA or AA title that used Unity, they mostly make their own, use Ogre, Crytek or Unreal.
Unreal is defacto industry standard.
iOS, has ARC IIRC, not sure it has true GC like Java or C#. ARC is a super primitive GC.
> Ref counting does pause, you get cascading deallocations.
That's not pausing. That's it doing work, upon request (i.e. when the object is released). If you have a single object that roots a massive object graph, and you release that single object, yes, it will have to destruct that entire object graph. But that's not the fault of ARC in the slightest, and would happen just the same with manual memory management.
> More deterministic than other GC though.
It's not GC, so what do you mean by "other GC"?
---
ARC has the exact same performance characteristics as manual memory management, except it's all automated so you can't screw it up (e.g. over-releasing or under-retaining). But it's subject to optimizations too (such as skipping the autorelease pool), which actually makes it faster than MRR in a lot of cases.
GC pauses are because of work in other forms of GC too.
As for explicitness... no. that's not explicit in my book.
It's a super primitive in a same way an abacus is a super primitive computer.
Also, it is like a super primitive GC, in that it's a much more primitive and much more performant automatic memory management system (like GC). It's just a different level of abstraction we're talking here.
It's no different than saying how is polygon is like a super primitive circle.
Various embedded languages could have GC (e.g. Lua has a GC), but the only GC that's shipped in iOS itself is in JavaScriptCore.
> the Rust crew has decided that they need to aggressively
> attack Go
FWIW, most Rust people don't even see Rust and Go as competing, but everyone keeps comparing the two, and at some point, repeating a falsehood enough time makes it truth.
Even Rob Pike thought Go and Ru...errr, C++ would be competing, but was surprised when it turns out they weren't. Go was competing with Python and Ruby all along.
I haven't felt that way about pcwalton's comments. Maybe I'm wrong. Care to link some comments?
And sure, I did end up learning quite a bit about Go. No, Go didn't make all the design decisions I would have made if I were designing the language, and yes, I've posted about some of those on here (null pointers, generics, zero values, lack of memory safety when racing on maps). But that doesn't mean I think it's a bad language, and I'd even like to use Go at some point for some projects (lack of time, argh).
Most of the time that I see Go come up as a comparison to Rust on places like HN, it is someone who is asking how Rust compares to Go, some question about 'systems languages like Go, Rust, C++', etc. In turn, someone on the Rust team might answer, but they weren't the one to bring up the topic to begin with.
And
"The current implementation is a parallel mark-and-sweep collector but a future version might take a different approach." (which I'm certain it will)
That's true (although I would question the use of "allocation" there—I think Java has as much control over when you allocate as Go does), but "some control" is not always enough control.
Have you done a back of the envelope calculation to justify this? I have a Javascript/browser MMO engine backend that's written in Go. I simply invoke the garbage collector every world-tick (8 times a second) and that works great for me. I can manage a huge world with GC pauses as large as 20ms.
That said, I can't wait for rust teepee server to land, it shapes up to be a rather interesting project.
(BTW, I’m curious: where did the spelling TeePee come from?)
(Link currently down)