Hacker News Reader

Comment by amalcon | Hacker News Reader

It seems pretty straightforward to me. Rust fits into more or less the niche of C and C++: a low-level systems programming language with minimal runtime dependencies (no garbage collection, smallish standard library), which happen to also be useful properties for realtime and other perfromance-critical software.

Go, on the other hand, fits more into Java's niche: an opinionated mid-level garbage collected language designed for application programming or mid-level systems stuff (i.e. web servers), with concurrency baked into the language design (though Go's concurrency design is much more to my liking than Java's).

View on HN

I mostly agree with your analysis. As someone who is doing web development in Rust, what should I fear of missing from a language like Go or Java? Is it just an ecosystem thing? Java is a more popular option for web server development over C++, but I don't know why.

I think with C++ it is much easier to shoot yourself in the foot, but overall, I think it's probably mostly just ecosystem between the C++ and Java.

Having tried both Rust and Go, I think I'd much prefer Go for simple web dev stuff because of all the ecosystem around it, but for most other things prefer rust.

> I think with C++ it is much easier to shoot yourself in the foot property

Go solves this by not allowing you to have a foot in the first place, instead encouraging you to walk on your hands and write blog posts elaborating why everybody should do this.

Is Rust really suitable for web development? I am genuinely asking.

For server development I think it might be a good choice, but for application code itself it seems like more of a pain to program in than an advantage.

Probably mostly depends on the libraries and frameworks that will appear? The SQL query->data->template pipe isn't very reliant on the language as long as it can manipulate "data" reasonably well.

Nobody wants to code C++ for webservers because of the risk (PayPal not included) but Rust doesn't have that issue.

Actually, some people use C++, with an OKCupid framework.

https://github.com/okws/okws

I think Rust has promise as a web dev language. Here's a quick list of the key libraries currently in the ecosystem[1].

Up until now, I've only ever used interpreted, dynamic languages for web development. In contrast, Rust offers me a tight memory footprint (no silly things like unicorn-worker-killer), high performance (the average response time for most of my Rails apps is 150ms), and a slew of static guarantees about types (no "undefined method for nil:NilClass") and memory safety. It also has some really cool things like sanitary macros and syntax extensions that have allowed me to build out a fairly simple yet robust ORM similar to ActiveRecord in look and feel.

I may be forcing a square peg into a circle hole; all my current work is experimental.

Can you clarify on the difference between "server development" and "application code"? In this context, I've always considered those terms to be the same.

Edit: I think I understand what you mean by application code — business logic code? Reasonable concerns. I don't have much to say yet (I'm just doing framework stuff now in preparation for real applications), but here's a demo of my aforementioned ORM in action[2].

[1] http://arewewebyet.com/

[2] https://gist.github.com/SkylerLipthay/9015e6c79859e7dc8709

If garbage collection is ok for your use case, a garbage collected language (Java, Go, etc) will most certainly make your life easier than with Rust.

Rust is good for extending Python, Ruby, etc stuff. More safe than C.

Rust seems like an excellent choice for performance sensitive parts of your web application, especially client side. Right now asm.js / WASM do not contain a garbage collector, so most other choices would involve shipping up a large run time with your app. Unity can get away with that -- you probably can't.

Server side you have many more good choices, but Rust does have a nice FFI story in both directions.

Whether you want to write your entire app in Rust is a different question. I'd want to get more experience with Rust before answering that question -- writing a performance sensitive portion in Rust first would go a long way to answering that question.

I used Rust to optimize performance in a hot spot for our Python web-app. I am a Rust newbie, and this was my first encounter with the language, so my opinion may not have much value. But I found Rust to be unsuitable for web-development.

The fact that Rust requires that you think about memory management made it feel less expressive and less productive. The strictness of the compiler also got in the way of "productivity". There's nothing wrong with that strictness, but in the domain of web-development where productivity and expressiveness is often more valued than raw performance Rust doesn't feel like the optimal tool.

To use Rust for web-development feels like a premature optimization.

I think for web-development, it's probably more productive to use Ruby/Python/etc... and call Rust externally to optimize hot spots.

I can't imagine there being a huge difference between Rust and Go both being quite new.

Java and in particular the JVM has a massive ecosystem which ranges from small libraries through to major infrastructure components e.g. databases, big data, enterprise, middleware, integration etc. And the fact that the biggest and best companies are using it means you can leverage some high quality components e.g. Twitter, Netflix, IBM. That said all of the above isn't mandatory for 90% of websites most people build.

As for why Java is popular for web server deployment. Not having to worry about memory management, having a less complex feature set and excellent performance are the key features I can think of.

> I can't imagine there being a huge difference between Rust and Go both being quite new.

This is a failure of your imagination. The linked article points out some of the differences, but there are many others. This topic has been endlessly discussed, and I'm kind of sick of repeating it, but I have written several posts on this matter and you can hunt them down if you wish.

