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.
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.
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.
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.
(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.
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.
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.
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?)
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.
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.)
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.
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.)
So far as I can tell, if you want a fancy ORM, you're using a mainstream web language like Ruby or Python. Golang is obviously more mature on the HTTP serverside than Rust, but it is nowhere close to Rails, and is particularly weak on persistence. My understanding is that the same is true of Clojure, too.
Go can’t do a fancy ORM because of its weak type system. Rust’s type system and compiler plugin support (still being polished, but entirely usable) allow for some really nifty things. An ORM like Django’s is absolutely possible in Rust—and with strong typing and serious error checking into the bargain.
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.
Strong and weakly typed don't mean what you think they do. Strong typing is not about the expressiveness of a type system, rather about it having type safety, being memory safe and having static type-checking, and not having unsafe type conversions (and to a lesser extent implicit type conversions) and unions. What you meant to say was Rust's type system is more expressive then that of Go's.
> 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.
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 think what he means is static type system expressiveness, rather than type system "strength" (which is a term I don't like, since it's so overloaded as to be practically meaningless). Since it's dynamically typed, Ruby's static type system is maximally expressive. Go's type system (as with Rust's, or Java's, or any statically typed language) is less expressive by comparison.
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.
tl;dr ORM's with type safety and comprehensive error checking are possible with statically typed languages provided the type system is flexible/powerful enough
Couldn't an ORM for Golang be done with a code generator that generates filter functions and such based on the table layouts and relations? Then you'd get the best of both worlds: "dynamic" operation in the sense that the methods vary depending on the table layouts and relations, plus static validation of what you're doing at compile time.
Go’s type system is still not powerful enough to express such a thing; ORMs depend on blending things together from all over the place, e.g. with joins, method chaining and other things which really need genuine generics. There really is no solution without generics.
Since Go can do generics via code generation [1], I'm not convinced that it can't also do ORM via code generation.
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.
It seems to me that the method chaining is really all about building an internal S-Expression or tree structure of some kind that describes the type of query and joins needed. When it comes to solving problems, it's shaky ground to insist there can only be one possible approach.
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.
It depends. At the very most dynamic end, you'd encounter some troubles writing a code generator that could accommodate arbitrary joins of arbitrary combinations of tables chosen at runtime that happen to be for some reason arbitrarily joinable. This is an odd case, though; I'm sure somebody reading this has seen it and I sure it's out there, but it's probably not a case an ORM should be optimizing for. In most of the conventional uses, code generation could fit the bill, but you'd start getting into some weird declarations or something since you're not going to pre-generate every possible combination.
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.
Since you are the main force behind HTTP in rust, when do you think it (and rust) would be ready ?
You just started on Teepee and it seems like there are lots of breaking changes on rust itself every week so that's not really inciting me to check it out for now.
That talk looks really nice too, a shame it's in several months.
There are a few factors at work here. I hope to be able to secure some form of backing to allow me to work on it more (as it is, I’ve been taking Thursdays off to work mostly on Teepee). If anyone is interested in sponsoring me to work on it, I’m all ears! If I get backing things will happen much faster, to the level where I would expect to be able to write “ARGUABLY.” (though still not “Yes!”) on arewewebyet.com by approximately the end of this year. If not, it will probably take at least six months longer.
I’m definitely in with Rust and HTTP for the long haul. Hang round, things will get better.
The biggest thing is the lack of generics. That alone is enough to absolutely destroy any plans for a fancy ORM. Any such thing will end up using interfaces with type assertions everywhere.
(unintentionally) Mutable state passing over a concurrency boundary is a compile-time error in Rust. Two threads cannot mutate the same data unless you explicitly mark it as such, and by doing so, you'd force it through a mutex. This basically means data races are impossible.
For Clojure, some pretty good web frameworks (with ORM and everything) are starting to pop up [1] [2] [3] [4], but they're still early revisions and thus are prone to bugs and security holes [5].
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]
Or you could use GWT and have an extremely mature server-side language/ORM/everything-else, and a rich web client, all written in the same language and sharing the same class model.
Can't wait to try out Rust on sever though. I'd like to have compiled, performant, small footprint and simple http REST server written in language that is not Go or Haskel.
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.
For some reason, no one has mentioned that there is a very usable rust REST framework right now that you can try out https://github.com/Ogeon/rustful I'm not the author of this, so I can't tell you what features are missing, but the features that are there work very well from what I can tell. When it comes to web frameworks in Rust, there aren't many options yet (as stated in are we web yet) but the few that are out there are in active development.
I'm happily using the ZeroMQ bindings to serve an HTTP and WebSocket service w/ Mongrel2 servicing requests and Rust providing the handlers. Not a pure Rust stack, but it does a very admirable job serving responses for such a young language.
(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.
That's the exact path I've taken in another language (Nimrod).
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.
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.
Do Go and Rust share a lot of similarities? Apart from compiling into native code and being relatively new, what?
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.
Both implement the the CSP concurrency model, for example. Both have a C-like syntax. They are both object-oriented, but very different in that from java/c++/.net.
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.
"On the topic of performance, keep in mind that Go gives the programmer considerable control over memory layout and allocation, much more than is typical in garbage-collected languages. A careful programmer can reduce the garbage collection overhead dramatically by using the language well; see the article about profiling Go programs for a worked example, including a demonstration of Go's profiling tools."
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)
> On the topic of performance, keep in mind that Go gives the programmer considerable control over memory layout and allocation, much more than is typical in garbage-collected languages.
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.
Ok, and? Go is ok for server, that much is a given. Rust is X for server. Generally Rust is on par with C but how well will it work on server is anyone's guess.
My point is that you may not have to wait for Rust to be completed for a suitable server language. Do some back of the envelope calcs and quantify your needs in a concrete way.
While the web is one place where GCs have been well proven and a non-problem, are there actually any cases at all with Go where the GC became a problem? It seems like this GC advocacy is based upon a checkmark more than a reality.
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.
> It seems like this GC advocacy is based upon a checkmark more than a reality.
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.
There are many domains in which GC is a deal-breaker
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.
> 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.
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.
> 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.
FWIW, when Xcode (on OS X) switched from GC to ARC (automated reference counting), it got a massive performance boost.
ARC is not GC. It's automated reference counting. It's not a "super primitive GC" because it's a completely different approach to memory management. Notably, it has predictable behavior/performance characteristics, is suitable for realtime work (inasmuch any object-oriented approach with allocation/deallocation is; basically, it doesn't pause like GC does), and is fast. The downside is it is vulnerable to reference cycles.
The question was about precise control over memory allocations. Arc hides it like other forms of GC. You can tread carefully to avoid pauses with GC, but it is more fragile than explicitly manual mem management.
Ref counting does pause, you get cascading deallocations. More deterministic than other GC though.
Neither ARC nor GC hide memory allocations. They automate the process of deallocating memory. And ARC does not hide that either. Values get released when they go out of scope, and they get deallocated when the last reference disappears. It's a very explicit process, the only "hiding" is the fact that there is no `[foo release]` line anymore. But it's no more hidden than C++ destructors are.
> 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.
Yeah, the error is on my part. Meant to say 'ARC is like a super primitive GC'. It gives a very small amount of automatism over manually freeing memory, but must be done by hand.
It's a super primitive in a same way an abacus is a super primitive computer.
Yeah, no, you aren't helping your case at all. ARC is, again, not like a super primitive GC. And it most certainly is not "done by hand". That completely contradicts the "Automated" part of "Automated Reference Counting".
Yeah, no - is a very bad linguistic form. Try to avoid it. I speak from experience.
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.
GC and ARC are two very different approaches to memory management. Neither is more "primitive" than the other. They have different characteristics, different goals, different strengths & weaknesses.
> 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.
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.
> This is a thread about Rust and people hijacked it with Go comparison, saying server are better suited for Go, etc.
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?
> Umm, no, they didn't. This thread started with someone whining about Go's type system.
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.
I respectfully submit that you missed my point. I randomly picked C++ as a language you didn't mention.
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.)
And you missed my point. Right tool for the right job.
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 said, "I don't want people who've ever used Go to work on nuclear operations."
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).
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.
> 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.
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 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 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 know the Rust team doesn't have any animosity toward Go, at least not those that I have talked to. And the Go team certainly doesn't have anything against Rust. But I must say that I do notice you being overwhelmingly negative about Go a lot on HN and I wonder why you do that. Technically, yes, you are adding to the discussion in some ways but to me it seems unnecessary.
Can you cite some overwhelmingly negative comments that pcwalton has made towards Go? I always cringe whenever I see him comment in a Go-related thread, because I know how people will interpret any criticism of Go that comes directly from a Rust dev, whether or not the criticism itself mentions Rust. That said, pcwalton has seemed even-keeled every time that I've seen him comment.
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.
I'd rather just drop this. I don't see any point in escalating the discussion when we're all on the same page regarding relations between the two projects.
Sharing my thoughts on language design as it relates to other languages seems to be doing more harm than good, so I'll stop.
> 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.
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.
> the Rust crew has decided that they need to aggressively
> attack Go
As the one person in the world who is perhaps most up-to-date on what the "Rust crew" is doing in the community at-large, I can definitively state that this characterization is untrue, though I'm dismayed that you have somehow gotten that impression. All of the people that I've seen who bash Go while praising Rust are completely random internet commentators with no connection to the Rust community. If you can find me examples of Rust community members aggressively attacking Go, I will gladly ban those users from both the Rust subreddit and the official Rust IRC channel.
> 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.
This is true, but Patrick does pop up on a lot of Go threads saying negative things. If the Rust team doesn't want to be perceived as critical of Go then they shouldn't be so vocal about it.
I have lots of negative things to say about Go too, but it has nothing to do with Rust. I also have lots of positive things to say as well, but they have nothing to do with Rust.
I haven't felt that way about pcwalton's comments. Maybe I'm wrong. Care to link some comments?
I try to be balanced—I've made it clear that I like a lot of the decisions in Go and have no animosity toward the team—but I will stop commenting on Go if you'd like. No big deal.
Please don't stop commenting on Go. There aren't all that many mainstream (sort of...) language implementors who comment here, which makes your point of view rather unique and very interesting. I'd love to see you comment about more languages, not fewer. While I'm definitely something of a Rust fanboi, this goes for anybody with a depth of experience in actually working on a language - I love reading their thoughts about the trade-offs that their own and other languages made.
It's not my place to ask you to do anything, and I didn't raise this topic. I'm just saying: if you're wondering why people think the Rust team has a beef with Go, that's one reason.
Eh, Rust and Go have been perceived as direct competitors since the day Rust was announced, and before I even worked on it. They even were more direct competitors before Rust started ironing out its low-level performance story and dropped GC. That perception's hard to shake.
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).
Sure. I know you feel that way. But "the Rust and Go teams hate each other!" is a delicious and irresistible idea for some. When we are vocally critical of one another it perpetuates that meme whether we mean it or not. :-)
Yeah I can see them competing on the fabulous title of 'systems language' which means in Go's case - Server, Google toolchain and Rust's case - embedded, browser.
Right, Go and Rust have different definitions of 'systems language.'
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.
> , and for whatever bizarre reason the Rust crew has decided that they need to aggressively attack Go
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.
If I remember Rust binaries, due to default static linking end up rather large. There is work to remove all unnecessary things from libstd into other libraries.
That said, I can't wait for rust teepee server to land, it shapes up to be a rather interesting project.
Compare the footprint of your single static binary to a python program + the appropriate python 2.7.whatever & specific library versions which must be shipped with the program since odds are the user doesn't have the right version installed...
The binary is large, but the memory footprint small. And the startup time is small, too… servers that start up in under five milliseconds—delightful for me, with my Django background.
Dynamic linking cuts the binary size down considerably, but of course it requires the Rust libraries to be installed on the machine. You can also turn on LTO for even more savings.
This is more of a general question, but is rust going to have a C-compatible ABI? In other words, if I define a function in Rust, can I export it into a .so/.dll and load it up in MyFavoriteLanguage and call that function like I can with C? Or would it require some kind of C wrapper around Rust that interfaces with my language?
One of the three existing Rust deployments is a Ruby gem written in Rust. Technically, it's a Ruby gem written in C, which calls out to Rust. So yes, it's very possible, today.
Servo uses rust-http, which I wrote; Teepee is not yet to the stage where it can be used, but I expect that once it is Servo will switch to it as is convenient.
(BTW, I’m curious: where did the spelling TeePee come from?)
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.