10 ms·

The first thought that should pop into your head is probably, why use this instead of language XYZ, where XYZ is Ruby/Java/Python/Go. It's actually a pretty int

• andresmanz 11y ago
  > No one would (should!) ever consider writing a webservice in C++ Depends on what kind of web services you're talking about. C++ is widely spread in game development. It's nice to have the client and server code in the same language, so in game development, C++ web services (including multiplayer servers, if you count that as a web service) are not too unusual. Two years ago, I even had a customer who wanted me to create a C++ backend for a large website. That was a surprise, of course. But it was fun, it's safe, and it works. You can easily test for safety, and the security logic stuff is just what you have in any other language.
  • vezzy-fnord 11y ago
    Pretty sure Gmail's backend is C++, along with many other Google web services.
    • aikah 11y ago
      > Pretty sure Gmail's backend is C++, Define "backend". Pretty sure the core business logic of Gmail is written with tons of Java. C++ is used for generic "infrastructure" software, not for writing Gmail's business rules.
  • viraptor 11y ago
    > You can easily test for safety How do you define easily? Afaik, state of art is still: static analysis, maximum pedantic level from the compiler, 100% coverage, lots of fuzzing, lots of logic testing... and it still doesn't stop you from getting owned via one of the libraries you include (JSON, http parsing, ...). Is that not the case? It seems far from easy, if you compare to (for example) python framework where almost all of the code is pure-python. Edit: I meant practical state of art. Sure, you can prove your webapp secure if you have enough time. But nobody would seriously do that.
• allan_s 11y ago
  > No one would (should!) ever consider writing a webservice in C++, simply because it's unsafe to do so, it's much easier in other languages I wrote some years ago https://github.com/allan-simon/cppcms-skeleton https://github.com/allan-simon/cppcms-skeleton Which I used as a MVC C++ framework to create webapp, even a quite full featured wiki (multi-language, image uploading, markdown, history, conflict resolution with diff etc.) https://github.com/allan-simon/tatowiki https://github.com/allan-simon/tatowiki which is used in production there http://wiki.tatoeba.org http://wiki.tatoeba.org for now several years too (without crash, of course one error 500 from times to times because there was some bug) And it's not that hard to read and write I think https://github.com/allan-simon/tatowiki/blob/master/app/src/controllers/webs/Articles.cpp https://github.com/allan-simon/tatowiki/blob/master/app/src/... Of course it was missing a lot of tooling (ORM, database migration etc.) but I don't think the language per se was the problem. And if counting the full stack of dependencies, my solution certainly had less line of C/C++ involved than your typical php application :) For this, if i was to redo it in 2015, I would however consider Rust without any hesitation, especially as I think it has one major advantage compare to C/C++ regarding web services => the community wants to go that way and make library/framework to create webservices in Rust, first class citizen of the ecosystem
• ZoFreX 11y ago
  > No one would (should!) ever consider writing a webservice in C++ I can think of one area where that is done (and where Rust might fit quite nicely): Bittorrent trackers!
  • omginternets 11y ago
    This surprises me; what's so special about bittorrent trackers?
    • throwaway2048 11y ago
      they are extremely performance demanding (the actual tracker itself, what the clients communicate with), and use http. So much so that major trackers are constantly running into performance limitations. They often have to issue 1k+ requests per second.
    • ZoFreX 11y ago
      To add to what throwaway2048 said, as well as having high performance requirements, they're small and don't change much. You wouldn't want to write your typical CRUD app in Rust or C++ because developer speed is more important than application speed. But bittorrent trackers, while using http, are operating to a strict protocol, and are nowhere near as large (in terms of features and code size) or as fast changing as typical web apps.
