Comment by saosebastiao | Hacker News Reader

Comment by saosebastiao | Hacker News Reader

Parent Full thread

I feel like the projects where where rust is best positioned in terms of comparative advantage fall into two categories:

1) Large and complex systems that are slow to evolve due to being written in languages that are unsafe or are relatively poor in abstraction (in addition to the immense domain complexity). Examples: SQL and/or distributed databases, Paxos-ish systems, Operating Systems, IDEs, GIS, etc.

2) Extremely high performance systems on the fringe of research. Examples: MIP/LP/CP/SAT Solvers, Theorem Provers, Formal Verification tools, Rete-based Rule Engines, Machine Learning algorithms and frameworks, Statistical Samplers for MCMC, etc.

Unfortunately (maybe, I don't really know if it will turn out well or not), most of the hype for rust comes from back-end web developers. That is fine...I'm sure there is some performance to eek out there...but it is also trying to compete in an area where garbage collection has its greatest competitive advantages (namely, long running server processes). The comparative benefit is relatively small.

  > most of the hype for rust comes from back-end web 
  > developers

It may seem that way because 1) most of the hype for anything programming-related these days comes from back-end web developers, and 2) because back-end web developers are the primary audience of HN. At Rust meetups that I've attended I've seen interest in people doing video games, robotics, AI, numerical work, databases... they just don't have as public and excitable a forum as this. :)

I honestly wish we could get some of HN's mobile crowd hyped on Rust. A Rust-y take on Xamarin's ideas would be phenomenal, and with resource constrained phones, the performance gain from not having garbage collection or reference counting would be certainly welcome.

I suspect that crypto libraries and embedded systems might also be good areas for Rust. Basically anywhere that a buffer overflow or memory leak is a relatively high-penalty failure.

> compete in an area where garbage collection has its greatest competitive advantages (namely, long running server processes)

I thought it was the opposite that was true. A garbage collector can/will leak memory over time (days) and will use up to 6-8 times more memory and can have performance problems etc. All long running server processes I know of (database, mail, http servers) manage their own memory. Exceptions are VM based systems and it is not unheard of to have a trivial Tomcat app use up to 1GB of memory.

> A garbage collector can/will leak memory over time (days) and will use up to 6-8 times more memory and can have performance problems etc.

Usually that is a consequence of not optimizing the applications.

Using Java as an example, I still meet people that don't know about VisualVM, Mission Control, Eclipse MAT and many other similar tools.

It is possible to write applications that exhibit a flat GC line after they are warmed up, but many don't bother until someone complains about.

My, how times have changed.

Here, I come from the Lisp world where PDP-10s had magnetic core memory, and a max of 1MiB (of 9 bit bytes) in address space. Lisp Machines used DRAM, but at least early on less than an address space (64MiB of 8 bit bytes), and keeping your working set inside that was an issue if for no other reason than GC by the time I showed up was incremental copying without generations (i.e. an increment of GC would tend to trigger a page fault).

So I assure people like sovande that this can be done correctly, even if it's convenient to "ship it now!" and later find out what's "leaking" (keeping unneeded stuff from the tender mercies of the garbage collector).

Reply on news.ycombinator.com