24 ms·

Rust is a hard way to make a web API

331 points by tmcw 6y ago

striking 6y ago
The point about GraphQL seems misdirected. GraphQL works fine with Postgres as long as you are using (working) dataloaders appropriately, I promise. I'm afraid I don't understand why a non-Postgres DB should be chosen for GraphQL here, or why it was necessary to mention in a Rust article.
- TheCoelacanth 6y ago
  Yeah, the complaints don't seem to have anything to do with GraphQL. Writing efficient SQL for GraphQL resolvers is more or less the same as writing efficient GraphQL for any application or API. If you just write all of your queries in the most naive way possible, you're going to have inefficient queries. If you pay attention to querying in an efficient way, you will be able to do it without too much difficulty.
smolder 6y ago
Yeah, unless I am building a very performance sensitive web service, either in terms of memory or CPU efficiency, js/typescript or some other web centric language is a much easier choice, and is less costly to build in. I'm still choosing to write some web stuff in Rust for the experience, for the fact I can compile parts to .wasm and re-use them in a browser too, I enjoy tuning things for performance, and I am not under time constraints for it.
- vector_spaces 6y ago
  What frameworks are recommended nowadays for Typescript? Is Express still dominant here or are there TS-first options?
  - runarberg 6y ago
    If you want static types you can still use typescript in JavaScript as doc comments. If you really want the syntax as well you can always compile your code down to javascript before. So express works just as well with typescript as it does with JavaScript
  - Azeralthefallen 6y ago
    nest.js is fantastic. https://nestjs.com/ https://nestjs.com/
    - ducharmdev 6y ago
      Agreed - trying out nest.js the first time gave me hope that we'd see something like Django for typescript/javascript. Especially paired with nx workspaces, with shared code between front & backend... so nice.
      - enumjorge 6y ago
        How's their authentication solution? Auth is such a critical component of most web apps, yet something that IMO a lot of web frameworks don't fully flesh out compared to how easy it is with Django. I took a quick look at their auth docs, and while the docs seem pretty detailed, I noticed it involves multiple packages (@nestjs/passport, passport, passport-local, and their corresponding types) that you then have to glue together into a full solution. The instructions also apparently only show you how to store passwords in plain text, and using something like bcrypt to do it yourself is an exercise left to the reader. Not rocket science, as this [1] (older) article pointed out, it's hard finding quality auth-related tutorials in the Node ecosystem. With Django a lot of this stuff is built-in and solidly implemented. Granted, this was after a quick look at the docs, so my impression might be off. [0] https://docs.nestjs.com/security/authentication https://docs.nestjs.com/security/authentication [1] https://hackernoon.com/your-node-js-authentication-tutorial-is-wrong-f1a3bf831a46 https://hackernoon.com/your-node-js-authentication-tutorial-...
        nicoburns 6y ago
        What do you find you get from auth libraries? I've always found them much more trouble than they're worth. But I feel like I must be missing something.
        Blahah 6y ago
        Passportjs is the standard across all these frameworks. It's modular by design, so you can easily compose the right auth system for your needs. I've always found it quite intuitive and I've never seen anything even nearly as comprehensive in any language. http://www.passportjs.org/ http://www.passportjs.org/
  - krono 6y ago
    Every single typescript oriented library that I've tried has had a pretty atrocious dev experience and no end of compatibility issues. I love typescript, but the ecosystem is without a doubt one of the biggest detractors.
    - girvo 6y ago
      NestJS is quite a bit better in that regard, but in general I agree with your overall point. What do you feel most of these frameworks are missing re. dev experience?
      - krono 6y ago
        Mostly use other languages for back-end systems, but I will definitely be checking out NestJS soon. With regards to TS, generally, it takes a lot of effort to get it to work. More often than not, getting to that point in a way that is actually useful/practical and cost effective, requires yet another library to be installed. Just look at the TSLint/ESLint migration problems, the popularity of all those TS runners such as ts-node/ts-node-dev/tsx-watch/ts-babel/etc., the complete lack of interoperability between all those separate pieces. Many issues and even proposed fixes to parts of the TS ecosystem - which is all community ran - are either ignored, left open because no one seems to be able to figure it out, or deemed to be out of scope. I don't know how to fix this honestly. Some leadership from Microsoft would be a good start.
        girvo 6y ago
        Yeah that’s fair: I’m a bit of an early adopter of Deno [0] for that reason, it helps standardise quite a bit of that. Promising, anyway, if a bit rough currently. [0] https://deno.land https://deno.land
        Kaze404 6y ago
        You don't need any of those. TSLint was deprecated long ago, and TS runners are only mildly useful in development (to the point where I don't bother and just `tsc && node dist`). Are you sure it's a problem with the ecosystem?
  - foolofatom 6y ago
    I've been using https://tsed.io/ https://tsed.io/ with great success.
    - zumu 6y ago
      I've been out of the JS/TS world for a couple years. Are decorators everywhere now? I will be very sad if so.
      - mssundaram 6y ago
        My experience is only n=3 but I've only rarely seen them where I've worked over the past 5 years. The only sane use case I've seen was for tagging logs and metrics.
      - pas 6y ago
        TSed has a great dependency injection system, and uses decorators for a few things, I did not find its use excessive.
  - girvo 6y ago
    I second the NestJS recommendation, but I’ve also got quite far using pretty stock standard Express style middleware with Deno. It’s been a fun experience.
  - simplify 6y ago
    Two I've been lightly following are Redwood[0] and Blitz[1]. Still a long ways behind something like Rails, but promising nonetheless. [0] https://github.com/blitz-js/blitz https://github.com/blitz-js/blitz [1] https://github.com/redwoodjs/redwood https://github.com/redwoodjs/redwood
  - joshxyz 6y ago
    My codes are written on JS but the sensitive parts are heavily commented with TS types so my vscode intellisense could assist me with correct types. /* * @type {Map<String, Number>} */ const map = new Map(); Like that. Express JS is still shit, koajs and fastify are a little better, I used to use nodejs's internal http and https libraries directly but these days uwebsockets.js is what you'd want since it's mature enough already (used by top crypto exchanges). https://github.com/uNetworking/uWebSockets.js/ https://github.com/uNetworking/uWebSockets.js/ And oh it comes with TS types which are cool.
- mleonhard 6y ago
  Is the JS/TS toolchain still a complicated undocumented mess? The last time I tried to use the JS/TS dev tools, I wasted many hours because the tools did zero validation of config files. All of the tools happily silently ignore misspelled config key names and invalid values. This makes simply debugging the tools a huge time sink.
- hda2 6y ago
  Pardon my ignorance, but how are you using .wasm in the browser? How are getting values out of the web assembly module?
  - jagged-chisel 6y ago
    JavaScript is used to fetch, initialize, and run the wasm module. As long as the module exports functions, they can be called from JS. There are JS libraries that will automatically setup up bindings for you.
  - ctr_ctr 6y ago
    https://rustwasm.github.io/wasm-bindgen/api/web_sys/ https://rustwasm.github.io/wasm-bindgen/api/web_sys/ Suit yourself
  - smolder 6y ago
    I used wasm bindgen to make rust code callable from js. https://rustwasm.github.io/docs/wasm-bindgen/ https://rustwasm.github.io/docs/wasm-bindgen/
- pjmlp 6y ago
  I can do the same with Java and .NET based languages.
  - smolder 6y ago
    Which part? Compiling to .wasm? Java to me is "old reliable" but carries a lot of baggage and leaves a bad taste in my mouth to read/write. C#.NET I have less experience with. Neither can quite match Rust for cpu/memory efficiency, but they definitely have their place being capable, accessible, and efficient languages with robust "ecosystems".
    - pjmlp 6y ago
      All of them, native code, wasm, whatever. Yes, they might not match Rust down to the microsecond or byte count, it doesn't matter in distributed computing. There are bigger fishes to fry as distributed computing problems. And Rust type system for preventing data races among threads doesn't help when what is being used is distributed IPC across a cluster nodes.
      - smolder 6y ago
        I understand where you're coming from. I hear the "bigger fish to fry" sentiment often. The point about distributed data races is a good one. At one point I did a comparison between a mono/Nancy web service and the same web service, feature for feature, built in NodeJS, Rust/rocket, and Go. I built a few different endpoints that did different types of work and load tested them, profiled memory usage, etc. I know mono and perhaps Nancy weren't the best point of comparison, and it's been some time since, but Rust/rocket really impressed me then, including on axes like ease of development and code readability. The perf deltas I saw could matter quite a bit at scale, allowing for fewer/cheaper servers. I've enjoyed using Rust for a few things since, personally, and am so far pretty unbothered by its shortcomings.
- rualca 6y ago
  > Yeah, unless I am building a very performance sensitive web service, either in terms of memory or CPU efficiency, js/typescript or some other web centric language is a much easier choice, and is less costly to build in. I really do not understand how convoluted javascript frameworks that require a thousand tools and checkers and dependencies just to put up a hello world are sold as "easier choices", specially when there is no mention of SPAs anywhere. Is it that hard to deliver static or dynamic HTML+CSS?
jph 6y ago
For Rust web APIs, Actix and Rocket are both very good. For adjunct pieces such as web app authentication, including some common features such as user sign up via email or phone, recover a password, multi-factor auth, social sign in, and the like, there's not yet a good solution (AFAIK). I will gladly donate money toward developers working on this, especially if it's something simple such as Elixir Phoenix `mix phx.gen.auth` doing a one-time setup with good defaults, then fully customizable.
- Klonoar 6y ago
  I've actually "ported" Django's auth system (including their email verification pieces) to actix-web, and reused it across a few projects. I've thought about open sourcing it, but the problem is... well, then you have to maintain it, and I'm not really interested in doing that. But if someone wants to take up the project I don't mind donating the code. If anyone ever saw my version years ago[1], it's effectively Jelly 2.0. [1] https://github.com/ryanmcgrath/jelly https://github.com/ryanmcgrath/jelly
  - monadic3 6y ago
    > I've thought about open sourcing it, but the problem is... well, then you have to maintain it I re-purpose abandoned code all the time. It's not a moral failing to release unfinished code, especially if you label it as such.
    - dbrgn 6y ago
      Yeah, dump it with a note that it's just for yourself and that you have no interest in maintaining it. Someone might take over! Otherwise, it may at least be an inspiration.
      - Klonoar 6y ago
        You say that like I didn’t do that in the past with Jelly. It’s not my first day. ;P I’ll consider dropping it later tonight or this weekend.