• kyllo 11y ago
  Yeah--so, Rust's mission is memory safety without garbage collection. Is there ever really a situation where you need to write a web service but cannot afford garbage collection? Rust is a really cool and novel language. I considered learning it, but since I mostly program web apps and services, I decided to go with Haskell instead. it has much better performance than dynamic languages, but is still garbage collected, because managing memory manually in my code seems like a wasted effort. I chose Haskell rather than Go just because I like functional idioms, but you could just as easily replace Haskell with Go in the above paragraph. I mean, I guess the fact that you can write a web app in Rust is cool, I just don't understand why you'd really want to, when there are languages like Haskell and Go (and Nim and D...) that give you fast binaries and garbage collection.
  • jpgvm 11y ago
    The only real time Rust would be better due to lack of garbage collection is when you need performance consistency. It might be better than some of those languages for other reasons though. For instance I think Rust is more expressive than Go. I think it's easier to learn and more practical than Haskell (though I do enjoy me some Haskell too) and I think it has better tooling than all of those mentioned (except Nim, I don't know enough about Nim to pass judgement).
  • aethertap 11y ago
    I've been writing a web app in rust for a while now (using a different framework though, iron's ergonomics didn't suit me for some reason). Overall I've found it a pleasant enough experience. The reason I like the it is that I write code for a wide variety of domains, from web apps to compilers, and so far rust has been a decently usable language in all the domains I've tried it in. I really like the "one language to rule them all" aspect of it because it simplifies my life - chances are good that whatever problem I'm looking at will either be trivial enough for shell scripting, or will be amenable to a rust-based solution. Narrowing down the language set seems like it could also lead to some interesting interoperability potential, like an easy web UI for a disassembler library or something. I still use half a dozen other languages on a regular basis, so the dream of being able to really focus on just one is still just a dream. However, rust is getting closer, and I'm gradually migrating most of my work to it when the choice is up to me.
• mtanski 11y ago
  > No one would (should!) ever consider writing a webservice in C++, simply because it's unsafe to do so That's a pretty bold statements. By the same account, you should not write a webservice in rust because it's unsafe. One example is Rust's treatment of OOM cases. Today, if you run into OOM Rust will panic. Technically, you can have it call a oom handler, but you cannot call many common function in the handler since they allocate memory, so it's not super useful. Here's the bug, https://github.com/rust-lang/rust/issues/27335 https://github.com/rust-lang/rust/issues/27335 . And, here is the original one https://github.com/rust-lang/rust/issues/14674 https://github.com/rust-lang/rust/issues/14674 . (Side note: I find the habit of closing bugs and reopening new ones kind of annoying, since it's hard to track how long it's been know / around). I imagine as a malicious client you could try to DOS an application by 1. forming a message that will cause the application to allocate a lot of memory (as temporary buffers). 2. Send a lot of messages causing pressure on the memory subsystem. You can of course try to not have these issues in your application, but Rust doesn't explicitly save you from the, On the other hand in C application, you can try to close the offending client's connection and in C++ if you get a bad_alloc (and you deal with it) you'll end up unwinding your stack (and free enough memory to continue on). C++ makes it even easier to handle it at the top level and let RAI take care of the rest. Yes, in Linux you can die in the system oom case. But, 1. you can turn that off (and you should at least on some systems), 2. depending on your over commit policy you'll get an error instead of OOM if you allocate in a too big chunk. I personal like Rust and I'd like to see it succeed. But I think the Rust marketing is getting away from what Rust is able to do in it's current incarnation (1.2). Simply, in it's current incarnation there's lot's of unsolved problems (big and small). So please stop making outlandish claims.
  • yokohummer7 11y ago
    You say like C/C++ applications are particularly more resilient to OOM situations. That hasn't been my experience. You can deal with OOM in C/C++, but that doesn't mean it is quite viable. Even popular C libraries just abort when memory allocation failed. Regarding C++, is there really a code that even tries to capture `bad_alloc`? If so, did they test the various OOM situations that the program may encounter? I highly doubt it. I don't think that the "just panic" strategy used by Rust is pretty. It is mediocre at best. But I also don't think the way C/C++ handle OOM is great. They produce similar results in practice.
• sciurus 11y ago
  Regarding your web gateway, you might be able to use heka with the HTTP Listen input and AMQP output. https://hekad.readthedocs.org/en/v0.9.2/ https://hekad.readthedocs.org/en/v0.9.2/
• nstart 11y ago
  > There's a web gateway in our cluster that receives binary blobs over REST and puts them onto the message queue. In total not much over 100 lines of Ruby. We've thought about reducing the server load a bit by porting it to Go or some other more performant language. On a note unrelated to the actual thread, how do you port a piece like this to another language? Is the Golang part another webservice? Do you fire up a thread to start a process? Is it called via a bash script? If there's an error how do you get the error back from it?
  • tinco 11y ago
    Are you asking what application server I'd use? Or what framework? Currently the service is a Sinatra app managed by Passenger, it logs errors to stdout and airbrake. I guess if we would port it to Go it would be exactly the same. Frameworks or app servers are details I haven't thought about yet.