Specifically about C++ v Java for web development, I think the answer lies in reflection. C++ doesn't allow member introspection at runtime like Java. Many web technologies and their supporting stacks leverage reflection heavily.

Look at Spring MVC. Both it and Spring in general are reflection machines. This provides a lot of easy work that's relatively safe even with duck typing.

C and C++ were a mess when Java appeared.

C was standardized in 1989 and in the early 90's it was still easier to port K&R code than ANSI C.

C++ only got standardized in 1998, two years after Java appeared. Each compiler supported different parts of the standard, had vendor specific libraries and suffered from C like APIs.

Java was a good enough C++ that one could expect with would have the same behavior in every system.

Also the Java 1.0 networking libraries were already miles ahead of anything one could find for C and C++, and its SDK was free in the days we paid for compilers.

For Java, you get some very excellent tooling, a slowly evolving language, a battle-tested and mature virtual machine, comprehensive API, first-order parametric polymorphism, and a number of useful frameworks with tons of community support.

For Go, you get an opinionated language/build system, decent tooling that is quickly evolving, no higher-kinded types, very systems-oriented API, ability to target multiple platforms without a VM, and also a number of useful frameworks.

In short, and this is just MHO, I would rather build a systems-oriented app with Go than with Java, and I would rather build a webapp with Java than with Go. It's not clear to me that, as a language, Go can capture bizlogic complexity the same way Java could in a webapp. Also, it's definitely clear to me that I would rather deploy a native binary than a vm + bytecode for systems-heavy tasks, like automating maintenance of a database cluster, and Go is excellent for that.

Compared to Go or Java you're not missing much - I'm not sure what the state of Rust's generics is these days but at the very least they're not far behind Java's. Compared to a higher-level functional language you're missing higher-kinded types that would let you do things like http://typelevel.org/blog/2013/10/18/treelog.html . See what you end up doing for "cross-cutting concerns" - things like logging, auth, transactions - as those are the kind of thing you need a higher-level language to handle elegantly.

The big thing you're missing compared to the mid-level languages you mention is garbage collection. Rust makes manual memory management much easier than C++, but it's still never going to be quite as easy as the "just make objects and don't worry about it" that you get in a garbage-collected language.

yes they ARE competitors.

They are both used where people would use C or C++ to get more performances , especially by developers who would normally use a scripting language like ruby or python for their 'website'. Never heard a "why we moved from Java to Go story", heard plenty of infrastructure rewriting from ruby/python/nodejs to Go. People stuck in enterprise Java/C# ain't going to move a 10-15 yo infrastructure to the latest hype,they'll stick to the JVM or the CLR which offers plenty of choice already.

These (former) devs might have used Rust instead of Go though Rust doesn't come with a big webapp related ecosystem yet (it will).

In this space (compile to executable - statically typed yet still expressive languages without manual memory management) there are basically 4/5 languages in competition : Go, Rust, Nim, D and Crystal. One of them will be the 'C++ for suckers of the next 10 years' and will be incredibly successful as the demand is quite high. So Go is definitely in competition with others in that space.

Now let's the competition begin.

IMHO 'C++ for suckers of the next 10 years' will still be C++ (and I would love to be proved wrong).

> They are both used where people would use C or C++ to get more performances , especially by developers who would normally use a scripting language like ruby or python for their 'website'.

Rust is definitely not generally used by people who would otherwise use a scripting langauge.

There are dozens of languages with the same target audience as Go (with a similar or better maturity level); there are very few languages with the same target audience as Rust (suitable for embedded systems sans libc) with the maturity of Rust.

> Rust is definitely not generally used by people who would otherwise use a scripting language.

I fail to see why pythonists or rubyist couldn't use Rust. On the contrary Rust has more semantics that are closer to these languages than Go has.

"On the contrary Rust has more semantics that are closer to these languages than Go has."

Uh... goodness gracious no. Going from Python to Go is a bit of a learning experience, and you might lose some features you're used to while gaining some new ones you're not very used to, but it's not too big a deal. Going from Python to Rust is halfway as hard as going from Python to Haskell. Radically different philosophies, radically different semantics (GC to no GC is shocking enough, but Rust takes "no GC" to new heights of foreignness).

The first program a Pythonista writes in Go will pretty much work. The first program a Pythonista writes in Rust will explode into a half-page compiler error discussing concepts they've never heard of before.

None of this is a criticism of Rust... I applaud Rust for getting itself a good distance away from Python! In 40 years I think "imperative languages with no built-in ownership concepts" will be regarded in much the same way we regard line numbers today... "How did you ever use that? Are you serious? Who would ever think that was a good idea?" (Well, you had to be there...) But in the meantime, it's no contest... Go is way closer to Python than Rust is, and yeah, to some extent I personally consider that a criticism of Go. (I like Go for work, but to some extent I see it as a last-generation final refinement of its ideas, whereas Rust is a one of the first usable languages of the next generation. Both have their place. I suppose that doubles as my own explanation of why they aren't competitors, or at least, not direct competitors.)

Reply on news.ycombinator.com