jayy-lmao 6y ago
I can agree with some of this up to a point. The stuff about compiler slowness is nothing new, and I will happily admit its one of my pain points for working in Rust. However for getting c++ish performance for a relatively high level syntax I think this fills a different niche than GC'd alternatives. The web-server libraries are still evolving, and I too would love to see a few crates designed for handling auth. A lot of the issues with difficulty writing/safe practice will just improve once there's more examples/books/tutorials. It takes a little for this stuff to catch up. Finally I really struggle to see the point about dataloaders - they may be a little confronting initially but its the same thing you often have to do in Nodejs. There's public examples on Github of how to use them with both Juniper and Async-Graphql. I can understand a lot of this as "its just not there yet". Rust has a much smaller community than Golang/Python/Js, I think its understandable if its taking a little longer to have equivalents in tooling etc. I still enjoy writing it
Animats 6y ago
Yes. That's what Go is for. Go is for doing the things that Google does on servers, which mostly means web apps of one kind of another. It has all the parts for that, and they're well-exercised because they're doing billions of operations per second on Google's own work. It's hard-compiled, so you don't have all the extra overhead of the interpreted languages. Also, Go has a better async story than most web-oriented systems. Goroutines, or "green threads", do both the job of threads and "async". In async land, if anything blocks or uses much CPU time, you're stalled. Not so in Go. A goroutine can block without stalling other goroutines. Right now, I'm writing a client for a virtual world in Rust. There's a big need for concurrency, but, unlike web stuff, it's all tightly interrelated. There's a GPU to keep busy. There's network traffic of several different kinds. There are compute-bound tasks which need to be kept out of the frame refresh loop. Rust is good for this. The existing C++ client is too much of a mess to make concurrent; people looked at it and gave up. In Rust, it's coming along nicely. Use the right tool for the job.
- nx7487 6y ago
  inb4 C++ brigade
- WClayFerguson 6y ago
  Actually not to pick a fight, but that's what "Java" is for. The only reason we have too many languages is because every software developer wants to create his own, and inevitably some will gain traction, and get popular enough to further fragment the industry. Imagine how awesome the world would be right now if all those kiddies had just focused their energy on making JAVA better. Java would be 1000x better, and would be the ONLY language. But nope, everybody knows best, and so now we have a "Tower of Babel" for a software industry.
  - damnyou 6y ago
    To put it plainly, Java is a fundamentally broken language and its mistakes, starting from not having sum/option/result types from day 1, make it impossible to fix. edit to respond: calling them "bells and whistles" is a deep misunderstanding of what sum types are. They profoundly change how every single piece of code in the language is written, starting from how nulls are handled, and cannot be retrofitted into an existing ecosystem. (You can add them later, but baking in sum types from the start is very different. In particular Java would not have its terrible exception system if it had sum types.)
hardwaregeek 6y ago
I agree with this article a lot. I wrote a comment on Rust for web previously that covers similar ground: https://news.ycombinator.com/item?id=23776855 https://news.ycombinator.com/item?id=23776855 One problem that I noticed, which may become a serious issue in the future, is that a lot of libraries add abstractions via macros. Macros don't always compose or debug well. I had some experiences getting errors in my macros that had extremely confusing debug messages, often pointing to files that didn't exist. Hopefully there will be a trend of moving back to plain old functions. Nom for instance has converted its combinators into regular functions, which I like a lot. I'd love love love for there to be a language that gets in between Rust and TypeScript. It'd have the strictness over mutability like Rust, but the GC of JS/TS. It wouldn't have 3+ string types. It'd have enum variants and pattern matching but maybe not macros. Gleam is pretty close!
- jklehm 6y ago
  dlang[0] as well perhaps. [0] https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...
- isubasinghe 6y ago
  > I'd love love love for there to be a language that gets in between Rust and TypeScript. I am really really keen on developing something like this, along with an optional linear type system. I think this would be a cool project for my thesis but also I have a lot on my plate already.
  - hardwaregeek 6y ago
    Definitely interested in talking more about this if you're down! Send me an email
    - isubasinghe 6y ago
      Ah I would be down if I can get it onto my thesis next semester. I can contact you in about 5 months, if thats ok
ketamine__ 6y ago
10 minutes to compile? Intense.
- jacquesm 6y ago
  It's one of the reasons I both love and hate interpreted languages: they're by far the fastest edit-test cycle available so they are super fast to get started but after a while and when your program becomes larger you always end up wishing you had more goodies to keep you from messing up.
  - brundolf 6y ago
    As I wrote in another comment, Rust's edit-test cycle is actually quite respectable thanks to the build cache. I've personally worked on a Rust web server with several significant-sized libraries, including Serde which was mentioned in the article as being pretty large, and turnaround time was 1-2 seconds for small edits to my own code (including the server startup time). I kept a watch script running that rebuilt and restarted on each change, and the experience was comparable to Express.
  - josephg 6y ago
    Me too! Its weird to me that people justify slow compilation times by pointing out how much work the compiler needs to do. And yet, if V8 can compile and launch my program in milliseconds, it seems like a similarly designed just-in-time rust compiler/interpretter should be able to do the same thing. I really hate that I needed to do this, but I recently acknowledged that my 2016 macbook pro just isn't fast enough for rust development to feel good. I replaced it with a ryzen 5800 based desktop workstation for dev work. With my new machine a full build of a rust project I've been working on dropped from 2 minutes down to 20 seconds. Its an absolute delight and I highly recommend doing the same if you're writing rust regularly and can afford it. Hopefully the next few years of CPU improvements will forgive our collective inability to engineer CPU-efficient compilers.
    - zozbot234 6y ago
      > And yet, if V8 can compile and launch my program in milliseconds, it seems like a similarly designed just-in-time rust compiler/interpretter should be able to do the same thing. Along these lines, Rust developers are working on adopting cranelift (a compiler framework used for JIT in Firefox) for quick debug builds, where runtime performance is not critical.
sheeshkebab 6y ago
As with all software languages and frameworks - they are good for some things, bad for everything else.
gameswithgo 6y ago
I am a big Rust enthusiast and I agree. It will be efficient and fast but it will he harder than using C#/Go etc
- ibraheemdev 6y ago
  Rust will always be harder than Go because Rust has an intentionally strict compiler. That said, there is a lot of progress to be made in this space. It doesn't make sense to write off Rust as being a contender for mainstream web development, as it is still in its early stages.
  - nicoburns 6y ago
    Harder, but much less monotonous.
    - ibraheemdev 6y ago
      Don't get me wrong, I love the borrow checker, but it takes time to get used to it, especially for those coming from simpler languages Node.js who may not understand the lower level concerns that the compiler is dealing with.
      - nicoburns 6y ago
        My observation (coming from NodeJS myself and hanging out on r/rust) is that those from an Java/C#/C background seem to struggle a lot more. They expect to be able to use patterns that you can't inplement in Rust. Whereas most JS developers are used to functionalish patterns with minimal mutable state already. Plus a lot of the things you can't do in Rust you also can't do in JS because it's simply too high level.