• pjmlp 11y ago
  I can write web services in Haskell, OCaml, .NET, Java, Ada, Delphi, D, Go. All compile to native code and I don't have to fight with the borrow checker. Rust needs a good story to be sold as alternative for web development. We don't need system programming features in a web application. Unless maybe when offering a web interface to an embedded device, instead of coding it in C. EDIT: Before the downvotes continue, I am not attacking Rust and feel it is good that it also gets web frameworks. The point being that for web development there are already better alternatives and unless one needs Rust special language features, there isn't a compelling reason to use it instead of the more mature alternatives which also make use of native code.
  • pcwalton 11y ago
    The borrow checker also eliminates data races (and a variety of other bugs), something that most of the other languages on your list do not. While avoiding GC is probably the most prominent reason for the borrow check's existence, it is not the only one. You shouldn't have to fight with it. (Haskell in particular has a much more restrictive borrow checker than that of Rust: purity.)
    • pjmlp 11y ago
      I think you overestimate how willing most developers are to fight with the borrow checker instead of using actor libraries or task libraries (TPL, TBB, PPL, Fork-Join, Akka) instead. So far the Rust tricks with unsafe for certain data structures (e.g. double linked lists/DAGs) seem like fighting with the borrow checker. Or the issues to be solved with upcoming 1.3 changes for pattern matching.
      • pcwalton 11y ago
        > I think you overestimate how willing most developers are to fight with the borrow checker instead of using actor libraries or task libraries (TPL, TBB, PPL, Fork-Join, Akka) instead. That seems like a non-sequitur. What does the borrow checker have to do with actor libraries? Are you implying that these actor libraries give you the data race freedom guarantees that Rust's mutability rules give you? If so, that's trivially false. Those libraries guide you toward patterns that eliminate data races in simple cases if you follow them, but nothing enforces the rules. Moreover, being forced into actors or message passing for concurrency severely restricts the expressiveness of your program. Rust's approach lets you use shared memory if you like, or message passing if you like, or a combination of the two, with enforcement of the rules no matter which you pick. > So far the Rust tricks with unsafe for certain data structures (e.g. double linked lists/DAGs) seem like fighting with the borrow checker. Or the issues to be solved with upcoming 1.3 changes for pattern matching. Yes, they're tough. This is a downside of manual memory management (though one that can be improved in future iterations). But doubly linked lists/tree-like data structures are hard in Haskell too. "Tying the knot" is not exactly easy or intuitive.
• rootlocus 11y ago
  > Ruby powers a bunch of high throughput websites yet it's notoriously 200x slower than any other language Have you considered the costs of the hardware that compensates for the software's slowness?
  • nitrogen 11y ago
    All that hardware is cheaper than a developer who can optimize the software without adding vulnerabilities. Plus Ruby/Rails apps rely very heavily on caching.
    • rootlocus 11y ago
      Considering the CPU architecture, everything relies heavily on caching. Not to mention it's the first thing any developer thinks about when performance is concerned. I'd be surprised to see any large application that doesn't rely heavily on some kind of caching.
    • txdv 11y ago
      Unless you go facebook. Then a performance improvement of 0.5% can be worth 100k a year.
• speleding 11y ago
  > But here comes Rust, it takes away the unsafety There are no memory leaks at the language level in Rust but lots of other unsafety exists in web apps at a higher level: SQL injections, XSS, etc. A battle hardened framework like Rails probably gives a safer end result until a Rust based framework is more mature.
  • steveklabnik 11y ago
    > There are no memory leaks at the language level in Rust Rust absolutely can leak memory, trivially. There's even a function that does it, http://doc.rust-lang.org/stable/std/mem/fn.forget.html http://doc.rust-lang.org/stable/std/mem/fn.forget.html
  • dbaupp 11y ago
    (To be clear: "memory safety" doesn't mean "freedom from memory leaks", it covers things like buffer overflows and use-after-free violations, https://en.wikipedia.org/wiki/Memory_safety https://en.wikipedia.org/wiki/Memory_safety .)