rcurry 6y ago
That’s why we have an easy way - just pull up IntelliJ, select Express App, and be done with it.
brundolf 6y ago
A few points: > Once your code is compiled, everything’s amazing! But in my case, this basic API - which wasn’t even feature-complete and was by no means a complex system - took more than ten minutes to compile...Caching helps as long as you don’t have to rebuild cached dependencies. The author glossed over that last part, but at least from a workflow perspective, the build cache makes a huge difference. In my experiments developing a web server in Rust, I used cargo-watch (https://github.com/passcod/cargo-watch https://github.com/passcod/cargo-watch) to automatically rebuild each time I made a change. The turnaround time was usually 1-2 seconds - nearly as fast as restarting a Node server, and about the same amount of time it takes me to alt-tab and test the change. I was using Serde, a high-level HTTP framework, and several other crates. It didn't matter, because they never had to be rebuilt. My own code was small, but still. > Rust makes you think about dimensions of your code that matter tremendously for systems programming...It makes you think about real but unlikely corner cases and make sure that they’re handled...These are all valid concerns. But for most web applications, they’re not the most important concerns. I disagree strongly (at least about corner cases). Maybe you don't want to bother with this stuff when you're still in the prototyping phase, but once a service is fairly well established, it's definitely beneficial to be forced to think about corner-cases (both in libraries/IO, and in your own business logic that you've hopefully modeled with Rust's powerful type system). Not only is your API usually the authoritative source of truth for your application/service, it's exposed to the whole internet by design, just begging to be prodded for logic holes. This IMO is one of Rust's main benefits; it's been called "the practical Haskell" before, and while its ecosystem isn't yet the most practical one for web servers, it is still much more so than Haskell's. > Lots of missing pieces This is the strongest point, in my opinion. Rust's web ecosystem is definitely still in the early days, and this is partly because Rust's benefits aren't nearly as extreme in this usecase as they are in other usecases. There is for sure a chicken-and-egg problem as not enough companies are using Rust for web servers, which means not as much time is getting invested in the relevant libraries. I hope this changes; I don't know for sure that it will. It feels like it is, but very slowly. That said: > Unfortunately, a lot of the incredibly exciting work in the Rust ecosystem has nothing to do with web application servers. There are some promising web frameworks - even a somewhat higher-level framework - but they’re undoubtedly in a niche. Even Actix, the main web framework, has a very top-heavy set of contributors. The author failed to mention or wasn't aware of Rocket (https://rocket.rs/ https://rocket.rs/), an up-and-coming Rust web framework that's extremely exciting and provides a programming experience strikingly similar to that of Flask or Express. It's still in 0.X releases, the current release doesn't build on stable rustc (though the master branch does!), you're still going to have a hard time finding SDKs for auth and payment and cloud, etc. But the important thing is that it shows what's possible. Web servers can be ergonomic to write in Rust, benefiting from its wonderful type system and performance, with very few sacrifices. We just need the ecosystem to catch up. Hopefully enough companies will realize the opportunity and that will happen. In summary: Yeah. Rust is a hard way to make a web API right now. But I don't think it has to be.
Groxx 6y ago
>The Rust ecosystem is not web-centric TBH I think this is the primary reason why Rust isn't as nice as e.g. Node. Convenient (and safe and decently performant) web libraries need to do a lot of complicated stuff under the hood, and the community hasn't (yet?) put in enough effort to reach parity with more web-oriented communities. (edit: I'm honestly kinda confused why this is getting downvoted so quickly. do people disagree that Rust can be nice?)
- ibraheemdev 6y ago
  I think the downvotes are because of this statement: > the community hasn't (yet?) put in enough effort to reach parity with more web-oriented communities Rust is a relatively new language, and these things take time. The community is amazing and is putting in a lot of effort, but you have to be patient.
  - Groxx 6y ago
    Totally agreed. IMO it's almost completely unreasonable to expect Rust to be as nice as more-established ecosystems, so it being "hard(er)" is expected. The community isn't as large nor has it existed as long, so of course it's not up to par yet. Given the community is generally more focused on performance and safety, I'd honestly expect it to take the Rust community longer to reach "nice for web projects" than e.g. Go and Node took.
  - randomdata 6y ago
    > Rust is a relatively new language It is approximately the same age as Go and Node. Unless there is something fundamental to Rust that prevents the creation of what the parent describes as a convenient web library, then not putting in enough effort yet to this point is the only reasonable explanation. And a good explanation at that, as it is understandable why convenient web libraries has not been Rust's focus. There are plenty of good tools for that job already. The Rust project seems to be more concerned about creating good tools in areas where good tools are currently lacking. If downvoting was supposed to send some kind of message, I'm not sure that would explain it. Of course, all downvoting tells is that someone accidentally hit a button when they were trying to scroll through the page, so this is all moot anyway.
rascul 6y ago
I've been writing rust for several years now and I still enjoy it. No other language has given me that satisfaction. I don't care if it's hard because, for me, it's the fun kind of hard.
- vallas 6y ago
  I like this mindset. What to do when time is critical tho?
- jariel 6y ago
  This is really interesting, I felt that at first, but not later. I think Rust may be a trap. The 'feeling of satisfaction' of making it work according to those strict rules, I think might be a kind of intellectual heroin for developers. I believe we may be vastly overestimating the value of that supposed 'correctness' - and also don't contemplate that it's only a specific kind of correctness. Developers are the kind of people that will naturally hone in on solving problems and building things, and our intuition may not be remotely attuned to necessarily creating value. We'll build some 'perfect thing' long before we build some 'useful thing'. I've become very skeptical of rust for this reason, it's so addictive to a certain personality type that I wonder if there is true reasoning behind the need for hyper strictness. I don't think we need Rust actually, I think we just needed a 'clean' version of C++ with some nicer things around pointers and that would have been fine. Edit: Should say I'm not against Rust, it's super cool, and likely has applications. I'm just skeptical of our reaction to it. I think it's 'borrow checker v1.0' and future languages may improve on that.
  - zip1234 6y ago
    Perhaps it matters where you are coming from? We are using Rust to replace C on embedded. It is a breath of fresh air for that. C++ will work for that, but is not a breath of fresh air. We are shipping better code much faster than the equivalent C.
  - zozbot234 6y ago
    > I don't think we need Rust actually, I think we just needed a 'clean' version of C++ with some nicer things around pointers and that would have been fine. The C++ community has tried this approach, and the outcome (viz. the C++ Core Guidelines) while definitely useful was far less "clean" than Rust itself. You're definitely right that some developers overestimate the need for complex solutions, but this failure mode seems rather more common in the C++ community and it's a bit weird to criticize Rust for it.
bestinterest 6y ago
On his point about payment gateways possibly being better for Rust I currently work in a system with a <10s SLA for a payment flow and boring old Java works fine with the whole Kafka/OpenShift/Microservice craze setup. And this setup runs through a bunch of microservices and talks to external API's. And even the real time messaging stuff? It probably depends on how real time you need, e.g WhatsApp is heavy on Elixir I believe and is the better choice for real time messaging due to its amazing actor concurrency model. Rust is a niche language for most programming domains imo but when you have a use case it really shines. But it also is such an attractive language because it brings out the engineer in all of us. The addicting process of optimizing every bit of code when in reality you probably should of just spun up a Rails app for your service and scaled horizontally eating your sadness of the performance engineer within yourself over the business logic that needs to get done yesterday.
- kuresov 6y ago
  FYI I believe WhatsApp was written in Erlang (Elixir uses the BEAM VM as well), but it was rewritten in C++ after Facebook bought it.
  - bcrosby95 6y ago
    Not true. Facebook Chat was written in Erlang and re-written in C++. This seems to confuse a lot of people. And in fact, Facebook is working on a statically typed version of Erlang. https://elixirforum.com/t/facebook-is-writing-a-new-statically-typed-language-to-run-on-the-beam/29829/34 https://elixirforum.com/t/facebook-is-writing-a-new-statical...
- jariel 6y ago
  I think it brings out the OCD in all of us, because we're apt to believe that the 'hard correctness' is somehow a thing of value. We climbed the mountain and believe that's what 'makes it better' but it may very well be irrelevant. As you say, Java is so often actually 'better' in the big picture.
snicksnak 6y ago
https://www.arewewebyet.org/ https://www.arewewebyet.org/
brink 6y ago
I don't blame anyone for wanting one language that solves everything. Rust is already good at so many things. I too want Rust and web to be better than it is. My day job consists of a hybrid of Rust/React/JS/CSS/HTML/Ruby/Rails/SQL (in no particular order). I don't like having to remember so much. I would love to see one language be the best at everything, but I doubt that will ever happen.
- Tade0 6y ago
  I'm curious: how does one find such a job? I've been doing mostly front-end work for the past decade and I could use some variety.
  - cube00 6y ago
    Smaller companies typically have this because they can't afford two separate frontend and backend teams because if they did neither team would have the critical mass to cover staff when on leave.
  - brink 6y ago
    I work for a tiny startup.
karulont 6y ago
> Heck, if you ask some people, Rust is less secure than a GC’ed language for web apps if you use any crates that have unsafe code - which includes Actix, the most popular web framework, because unsafe code allows things like deferencing raw pointers. The presence of _unsafe_ is okay, it just means that this is a part of code, that the compiler cannot verify itself. Usually the unsafe part (verified by human) is wrapped in a API that is safe to use. PS: You can still have memory leaks in GC-d languages by reference cycles.
- Const-me 6y ago
  > The presence of _unsafe_ is okay I don’t think so. It explodes the attack surface. In safe languages like C# or Java there’s no unsafe anywhere, not even in standard libraries. These runtimes are safe all the way down. The only attack surface is the VM itself, but these are very small only a handful of instructions, and are tested and audited really well. > You can still have memory leaks in GC-d languages by reference cycles. No, you can’t. All modern garbage collectors collect reference cycles just fine. They don’t just count references; they actually traverse these graphs.
  - nicoburns 6y ago
    C# actually has unsafe too. And it's pretty common in both of these languages for there to be C libraries involved somewhere in the stack.
    - Const-me 6y ago
      > C# actually has unsafe too. An optional feature. Very useful for embedded and similar, but for general-purpose stuff like the web you never need anything unsafe. > it's pretty common in both of these languages for there to be C libraries involved somewhere in the stack. Negative. The complete stack is open source. You can browse the source code of the standard library at https://source.dot.net/ https://source.dot.net/ You only gonna find unsafe/dllimport for IO parts of that library where they integrate with file systems and such. All their core components are 100% managed code.
juststeve 6y ago
Yes, and this article proposes no solutions and is kind of whinge-y. edit: downvotes? ok, got it.
filereaper 6y ago
Most of the author's article comes down a disagreement of values between what the author values and what Rust's language engineers value, and that's perfectly okay. I highly encourage everyone to watch Steve Klabnik's video on how Rust Views Tradeoffs [1] Rust has these core values that they refuse to compromise on in this order of precedence: - Memory Safety - Speed (compiled binary execution speed, not compile time) - Productivity And because of these core values, other aspects emerge such as the long compile time as they value memory safety as the language's highest core value and are accepting the tradeoff of long compile times. The talk goes on to say, we should ourselves reflect and ask what our core values are that we can't compromise on? What are the secondary values and so on... And then find the language/tool that lines up with our values. I really can't emphasize enough to go watch the talk. [1] https://www.youtube.com/watch?v=2ajos-0OWts https://www.youtube.com/watch?v=2ajos-0OWts
- vallas 6y ago
  Speed of the web can’t be a compromise. I guess interoperability with js or py is something to consider more in the Rust web battle.
- steveklabnik 6y ago
  Thanks so much!
  - deleted 6y ago
    [deleted]
ibraheemdev 6y ago
I agree that using Rust to build a web API is harder than in say Node/Rails/Django. However, you have to understand that Rust is a new language. Rails was first released in 2004 (and used in production before that) and Django in 2005. On the other hand, actix-web was first released in 2017, and the language itself went 1.0 just 5 years ago. The Rust web ecosystem is very young, and while there is a lot of work going on in this space, these things take time. Don't be too quick to judge - it doesn't make sense to write off Rust for mainstream web development yet.
- mtalantikite 6y ago
  All of this is important to point out, and I’d also add that async only hit stable Rust a little over a year ago! Over the past year Rust has finally felt like it’s in a good place to write web things in, which I find very exciting. I spent the summer in Rust, then in the Fall was back in a Go project, and I was really missing some Rust features when I had to make that switch (error handling with anyhow in particular!).
- nine_k 6y ago
  Something has to be said about the difference between CPU and RAM consumption of a service written in Python or Ruby, and written in Rust or C++. That ease of use has a cost.
epage 6y ago
> But Rust’s memory rules aren’t more secure than Node.js’s or Python’s. Your web application written in Rust isn’t going to be systematically more or less secure than an application in Python or Ruby. Just want to call out that I've heard a horror story of a very bad security bug due to implicit shared mutability in Python. (vague to protect the innocent) > Heck, if you ask some people, Rust is less secure than a GC’ed language for web apps if you use any crates that have unsafe code - which includes Actix, the most popular web framework, because unsafe code allows things like deferencing raw pointers. You can write unsafe code in Python (and some of the web frameworks use this) and nothing helps you with auditing it, unlike unsafe blocks in Rust.
- aidenn0 6y ago
  > > Heck, if you ask some people, Rust is less secure than a GC’ed language for web apps if you use any crates that have unsafe code - which includes Actix, the most popular web framework, because unsafe code allows things like deferencing raw pointers. > You can write unsafe code in Python (and some of the web frameworks use this) and nothing helps you with auditing it, unlike unsafe blocks in Rust. This was the dumbest part of TFA Python and Node both have parts of their runtimes, standard libraries, and extension libraries written in C and C++. Last time I checked, C and C++ allow dereferencing raw pointers.
- hckr1292 6y ago
  Yeah, the very type-centric programming flavor of the ecosystem and strict type checking in the compiler mean that Rust developers will generally leverage guarrantees from the Rust compiler for all sorts of interfaces that you would never do in Python or Nodejs. It's frankly annoying in the kind of web api context that this author is describing and is another source of lost productivity. So, Ruby has Rails, PHP has Drupal/Wordpress/etc, Python Django. However, neither Go nor Rust have a mature framework that makes it easy to spin up a CRUD app. I'm hopeful that some sort of project in Rust will rise up along the lines of Flaskrestplus in which resources are the primary abstractions. Resources could have codegen'd frontends built using something like react-admin so that you could build a fully functional web form in 100 loc or less. There's no reason the frontend bits couldn't be shared by Rust and Golang (and C++, D, Haskell, etc) frameworks.
tinselcity 6y ago
I wrote a REST-ful C++ http(s) server library with support for url routes/json etc: https://github.com/verizondigital/is2 https://github.com/verizondigital/is2 It's been useful for me if I've needed to use C++. It's similar to libmicrohttpd.
lovasoa 6y ago
If what you are building is a graphql crud api over a postgres database, you may be wasting your time, whatever language you are writing it in. This is a generic problem that doesn't need a custom solution. You can probably just install Hasura and move on to writing your business logic.
danbruder 6y ago
I’ve been building/maintaining a rust/graphql/postgres api for the last year with a moderately complex domain - it is very uneventful. That thing just works all the time. I don’t have to track down issues very often. It was harder to build for sure, but man it is a joy to work on.
LegNeato 6y ago
I'm the maintainer of Juniper. Juniper is a library, not a framework. As such it is agnostic to how you want to solve N+1. You get a lookahead and can do what you want...dataloader (like Facebook), eager loading all data up front (like Rails), generating efficient SQL on the fly (like prisma). There are projects and examples to do all three but we don't want to assume one solution is right for all domains. We take this to the extreme...Juniper doesn't even require a web server and isn't tied to a particular serialization format! Of course, we provide optional integrations with popular web frameworks using json but the key is they are optional.
CyberRabbi 6y ago
> Rust code can be just as fast as that C code, but protect that memory access, and without the cost of a garbage collector or some kind of runtime checking. Not technically true. Rust must do a runtime bounds check when it cannot prove that the input index goes above bounds at compile time
- EugeneOZ 6y ago
  No, it will just panic in such case.
  - Shoop 6y ago
    It needs to do a check in order to decide to panic. C/C++ just allow undefined behavior which means they don't need to bounds check because the generated code is allowed to have any behavior in this case (either the read just reads some random memory out of the heap or the kernel kills the process since it tried to access unmapped memory). In rust, panicing involves unwinding the stack. The compiler must generate code to do the bounds check and then also generate code to do the stack unwinding for the panic in the case where the bounds check fails.
    - wahern 6y ago
      In practice C code, especially well-written C code, will have most of the same bounds checks. It's not uncommon where a C programmer could safely omit a bounds check, but of course it's too often that the average C programmer mistakenly omits a bounds check or implements a bounds check wrong. See, e.g., the recent HN post, "Escaping VirtualBox 6.1", https://news.ycombinator.com/item?id=25795731 https://news.ycombinator.com/item?id=25795731 (https://secret.club/2021/01/14/vbox-escape.html https://secret.club/2021/01/14/vbox-escape.html).
      - CyberRabbi 6y ago
        Do you have data to support your claim? My experience runs counter to your claim. Its fairly common for core performance-sensitive rust code to use “unsafe” to avoid unnecessary checks that the compiler cannot automatically elide.
EugeneOZ 6y ago
I’m writing 5+ years REST APIs in Rust and this article was just ridiculous to read. Especially part about GraphQL.
vietvu 6y ago
I don't use C to make web API, the same for Rust. Not because it's impossible, but there are better suitable tools for the job.
tamalsaha001 6y ago
This sounds like an opportunity for someone to create a "rails/laravel/django" for Rust.
- ldiracdelta 6y ago
  They're trying. https://www.arewewebyet.org/ https://www.arewewebyet.org/
- EugeneOZ 6y ago
  The world should not suffer another one laravel.
- ibraheemdev 6y ago
  Wish me luck!
solson4 6y ago
In my spare time over the fall I put together a CRUD app to learn rust. Yew frontend and an actix/diesel backend. I must say, I actually really liked working with actix. There was a bit of a learning curve, but after I'd figured out the rust workflow, I felt very productive. Sure, could have gotten up and running faster in Django, but the rust app felt much more solid, like the compiler had my back. If there was something like Phoenix to help with the initial setup as others here have suggested, it would probably be my goto for this sort of thing. Yew on the other hand... it's got a ways to go before I would recommend it.
neilv 6y ago
> Rust has a fair number of web server frameworks, database connectors, and parsers. But building authentication? Oddly enough, this was the exact missing off-the-shelf piece -- traditional built-in Web authn&autho, not OAuth2/OpenID/etc. -- that last week made me (reluctantly) abandon plans to use Rust for a rapid Web backend project, and at least delay trying to do most of our new software work in Rust. The Web authn was sorta the last straw, on top of enough additional known-extra-work and known-uncertainties, so I couldn't justify going Rust at this point, for our needs right now. I decided I had to go with a framework and language that was already heavily proven (if boring) for this kind of application (and, incidentally, one of the framework's off-the-shelf authn&autho packages turned out to be a breeze to use, so far). (Were I doing a brand new startup demo/MVP, or an R&D project within a comfortably established company, I might've taken on additional risk here, and tried to power through the extra work and unknowns, but we are an early startup nevertheless in B2B critical production already.) (One reason not using Rust yet was disappointing to me is, just as I'd personally prefer to be mastering Rust right now, using Rust would be a recruiting carrot, somewhat like beloved fringe language Lisp/Scheme/Racket/OCaml/Haskell/etc. would be. I could also see Rust soon letting us do all our backend, much of Web frontend, embedded/appliance systems with device interfacing and some creative networking, and even mobile apps, rather than the mix of too many languages we have now. And I also suspected that most developers we'd hire would end up creating fewer defects in Rust code, since language semantics and static checking would force us to think harder before the alternative led to runtime failures, and/or to encumbering our ability to evolve things fast without breaking production.) (I'd probably enjoy the job of helping build out the platform/ecosystem of Rust or another newish interesting language I liked. I've done building-out before, including lots of authn from scratch. And of course sometimes it makes sense, in the context of a project in one platform, to build generic pieces that would be off-the-shelf in some other platforms; but other times that makes less sense.)
ldiracdelta 6y ago
My experience parallels the writer's... I did a foray over the holidays to try to make some base-layer and generic on top of rocket then actix-web then tide. I can get any of their toy examples to work, but building up a complex system with mixins to genericize some boiler plate code wasn't possible for my tiny brain. I may be hide-bound, but the lack of inheritance is a pain. I know I'm not right, but OO inheritance solves some problems well. In the django ecosystem, I can take an existing component with a vast API surface, inherit from it, tweak a tiny part of it and then put it back in the system and I'm off to the races. With rust, you have to re-implement the entire API surface to experiment with a tweak or go upstream and modify the original source, which isn't a great long-term solution -- maintaining patches. The diesel ORM is great, but it seems that each api returns a different type and doing a builder pattern generically across different functions and getting the types correct is like being in the worst C++ templating hell. I love the speed of execution, the type checking, the borrow checker, but the coding friction is real. I'd love to see more complex examples in all the rust web frameworks that do real work with good function partitioning in addition to the simple examples.
- ibraheemdev 6y ago
  > The diesel ORM is great, but it seems that each api returns a different type and doing a builder pattern generically across different functions and getting the types correct is like being in the worst C++ templating hell. Diesel provides the `into_boxed` method [0] for composing queries. [0]: https://docs.diesel.rs/diesel/query_dsl/trait.QueryDsl.html#method.into_boxed https://docs.diesel.rs/diesel/query_dsl/trait.QueryDsl.html#...
thayne 6y ago
Regarding compile times, if you are considering rust you probably want it to be fast at runtime, and are willing to put up with a slower compile time to get that. That said, 10 minutes seems like a long time for a simple api unless you are using a lot of procedural macros or something. Regarding safety, rust's lifetime system protects you against more than just preventing the invalid memory accesses, which GC languages also do. But several classes of race conditions that are easy to introduce in almost any other multi-threaded language are impossible in rust's type system (unless there is incorrect unsafe code). And in a web app with high levels of concurrency, that is kind of important.
nprateem 6y ago
Rust should have a GC mode where you can forget about the borrow checker and just write code like in Go, etc. I don't want to invest my time learning a language that only justifies its complexity in certain high performance use cases. If Rust was able to go into a GC mode I'd use it more, and then I'd already know it on those rare occasions performance was critical.
pjmlp 6y ago
Rust is a good language for low level systems programming, like C++ is being used in mobile OSes. For anything else, just use a language with automatic memory management and tooling capable of doing AOT/JIT compilation. Doing it in Rust while doable, feels more like trying to prove a point than doing any kind of usable work at scale.
smonff 6y ago
Don't believe the hype. Rust and Go are nice, but 95% of the time you don't need those. Especially when I read about the fact that it is "developed by Google for their own needs", I mean, you surely not work for Google. Same with React: you are (maybe) not a Facebook engineer that must work on one of the most complex front end of the world. Just use stuff that works, and that most people already know. Python, Perl, Ruby, jQuery, PHP, etc. Any of those have all the tools you need, proper documentation, millions of Stack Overflow discussions, and exceptional ecosystems and communities. I am a Perl enthusiast since more than ten years. Personnal opinion, feel free to ignore it. It got the incredible [Mojolicious](https://mojolicious.org https://mojolicious.org) framework that makes possible to deploy a full API through a oneliner. I know everybody hates Perl (especially for web development), but I am really tired of all the re-inventing the wheels. I would never study another languages. I am forty. I am tired.
- rualca 6y ago
  > Just use stuff that works, and that most people already know. Python, Perl, Ruby, jQuery, PHP, etc. Any of those have all the tools you need, proper documentation, millions of Stack Overflow discussions, and exceptional ecosystems and communities. Most of the stuff you mentioned is also highly inefficient and requires much more computational resources to reach the same level of service. Java is also conspicuously missing from that list, even though it has a solid infrastructure and ecosystem.
  - smonff 6y ago
    Inefficient for what? Are Perl regexps inefficient? No, they are the best. Isn't Python's Django efficient at producing full web applications in no-time with decent performances and that can be maintainable? Maybe you are speaking of the way jQuery don't work at managing the reactive interfaces of half of the websites since 2006? Who spoke of efficiency. Everything is inefficient. Are cars efficient? No. You use less time at walking your way than using a car and working to pay your car. Plus they are dirty. I have to admit that I forgot Java that have the most efficient object system in the world: btw I got trained on it and spent half of my career coding Java. I just tried to quote stuff I wasn't familiar with.
luizparreira 6y ago
Rust certainly wasn't created with web development in mind. But the developers of the language and libraries made it simple and nice enough that its constructs are very close to what you would call a high-level language. I have been using rust for my company's project backend server and even though I don't have all the libs that I need as crates, they are simple enough that I can code them myself. I wouldn't choose any other language, the sheer peace-of-mind Rust and its compiler gives me when my build is successful and my tests pass is hard to give up. Rust is awesome and I expect most of the web dev frameworks to be built in the next 5 years, I hope my company is able to help with that :)
mwcampbell 6y ago
> Some people will say well, X language is so good you can just write an SDK yourself in a weekend! To which I must reply, no. This is what has me contemplating moving away from Elixir. The top three web back-end languages, judging by the availability of certain SDKs, seem to be Python, Java, and JS (via Node). Now I just have to choose between those three, for a full-stack, mostly server-rendered, web app.
vallas 6y ago
Anyone talking about new NodeJS: Deno.land, written in Rust?

331 points by tmcw 6y ago

The point about GraphQL seems misdirected. GraphQL works fine with Postgres as long as you are using (working) dataloaders appropriately, I promise. I'm afraid I don't understand why a non-Postgres DB should be chosen for GraphQL here, or why it was necessary to mention in a Rust article.

TheCoelacanth 6y ago
Yeah, the complaints don't seem to have anything to do with GraphQL. Writing efficient SQL for GraphQL resolvers is more or less the same as writing efficient GraphQL for any application or API. If you just write all of your queries in the most naive way possible, you're going to have inefficient queries. If you pay attention to querying in an efficient way, you will be able to do it without too much difficulty.

smolder 6y ago

Yeah, unless I am building a very performance sensitive web service, either in terms of memory or CPU efficiency, js/typescript or some other web centric language is a much easier choice, and is less costly to build in. I'm still choosing to write some web stuff in Rust for the experience, for the fact I can compile parts to .wasm and re-use them in a browser too, I enjoy tuning things for performance, and I am not under time constraints for it.

vector_spaces 6y ago
What frameworks are recommended nowadays for Typescript? Is Express still dominant here or are there TS-first options?
- runarberg 6y ago
  If you want static types you can still use typescript in JavaScript as doc comments. If you really want the syntax as well you can always compile your code down to javascript before. So express works just as well with typescript as it does with JavaScript
- Azeralthefallen 6y ago
  nest.js is fantastic. https://nestjs.com/ https://nestjs.com/
  - ducharmdev 6y ago
    Agreed - trying out nest.js the first time gave me hope that we'd see something like Django for typescript/javascript. Especially paired with nx workspaces, with shared code between front & backend... so nice.
    - enumjorge 6y ago
      How's their authentication solution? Auth is such a critical component of most web apps, yet something that IMO a lot of web frameworks don't fully flesh out compared to how easy it is with Django. I took a quick look at their auth docs, and while the docs seem pretty detailed, I noticed it involves multiple packages (@nestjs/passport, passport, passport-local, and their corresponding types) that you then have to glue together into a full solution. The instructions also apparently only show you how to store passwords in plain text, and using something like bcrypt to do it yourself is an exercise left to the reader. Not rocket science, as this [1] (older) article pointed out, it's hard finding quality auth-related tutorials in the Node ecosystem. With Django a lot of this stuff is built-in and solidly implemented. Granted, this was after a quick look at the docs, so my impression might be off. [0] https://docs.nestjs.com/security/authentication https://docs.nestjs.com/security/authentication [1] https://hackernoon.com/your-node-js-authentication-tutorial-is-wrong-f1a3bf831a46 https://hackernoon.com/your-node-js-authentication-tutorial-...
      - nicoburns 6y ago
        What do you find you get from auth libraries? I've always found them much more trouble than they're worth. But I feel like I must be missing something.
      - Blahah 6y ago
        Passportjs is the standard across all these frameworks. It's modular by design, so you can easily compose the right auth system for your needs. I've always found it quite intuitive and I've never seen anything even nearly as comprehensive in any language. http://www.passportjs.org/ http://www.passportjs.org/
- krono 6y ago
  Every single typescript oriented library that I've tried has had a pretty atrocious dev experience and no end of compatibility issues. I love typescript, but the ecosystem is without a doubt one of the biggest detractors.
  - girvo 6y ago
    NestJS is quite a bit better in that regard, but in general I agree with your overall point. What do you feel most of these frameworks are missing re. dev experience?
    - krono 6y ago
      Mostly use other languages for back-end systems, but I will definitely be checking out NestJS soon. With regards to TS, generally, it takes a lot of effort to get it to work. More often than not, getting to that point in a way that is actually useful/practical and cost effective, requires yet another library to be installed. Just look at the TSLint/ESLint migration problems, the popularity of all those TS runners such as ts-node/ts-node-dev/tsx-watch/ts-babel/etc., the complete lack of interoperability between all those separate pieces. Many issues and even proposed fixes to parts of the TS ecosystem - which is all community ran - are either ignored, left open because no one seems to be able to figure it out, or deemed to be out of scope. I don't know how to fix this honestly. Some leadership from Microsoft would be a good start.
      - girvo 6y ago
        Yeah that’s fair: I’m a bit of an early adopter of Deno [0] for that reason, it helps standardise quite a bit of that. Promising, anyway, if a bit rough currently. [0] https://deno.land https://deno.land
      - Kaze404 6y ago
        You don't need any of those. TSLint was deprecated long ago, and TS runners are only mildly useful in development (to the point where I don't bother and just `tsc && node dist`). Are you sure it's a problem with the ecosystem?
- foolofatom 6y ago
  I've been using https://tsed.io/ https://tsed.io/ with great success.
  - zumu 6y ago
    I've been out of the JS/TS world for a couple years. Are decorators everywhere now? I will be very sad if so.
    - mssundaram 6y ago
      My experience is only n=3 but I've only rarely seen them where I've worked over the past 5 years. The only sane use case I've seen was for tagging logs and metrics.
    - pas 6y ago
      TSed has a great dependency injection system, and uses decorators for a few things, I did not find its use excessive.
- girvo 6y ago
  I second the NestJS recommendation, but I’ve also got quite far using pretty stock standard Express style middleware with Deno. It’s been a fun experience.
- simplify 6y ago
  Two I've been lightly following are Redwood[0] and Blitz[1]. Still a long ways behind something like Rails, but promising nonetheless. [0] https://github.com/blitz-js/blitz https://github.com/blitz-js/blitz [1] https://github.com/redwoodjs/redwood https://github.com/redwoodjs/redwood
- joshxyz 6y ago
  My codes are written on JS but the sensitive parts are heavily commented with TS types so my vscode intellisense could assist me with correct types. /* * @type {Map<String, Number>} */ const map = new Map(); Like that. Express JS is still shit, koajs and fastify are a little better, I used to use nodejs's internal http and https libraries directly but these days uwebsockets.js is what you'd want since it's mature enough already (used by top crypto exchanges). https://github.com/uNetworking/uWebSockets.js/ https://github.com/uNetworking/uWebSockets.js/ And oh it comes with TS types which are cool.
mleonhard 6y ago
Is the JS/TS toolchain still a complicated undocumented mess? The last time I tried to use the JS/TS dev tools, I wasted many hours because the tools did zero validation of config files. All of the tools happily silently ignore misspelled config key names and invalid values. This makes simply debugging the tools a huge time sink.
hda2 6y ago
Pardon my ignorance, but how are you using .wasm in the browser? How are getting values out of the web assembly module?
- jagged-chisel 6y ago
  JavaScript is used to fetch, initialize, and run the wasm module. As long as the module exports functions, they can be called from JS. There are JS libraries that will automatically setup up bindings for you.
- ctr_ctr 6y ago
  https://rustwasm.github.io/wasm-bindgen/api/web_sys/ https://rustwasm.github.io/wasm-bindgen/api/web_sys/ Suit yourself
- smolder 6y ago
  I used wasm bindgen to make rust code callable from js. https://rustwasm.github.io/docs/wasm-bindgen/ https://rustwasm.github.io/docs/wasm-bindgen/
pjmlp 6y ago
I can do the same with Java and .NET based languages.
- smolder 6y ago
  Which part? Compiling to .wasm? Java to me is "old reliable" but carries a lot of baggage and leaves a bad taste in my mouth to read/write. C#.NET I have less experience with. Neither can quite match Rust for cpu/memory efficiency, but they definitely have their place being capable, accessible, and efficient languages with robust "ecosystems".
  - pjmlp 6y ago
    All of them, native code, wasm, whatever. Yes, they might not match Rust down to the microsecond or byte count, it doesn't matter in distributed computing. There are bigger fishes to fry as distributed computing problems. And Rust type system for preventing data races among threads doesn't help when what is being used is distributed IPC across a cluster nodes.
    - smolder 6y ago
      I understand where you're coming from. I hear the "bigger fish to fry" sentiment often. The point about distributed data races is a good one. At one point I did a comparison between a mono/Nancy web service and the same web service, feature for feature, built in NodeJS, Rust/rocket, and Go. I built a few different endpoints that did different types of work and load tested them, profiled memory usage, etc. I know mono and perhaps Nancy weren't the best point of comparison, and it's been some time since, but Rust/rocket really impressed me then, including on axes like ease of development and code readability. The perf deltas I saw could matter quite a bit at scale, allowing for fewer/cheaper servers. I've enjoyed using Rust for a few things since, personally, and am so far pretty unbothered by its shortcomings.
rualca 6y ago
> Yeah, unless I am building a very performance sensitive web service, either in terms of memory or CPU efficiency, js/typescript or some other web centric language is a much easier choice, and is less costly to build in. I really do not understand how convoluted javascript frameworks that require a thousand tools and checkers and dependencies just to put up a hello world are sold as "easier choices", specially when there is no mention of SPAs anywhere. Is it that hard to deliver static or dynamic HTML+CSS?

jph 6y ago

For Rust web APIs, Actix and Rocket are both very good. For adjunct pieces such as web app authentication, including some common features such as user sign up via email or phone, recover a password, multi-factor auth, social sign in, and the like, there's not yet a good solution (AFAIK). I will gladly donate money toward developers working on this, especially if it's something simple such as Elixir Phoenix `mix phx.gen.auth` doing a one-time setup with good defaults, then fully customizable.

Klonoar 6y ago
I've actually "ported" Django's auth system (including their email verification pieces) to actix-web, and reused it across a few projects. I've thought about open sourcing it, but the problem is... well, then you have to maintain it, and I'm not really interested in doing that. But if someone wants to take up the project I don't mind donating the code. If anyone ever saw my version years ago[1], it's effectively Jelly 2.0. [1] https://github.com/ryanmcgrath/jelly https://github.com/ryanmcgrath/jelly
- monadic3 6y ago
  > I've thought about open sourcing it, but the problem is... well, then you have to maintain it I re-purpose abandoned code all the time. It's not a moral failing to release unfinished code, especially if you label it as such.
  - dbrgn 6y ago
    Yeah, dump it with a note that it's just for yourself and that you have no interest in maintaining it. Someone might take over! Otherwise, it may at least be an inspiration.
    - Klonoar 6y ago
      You say that like I didn’t do that in the past with Jelly. It’s not my first day. ;P I’ll consider dropping it later tonight or this weekend.

jayy-lmao 6y ago

I can agree with some of this up to a point. The stuff about compiler slowness is nothing new, and I will happily admit its one of my pain points for working in Rust. However for getting c++ish performance for a relatively high level syntax I think this fills a different niche than GC'd alternatives. The web-server libraries are still evolving, and I too would love to see a few crates designed for handling auth. A lot of the issues with difficulty writing/safe practice will just improve once there's more examples/books/tutorials. It takes a little for this stuff to catch up. Finally I really struggle to see the point about dataloaders - they may be a little confronting initially but its the same thing you often have to do in Nodejs. There's public examples on Github of how to use them with both Juniper and Async-Graphql. I can understand a lot of this as "its just not there yet". Rust has a much smaller community than Golang/Python/Js, I think its understandable if its taking a little longer to have equivalents in tooling etc. I still enjoy writing it

Animats 6y ago

Yes. That's what Go is for. Go is for doing the things that Google does on servers, which mostly means web apps of one kind of another. It has all the parts for that, and they're well-exercised because they're doing billions of operations per second on Google's own work. It's hard-compiled, so you don't have all the extra overhead of the interpreted languages. Also, Go has a better async story than most web-oriented systems. Goroutines, or "green threads", do both the job of threads and "async". In async land, if anything blocks or uses much CPU time, you're stalled. Not so in Go. A goroutine can block without stalling other goroutines. Right now, I'm writing a client for a virtual world in Rust. There's a big need for concurrency, but, unlike web stuff, it's all tightly interrelated. There's a GPU to keep busy. There's network traffic of several different kinds. There are compute-bound tasks which need to be kept out of the frame refresh loop. Rust is good for this. The existing C++ client is too much of a mess to make concurrent; people looked at it and gave up. In Rust, it's coming along nicely. Use the right tool for the job.

nx7487 6y ago
inb4 C++ brigade
WClayFerguson 6y ago
Actually not to pick a fight, but that's what "Java" is for. The only reason we have too many languages is because every software developer wants to create his own, and inevitably some will gain traction, and get popular enough to further fragment the industry. Imagine how awesome the world would be right now if all those kiddies had just focused their energy on making JAVA better. Java would be 1000x better, and would be the ONLY language. But nope, everybody knows best, and so now we have a "Tower of Babel" for a software industry.
- damnyou 6y ago
  To put it plainly, Java is a fundamentally broken language and its mistakes, starting from not having sum/option/result types from day 1, make it impossible to fix. edit to respond: calling them "bells and whistles" is a deep misunderstanding of what sum types are. They profoundly change how every single piece of code in the language is written, starting from how nulls are handled, and cannot be retrofitted into an existing ecosystem. (You can add them later, but baking in sum types from the start is very different. In particular Java would not have its terrible exception system if it had sum types.)

hardwaregeek 6y ago

I agree with this article a lot. I wrote a comment on Rust for web previously that covers similar ground: https://news.ycombinator.com/item?id=23776855 https://news.ycombinator.com/item?id=23776855 One problem that I noticed, which may become a serious issue in the future, is that a lot of libraries add abstractions via macros. Macros don't always compose or debug well. I had some experiences getting errors in my macros that had extremely confusing debug messages, often pointing to files that didn't exist. Hopefully there will be a trend of moving back to plain old functions. Nom for instance has converted its combinators into regular functions, which I like a lot. I'd love love love for there to be a language that gets in between Rust and TypeScript. It'd have the strictness over mutability like Rust, but the GC of JS/TS. It wouldn't have 3+ string types. It'd have enum variants and pattern matching but maybe not macros. Gleam is pretty close!

jklehm 6y ago
dlang[0] as well perhaps. [0] https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...
isubasinghe 6y ago
> I'd love love love for there to be a language that gets in between Rust and TypeScript. I am really really keen on developing something like this, along with an optional linear type system. I think this would be a cool project for my thesis but also I have a lot on my plate already.
- hardwaregeek 6y ago
  Definitely interested in talking more about this if you're down! Send me an email
  - isubasinghe 6y ago
    Ah I would be down if I can get it onto my thesis next semester. I can contact you in about 5 months, if thats ok

ketamine__ 6y ago

10 minutes to compile? Intense.

jacquesm 6y ago
It's one of the reasons I both love and hate interpreted languages: they're by far the fastest edit-test cycle available so they are super fast to get started but after a while and when your program becomes larger you always end up wishing you had more goodies to keep you from messing up.
- brundolf 6y ago
  As I wrote in another comment, Rust's edit-test cycle is actually quite respectable thanks to the build cache. I've personally worked on a Rust web server with several significant-sized libraries, including Serde which was mentioned in the article as being pretty large, and turnaround time was 1-2 seconds for small edits to my own code (including the server startup time). I kept a watch script running that rebuilt and restarted on each change, and the experience was comparable to Express.
- josephg 6y ago
  Me too! Its weird to me that people justify slow compilation times by pointing out how much work the compiler needs to do. And yet, if V8 can compile and launch my program in milliseconds, it seems like a similarly designed just-in-time rust compiler/interpretter should be able to do the same thing. I really hate that I needed to do this, but I recently acknowledged that my 2016 macbook pro just isn't fast enough for rust development to feel good. I replaced it with a ryzen 5800 based desktop workstation for dev work. With my new machine a full build of a rust project I've been working on dropped from 2 minutes down to 20 seconds. Its an absolute delight and I highly recommend doing the same if you're writing rust regularly and can afford it. Hopefully the next few years of CPU improvements will forgive our collective inability to engineer CPU-efficient compilers.
  - zozbot234 6y ago
    > And yet, if V8 can compile and launch my program in milliseconds, it seems like a similarly designed just-in-time rust compiler/interpretter should be able to do the same thing. Along these lines, Rust developers are working on adopting cranelift (a compiler framework used for JIT in Firefox) for quick debug builds, where runtime performance is not critical.

sheeshkebab 6y ago

As with all software languages and frameworks - they are good for some things, bad for everything else.

gameswithgo 6y ago

I am a big Rust enthusiast and I agree. It will be efficient and fast but it will he harder than using C#/Go etc

ibraheemdev 6y ago
Rust will always be harder than Go because Rust has an intentionally strict compiler. That said, there is a lot of progress to be made in this space. It doesn't make sense to write off Rust as being a contender for mainstream web development, as it is still in its early stages.
- nicoburns 6y ago
  Harder, but much less monotonous.
  - ibraheemdev 6y ago
    Don't get me wrong, I love the borrow checker, but it takes time to get used to it, especially for those coming from simpler languages Node.js who may not understand the lower level concerns that the compiler is dealing with.
    - nicoburns 6y ago
      My observation (coming from NodeJS myself and hanging out on r/rust) is that those from an Java/C#/C background seem to struggle a lot more. They expect to be able to use patterns that you can't inplement in Rust. Whereas most JS developers are used to functionalish patterns with minimal mutable state already. Plus a lot of the things you can't do in Rust you also can't do in JS because it's simply too high level.

rcurry 6y ago

That’s why we have an easy way - just pull up IntelliJ, select Express App, and be done with it.

brundolf 6y ago

A few points: > Once your code is compiled, everything’s amazing! But in my case, this basic API - which wasn’t even feature-complete and was by no means a complex system - took more than ten minutes to compile...Caching helps as long as you don’t have to rebuild cached dependencies. The author glossed over that last part, but at least from a workflow perspective, the build cache makes a huge difference. In my experiments developing a web server in Rust, I used cargo-watch (https://github.com/passcod/cargo-watch https://github.com/passcod/cargo-watch) to automatically rebuild each time I made a change. The turnaround time was usually 1-2 seconds - nearly as fast as restarting a Node server, and about the same amount of time it takes me to alt-tab and test the change. I was using Serde, a high-level HTTP framework, and several other crates. It didn't matter, because they never had to be rebuilt. My own code was small, but still. > Rust makes you think about dimensions of your code that matter tremendously for systems programming...It makes you think about real but unlikely corner cases and make sure that they’re handled...These are all valid concerns. But for most web applications, they’re not the most important concerns. I disagree strongly (at least about corner cases). Maybe you don't want to bother with this stuff when you're still in the prototyping phase, but once a service is fairly well established, it's definitely beneficial to be forced to think about corner-cases (both in libraries/IO, and in your own business logic that you've hopefully modeled with Rust's powerful type system). Not only is your API usually the authoritative source of truth for your application/service, it's exposed to the whole internet by design, just begging to be prodded for logic holes. This IMO is one of Rust's main benefits; it's been called "the practical Haskell" before, and while its ecosystem isn't yet the most practical one for web servers, it is still much more so than Haskell's. > Lots of missing pieces This is the strongest point, in my opinion. Rust's web ecosystem is definitely still in the early days, and this is partly because Rust's benefits aren't nearly as extreme in this usecase as they are in other usecases. There is for sure a chicken-and-egg problem as not enough companies are using Rust for web servers, which means not as much time is getting invested in the relevant libraries. I hope this changes; I don't know for sure that it will. It feels like it is, but very slowly. That said: > Unfortunately, a lot of the incredibly exciting work in the Rust ecosystem has nothing to do with web application servers. There are some promising web frameworks - even a somewhat higher-level framework - but they’re undoubtedly in a niche. Even Actix, the main web framework, has a very top-heavy set of contributors. The author failed to mention or wasn't aware of Rocket (https://rocket.rs/ https://rocket.rs/), an up-and-coming Rust web framework that's extremely exciting and provides a programming experience strikingly similar to that of Flask or Express. It's still in 0.X releases, the current release doesn't build on stable rustc (though the master branch does!), you're still going to have a hard time finding SDKs for auth and payment and cloud, etc. But the important thing is that it shows what's possible. Web servers can be ergonomic to write in Rust, benefiting from its wonderful type system and performance, with very few sacrifices. We just need the ecosystem to catch up. Hopefully enough companies will realize the opportunity and that will happen. In summary: Yeah. Rust is a hard way to make a web API right now. But I don't think it has to be.

Groxx 6y ago

>The Rust ecosystem is not web-centric TBH I think this is the primary reason why Rust isn't as nice as e.g. Node. Convenient (and safe and decently performant) web libraries need to do a lot of complicated stuff under the hood, and the community hasn't (yet?) put in enough effort to reach parity with more web-oriented communities. (edit: I'm honestly kinda confused why this is getting downvoted so quickly. do people disagree that Rust can be nice?)

ibraheemdev 6y ago
I think the downvotes are because of this statement: > the community hasn't (yet?) put in enough effort to reach parity with more web-oriented communities Rust is a relatively new language, and these things take time. The community is amazing and is putting in a lot of effort, but you have to be patient.
- Groxx 6y ago
  Totally agreed. IMO it's almost completely unreasonable to expect Rust to be as nice as more-established ecosystems, so it being "hard(er)" is expected. The community isn't as large nor has it existed as long, so of course it's not up to par yet. Given the community is generally more focused on performance and safety, I'd honestly expect it to take the Rust community longer to reach "nice for web projects" than e.g. Go and Node took.
- randomdata 6y ago
  > Rust is a relatively new language It is approximately the same age as Go and Node. Unless there is something fundamental to Rust that prevents the creation of what the parent describes as a convenient web library, then not putting in enough effort yet to this point is the only reasonable explanation. And a good explanation at that, as it is understandable why convenient web libraries has not been Rust's focus. There are plenty of good tools for that job already. The Rust project seems to be more concerned about creating good tools in areas where good tools are currently lacking. If downvoting was supposed to send some kind of message, I'm not sure that would explain it. Of course, all downvoting tells is that someone accidentally hit a button when they were trying to scroll through the page, so this is all moot anyway.

rascul 6y ago

I've been writing rust for several years now and I still enjoy it. No other language has given me that satisfaction. I don't care if it's hard because, for me, it's the fun kind of hard.

vallas 6y ago
I like this mindset. What to do when time is critical tho?
jariel 6y ago
This is really interesting, I felt that at first, but not later. I think Rust may be a trap. The 'feeling of satisfaction' of making it work according to those strict rules, I think might be a kind of intellectual heroin for developers. I believe we may be vastly overestimating the value of that supposed 'correctness' - and also don't contemplate that it's only a specific kind of correctness. Developers are the kind of people that will naturally hone in on solving problems and building things, and our intuition may not be remotely attuned to necessarily creating value. We'll build some 'perfect thing' long before we build some 'useful thing'. I've become very skeptical of rust for this reason, it's so addictive to a certain personality type that I wonder if there is true reasoning behind the need for hyper strictness. I don't think we need Rust actually, I think we just needed a 'clean' version of C++ with some nicer things around pointers and that would have been fine. Edit: Should say I'm not against Rust, it's super cool, and likely has applications. I'm just skeptical of our reaction to it. I think it's 'borrow checker v1.0' and future languages may improve on that.
- zip1234 6y ago
  Perhaps it matters where you are coming from? We are using Rust to replace C on embedded. It is a breath of fresh air for that. C++ will work for that, but is not a breath of fresh air. We are shipping better code much faster than the equivalent C.
- zozbot234 6y ago
  > I don't think we need Rust actually, I think we just needed a 'clean' version of C++ with some nicer things around pointers and that would have been fine. The C++ community has tried this approach, and the outcome (viz. the C++ Core Guidelines) while definitely useful was far less "clean" than Rust itself. You're definitely right that some developers overestimate the need for complex solutions, but this failure mode seems rather more common in the C++ community and it's a bit weird to criticize Rust for it.

bestinterest 6y ago

On his point about payment gateways possibly being better for Rust I currently work in a system with a <10s SLA for a payment flow and boring old Java works fine with the whole Kafka/OpenShift/Microservice craze setup. And this setup runs through a bunch of microservices and talks to external API's. And even the real time messaging stuff? It probably depends on how real time you need, e.g WhatsApp is heavy on Elixir I believe and is the better choice for real time messaging due to its amazing actor concurrency model. Rust is a niche language for most programming domains imo but when you have a use case it really shines. But it also is such an attractive language because it brings out the engineer in all of us. The addicting process of optimizing every bit of code when in reality you probably should of just spun up a Rails app for your service and scaled horizontally eating your sadness of the performance engineer within yourself over the business logic that needs to get done yesterday.

kuresov 6y ago
FYI I believe WhatsApp was written in Erlang (Elixir uses the BEAM VM as well), but it was rewritten in C++ after Facebook bought it.
- bcrosby95 6y ago
  Not true. Facebook Chat was written in Erlang and re-written in C++. This seems to confuse a lot of people. And in fact, Facebook is working on a statically typed version of Erlang. https://elixirforum.com/t/facebook-is-writing-a-new-statically-typed-language-to-run-on-the-beam/29829/34 https://elixirforum.com/t/facebook-is-writing-a-new-statical...
jariel 6y ago
I think it brings out the OCD in all of us, because we're apt to believe that the 'hard correctness' is somehow a thing of value. We climbed the mountain and believe that's what 'makes it better' but it may very well be irrelevant. As you say, Java is so often actually 'better' in the big picture.

snicksnak 6y ago

https://www.arewewebyet.org/ https://www.arewewebyet.org/

brink 6y ago

I don't blame anyone for wanting one language that solves everything. Rust is already good at so many things. I too want Rust and web to be better than it is. My day job consists of a hybrid of Rust/React/JS/CSS/HTML/Ruby/Rails/SQL (in no particular order). I don't like having to remember so much. I would love to see one language be the best at everything, but I doubt that will ever happen.

Tade0 6y ago
I'm curious: how does one find such a job? I've been doing mostly front-end work for the past decade and I could use some variety.
- cube00 6y ago
  Smaller companies typically have this because they can't afford two separate frontend and backend teams because if they did neither team would have the critical mass to cover staff when on leave.
- brink 6y ago
  I work for a tiny startup.

karulont 6y ago

> Heck, if you ask some people, Rust is less secure than a GC’ed language for web apps if you use any crates that have unsafe code - which includes Actix, the most popular web framework, because unsafe code allows things like deferencing raw pointers. The presence of _unsafe_ is okay, it just means that this is a part of code, that the compiler cannot verify itself. Usually the unsafe part (verified by human) is wrapped in a API that is safe to use. PS: You can still have memory leaks in GC-d languages by reference cycles.

Const-me 6y ago
> The presence of _unsafe_ is okay I don’t think so. It explodes the attack surface. In safe languages like C# or Java there’s no unsafe anywhere, not even in standard libraries. These runtimes are safe all the way down. The only attack surface is the VM itself, but these are very small only a handful of instructions, and are tested and audited really well. > You can still have memory leaks in GC-d languages by reference cycles. No, you can’t. All modern garbage collectors collect reference cycles just fine. They don’t just count references; they actually traverse these graphs.
- nicoburns 6y ago
  C# actually has unsafe too. And it's pretty common in both of these languages for there to be C libraries involved somewhere in the stack.
  - Const-me 6y ago
    > C# actually has unsafe too. An optional feature. Very useful for embedded and similar, but for general-purpose stuff like the web you never need anything unsafe. > it's pretty common in both of these languages for there to be C libraries involved somewhere in the stack. Negative. The complete stack is open source. You can browse the source code of the standard library at https://source.dot.net/ https://source.dot.net/ You only gonna find unsafe/dllimport for IO parts of that library where they integrate with file systems and such. All their core components are 100% managed code.

juststeve 6y ago

Yes, and this article proposes no solutions and is kind of whinge-y. edit: downvotes? ok, got it.

filereaper 6y ago

Most of the author's article comes down a disagreement of values between what the author values and what Rust's language engineers value, and that's perfectly okay. I highly encourage everyone to watch Steve Klabnik's video on how Rust Views Tradeoffs [1] Rust has these core values that they refuse to compromise on in this order of precedence: - Memory Safety - Speed (compiled binary execution speed, not compile time) - Productivity And because of these core values, other aspects emerge such as the long compile time as they value memory safety as the language's highest core value and are accepting the tradeoff of long compile times. The talk goes on to say, we should ourselves reflect and ask what our core values are that we can't compromise on? What are the secondary values and so on... And then find the language/tool that lines up with our values. I really can't emphasize enough to go watch the talk. [1] https://www.youtube.com/watch?v=2ajos-0OWts https://www.youtube.com/watch?v=2ajos-0OWts

vallas 6y ago
Speed of the web can’t be a compromise. I guess interoperability with js or py is something to consider more in the Rust web battle.
steveklabnik 6y ago
Thanks so much!
- deleted 6y ago
  [deleted]

ibraheemdev 6y ago

I agree that using Rust to build a web API is harder than in say Node/Rails/Django. However, you have to understand that Rust is a new language. Rails was first released in 2004 (and used in production before that) and Django in 2005. On the other hand, actix-web was first released in 2017, and the language itself went 1.0 just 5 years ago. The Rust web ecosystem is very young, and while there is a lot of work going on in this space, these things take time. Don't be too quick to judge - it doesn't make sense to write off Rust for mainstream web development yet.

mtalantikite 6y ago
All of this is important to point out, and I’d also add that async only hit stable Rust a little over a year ago! Over the past year Rust has finally felt like it’s in a good place to write web things in, which I find very exciting. I spent the summer in Rust, then in the Fall was back in a Go project, and I was really missing some Rust features when I had to make that switch (error handling with anyhow in particular!).
nine_k 6y ago
Something has to be said about the difference between CPU and RAM consumption of a service written in Python or Ruby, and written in Rust or C++. That ease of use has a cost.

epage 6y ago

> But Rust’s memory rules aren’t more secure than Node.js’s or Python’s. Your web application written in Rust isn’t going to be systematically more or less secure than an application in Python or Ruby. Just want to call out that I've heard a horror story of a very bad security bug due to implicit shared mutability in Python. (vague to protect the innocent) > Heck, if you ask some people, Rust is less secure than a GC’ed language for web apps if you use any crates that have unsafe code - which includes Actix, the most popular web framework, because unsafe code allows things like deferencing raw pointers. You can write unsafe code in Python (and some of the web frameworks use this) and nothing helps you with auditing it, unlike unsafe blocks in Rust.

aidenn0 6y ago
> > Heck, if you ask some people, Rust is less secure than a GC’ed language for web apps if you use any crates that have unsafe code - which includes Actix, the most popular web framework, because unsafe code allows things like deferencing raw pointers. > You can write unsafe code in Python (and some of the web frameworks use this) and nothing helps you with auditing it, unlike unsafe blocks in Rust. This was the dumbest part of TFA Python and Node both have parts of their runtimes, standard libraries, and extension libraries written in C and C++. Last time I checked, C and C++ allow dereferencing raw pointers.
hckr1292 6y ago
Yeah, the very type-centric programming flavor of the ecosystem and strict type checking in the compiler mean that Rust developers will generally leverage guarrantees from the Rust compiler for all sorts of interfaces that you would never do in Python or Nodejs. It's frankly annoying in the kind of web api context that this author is describing and is another source of lost productivity. So, Ruby has Rails, PHP has Drupal/Wordpress/etc, Python Django. However, neither Go nor Rust have a mature framework that makes it easy to spin up a CRUD app. I'm hopeful that some sort of project in Rust will rise up along the lines of Flaskrestplus in which resources are the primary abstractions. Resources could have codegen'd frontends built using something like react-admin so that you could build a fully functional web form in 100 loc or less. There's no reason the frontend bits couldn't be shared by Rust and Golang (and C++, D, Haskell, etc) frameworks.

tinselcity 6y ago

I wrote a REST-ful C++ http(s) server library with support for url routes/json etc: https://github.com/verizondigital/is2 https://github.com/verizondigital/is2 It's been useful for me if I've needed to use C++. It's similar to libmicrohttpd.

lovasoa 6y ago

If what you are building is a graphql crud api over a postgres database, you may be wasting your time, whatever language you are writing it in. This is a generic problem that doesn't need a custom solution. You can probably just install Hasura and move on to writing your business logic.

danbruder 6y ago

I’ve been building/maintaining a rust/graphql/postgres api for the last year with a moderately complex domain - it is very uneventful. That thing just works all the time. I don’t have to track down issues very often. It was harder to build for sure, but man it is a joy to work on.

LegNeato 6y ago

I'm the maintainer of Juniper. Juniper is a library, not a framework. As such it is agnostic to how you want to solve N+1. You get a lookahead and can do what you want...dataloader (like Facebook), eager loading all data up front (like Rails), generating efficient SQL on the fly (like prisma). There are projects and examples to do all three but we don't want to assume one solution is right for all domains. We take this to the extreme...Juniper doesn't even require a web server and isn't tied to a particular serialization format! Of course, we provide optional integrations with popular web frameworks using json but the key is they are optional.

CyberRabbi 6y ago

> Rust code can be just as fast as that C code, but protect that memory access, and without the cost of a garbage collector or some kind of runtime checking. Not technically true. Rust must do a runtime bounds check when it cannot prove that the input index goes above bounds at compile time

EugeneOZ 6y ago
No, it will just panic in such case.
- Shoop 6y ago
  It needs to do a check in order to decide to panic. C/C++ just allow undefined behavior which means they don't need to bounds check because the generated code is allowed to have any behavior in this case (either the read just reads some random memory out of the heap or the kernel kills the process since it tried to access unmapped memory). In rust, panicing involves unwinding the stack. The compiler must generate code to do the bounds check and then also generate code to do the stack unwinding for the panic in the case where the bounds check fails.
  - wahern 6y ago
    In practice C code, especially well-written C code, will have most of the same bounds checks. It's not uncommon where a C programmer could safely omit a bounds check, but of course it's too often that the average C programmer mistakenly omits a bounds check or implements a bounds check wrong. See, e.g., the recent HN post, "Escaping VirtualBox 6.1", https://news.ycombinator.com/item?id=25795731 https://news.ycombinator.com/item?id=25795731 (https://secret.club/2021/01/14/vbox-escape.html https://secret.club/2021/01/14/vbox-escape.html).
    - CyberRabbi 6y ago
      Do you have data to support your claim? My experience runs counter to your claim. Its fairly common for core performance-sensitive rust code to use “unsafe” to avoid unnecessary checks that the compiler cannot automatically elide.

EugeneOZ 6y ago

I’m writing 5+ years REST APIs in Rust and this article was just ridiculous to read. Especially part about GraphQL.

vietvu 6y ago

I don't use C to make web API, the same for Rust. Not because it's impossible, but there are better suitable tools for the job.

tamalsaha001 6y ago

This sounds like an opportunity for someone to create a "rails/laravel/django" for Rust.

ldiracdelta 6y ago
They're trying. https://www.arewewebyet.org/ https://www.arewewebyet.org/
EugeneOZ 6y ago
The world should not suffer another one laravel.
ibraheemdev 6y ago
Wish me luck!

solson4 6y ago

In my spare time over the fall I put together a CRUD app to learn rust. Yew frontend and an actix/diesel backend. I must say, I actually really liked working with actix. There was a bit of a learning curve, but after I'd figured out the rust workflow, I felt very productive. Sure, could have gotten up and running faster in Django, but the rust app felt much more solid, like the compiler had my back. If there was something like Phoenix to help with the initial setup as others here have suggested, it would probably be my goto for this sort of thing. Yew on the other hand... it's got a ways to go before I would recommend it.

neilv 6y ago

> Rust has a fair number of web server frameworks, database connectors, and parsers. But building authentication? Oddly enough, this was the exact missing off-the-shelf piece -- traditional built-in Web authn&autho, not OAuth2/OpenID/etc. -- that last week made me (reluctantly) abandon plans to use Rust for a rapid Web backend project, and at least delay trying to do most of our new software work in Rust. The Web authn was sorta the last straw, on top of enough additional known-extra-work and known-uncertainties, so I couldn't justify going Rust at this point, for our needs right now. I decided I had to go with a framework and language that was already heavily proven (if boring) for this kind of application (and, incidentally, one of the framework's off-the-shelf authn&autho packages turned out to be a breeze to use, so far). (Were I doing a brand new startup demo/MVP, or an R&D project within a comfortably established company, I might've taken on additional risk here, and tried to power through the extra work and unknowns, but we are an early startup nevertheless in B2B critical production already.) (One reason not using Rust yet was disappointing to me is, just as I'd personally prefer to be mastering Rust right now, using Rust would be a recruiting carrot, somewhat like beloved fringe language Lisp/Scheme/Racket/OCaml/Haskell/etc. would be. I could also see Rust soon letting us do all our backend, much of Web frontend, embedded/appliance systems with device interfacing and some creative networking, and even mobile apps, rather than the mix of too many languages we have now. And I also suspected that most developers we'd hire would end up creating fewer defects in Rust code, since language semantics and static checking would force us to think harder before the alternative led to runtime failures, and/or to encumbering our ability to evolve things fast without breaking production.) (I'd probably enjoy the job of helping build out the platform/ecosystem of Rust or another newish interesting language I liked. I've done building-out before, including lots of authn from scratch. And of course sometimes it makes sense, in the context of a project in one platform, to build generic pieces that would be off-the-shelf in some other platforms; but other times that makes less sense.)

ldiracdelta 6y ago

My experience parallels the writer's... I did a foray over the holidays to try to make some base-layer and generic on top of rocket then actix-web then tide. I can get any of their toy examples to work, but building up a complex system with mixins to genericize some boiler plate code wasn't possible for my tiny brain. I may be hide-bound, but the lack of inheritance is a pain. I know I'm not right, but OO inheritance solves some problems well. In the django ecosystem, I can take an existing component with a vast API surface, inherit from it, tweak a tiny part of it and then put it back in the system and I'm off to the races. With rust, you have to re-implement the entire API surface to experiment with a tweak or go upstream and modify the original source, which isn't a great long-term solution -- maintaining patches. The diesel ORM is great, but it seems that each api returns a different type and doing a builder pattern generically across different functions and getting the types correct is like being in the worst C++ templating hell. I love the speed of execution, the type checking, the borrow checker, but the coding friction is real. I'd love to see more complex examples in all the rust web frameworks that do real work with good function partitioning in addition to the simple examples.

ibraheemdev 6y ago
> The diesel ORM is great, but it seems that each api returns a different type and doing a builder pattern generically across different functions and getting the types correct is like being in the worst C++ templating hell. Diesel provides the `into_boxed` method [0] for composing queries. [0]: https://docs.diesel.rs/diesel/query_dsl/trait.QueryDsl.html#method.into_boxed https://docs.diesel.rs/diesel/query_dsl/trait.QueryDsl.html#...

thayne 6y ago

Regarding compile times, if you are considering rust you probably want it to be fast at runtime, and are willing to put up with a slower compile time to get that. That said, 10 minutes seems like a long time for a simple api unless you are using a lot of procedural macros or something. Regarding safety, rust's lifetime system protects you against more than just preventing the invalid memory accesses, which GC languages also do. But several classes of race conditions that are easy to introduce in almost any other multi-threaded language are impossible in rust's type system (unless there is incorrect unsafe code). And in a web app with high levels of concurrency, that is kind of important.

nprateem 6y ago

Rust should have a GC mode where you can forget about the borrow checker and just write code like in Go, etc. I don't want to invest my time learning a language that only justifies its complexity in certain high performance use cases. If Rust was able to go into a GC mode I'd use it more, and then I'd already know it on those rare occasions performance was critical.

pjmlp 6y ago

Rust is a good language for low level systems programming, like C++ is being used in mobile OSes. For anything else, just use a language with automatic memory management and tooling capable of doing AOT/JIT compilation. Doing it in Rust while doable, feels more like trying to prove a point than doing any kind of usable work at scale.

smonff 6y ago

Don't believe the hype. Rust and Go are nice, but 95% of the time you don't need those. Especially when I read about the fact that it is "developed by Google for their own needs", I mean, you surely not work for Google. Same with React: you are (maybe) not a Facebook engineer that must work on one of the most complex front end of the world. Just use stuff that works, and that most people already know. Python, Perl, Ruby, jQuery, PHP, etc. Any of those have all the tools you need, proper documentation, millions of Stack Overflow discussions, and exceptional ecosystems and communities. I am a Perl enthusiast since more than ten years. Personnal opinion, feel free to ignore it. It got the incredible [Mojolicious](https://mojolicious.org https://mojolicious.org) framework that makes possible to deploy a full API through a oneliner. I know everybody hates Perl (especially for web development), but I am really tired of all the re-inventing the wheels. I would never study another languages. I am forty. I am tired.

rualca 6y ago
> Just use stuff that works, and that most people already know. Python, Perl, Ruby, jQuery, PHP, etc. Any of those have all the tools you need, proper documentation, millions of Stack Overflow discussions, and exceptional ecosystems and communities. Most of the stuff you mentioned is also highly inefficient and requires much more computational resources to reach the same level of service. Java is also conspicuously missing from that list, even though it has a solid infrastructure and ecosystem.
- smonff 6y ago
  Inefficient for what? Are Perl regexps inefficient? No, they are the best. Isn't Python's Django efficient at producing full web applications in no-time with decent performances and that can be maintainable? Maybe you are speaking of the way jQuery don't work at managing the reactive interfaces of half of the websites since 2006? Who spoke of efficiency. Everything is inefficient. Are cars efficient? No. You use less time at walking your way than using a car and working to pay your car. Plus they are dirty. I have to admit that I forgot Java that have the most efficient object system in the world: btw I got trained on it and spent half of my career coding Java. I just tried to quote stuff I wasn't familiar with.

luizparreira 6y ago

Rust certainly wasn't created with web development in mind. But the developers of the language and libraries made it simple and nice enough that its constructs are very close to what you would call a high-level language. I have been using rust for my company's project backend server and even though I don't have all the libs that I need as crates, they are simple enough that I can code them myself. I wouldn't choose any other language, the sheer peace-of-mind Rust and its compiler gives me when my build is successful and my tests pass is hard to give up. Rust is awesome and I expect most of the web dev frameworks to be built in the next 5 years, I hope my company is able to help with that :)

mwcampbell 6y ago

> Some people will say well, X language is so good you can just write an SDK yourself in a weekend! To which I must reply, no. This is what has me contemplating moving away from Elixir. The top three web back-end languages, judging by the availability of certain SDKs, seem to be Python, Java, and JS (via Node). Now I just have to choose between those three, for a full-stack, mostly server-rendered, web app.

vallas 6y ago

Anyone talking about new NodeJS: Deno.land, written in Rust?