8 ms·

Julia writes she wouldn’t yet use Rust to write webservices. Right there, this could be the mission for 2018. http://www.arewewebyet.org http://www.arewewebyet

by eecc 9y ago

Julia writes she wouldn’t yet use Rust to write webservices. Right there, this could be the mission for 2018. http://www.arewewebyet.org http://www.arewewebyet.org Nobody with a sane mind would write C or CPP micro-services, but post-Spectre and Meltdown any reclaim in performance is tangibility valuable. Rust could be the one to swoop in and claim the position

banachtarski 9y ago
> Nobody with a sane mind would write C or CPP micro-services why? I do this all the time. Maybe I should check into a nearby asylum.
- michaelchisari 9y ago
  It must depend on what you're building with it. I haven't seen any reason why it couldn't be used for serving up data for an api. But as far as using it as a full featured web framework, a la Rails, Django or even Laravel, I can see why people say it's got a long way to go. That said, I haven't built anything production or large scale in Rust, so I can't claim to be an expert.
- shadowmint 9y ago
  The point isn’t that no one does it, its that its hard to do right. ...and that is flat out the case for c++, unequivocally. In rust you’d expect it to be better, because of (reasons rust is good here, like safety, having a package manager and an ecosystem, etc etc), but practically, there are too many halfbaked solutions, too much ‘use nightly’ and few good stable proven solutions to look at. Rust isn’t the right solution for every problem, but it should be a good solution for secure very high performance network services. Its definitely a good goal for the year~
  - e12e 9y ago
    > ...and that is flat out the case for c++, unequivocally. Arguably, this is why Google made go. But I'm not sure c++ micro services are a terrible idea. I think the real problems come with a) feature creep as opposed to writing new micro services, and b) the temptation to write "fast" c++. Just writing plain obvious c++ should give you a leg up on most languages (esp for micro services). But then, rather than refactor and think about the algorithm and data structures (and get a 10x performance benefit from a simpler solution), you could probably get a 2x improvement from a more convoluted, "special" c++ implementation. And that's where you're likely to encounter elder horrors lurking. [ed: I'm however more and more convinced there's no such thing as "plain obvious c" that doesn't have a number of serious issues along the lines of not checking mallloc return values, to utf8 string handling etc.]
- fauigerzigerk 9y ago
  >Maybe I should check into a nearby asylum. If you do, make sure it says "believes in micro-services" on the referral ;-)
  - banachtarski 9y ago
    I just mentally edit "micro-services" to "services" any time I read it hehe.
    - StavrosK 9y ago
      What, do you edit the "web" out of "webscale" too? Certifiable.
    - paulddraper 9y ago
      And "REST" to "HTTP"
- raverbashing 9y ago
  Because your code has bugs and/or security vulnerabilities. It's pretty safe to assume this without looking at your code
  - kbwt 9y ago
    I wouldn't be so sure lower level code necessarily has more vulnerabilities. It's certainly easier to find the vulnerabilities because the attack vectors are well-known. Software written in higher level languages is often less widely deployed, so less people are trying to find vulnerabilities. All the complexity adds up, and can result in new vulnerabilities that wouldn't have been there if the code was written in a simpler language.
    - sambe 9y ago
      What complexity adds up?
  - civility 9y ago
    Heh, so does yours. I can say this without even knowing what language you use to write your software, much less looking at it... All software has bugs, and most of those are security vulnerabilities waiting to happen.
    - raverbashing 9y ago
      Of course. Code is hard. Using a safer language makes it easier and less prone to out-of-bounds memory accesses. By using C/C++ you're choosing to make a hard problem harder.
      - duneroadrunner 9y ago
        C++ does have a practical, memory-safe subset[1]. Recommended for anyone writing internet facing C++ code. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
      - 9y ago
- sebcat 9y ago
  I also do this. I make use of Capsicum/seccomp-bpf and jail/chroot to a ro mountpoint, use SSP, ASLR where possible, ... But I still use C as my primary programming language. I've also written code in golang professionally for a year or two. It's quite common in the embedded space to use C or C++. It's easy to run everything as root and skip fundamental bound checking, so those languages get a bad rep in that space. Totally understandable. But it is possible to engineer solutions that are a lot safer too. It's just a question of priorities. Companies not prioritizing writing safe code or not working on having a safe architectural design will not bother with Rust or other memory safe languages. There's little to no market incentive in most areas. Sad but true.
  - pjmlp 9y ago
    Even using C++ in embedded is an issue, mostly cultural. A common theme in the C++ community is to advocate C++ to devs that only see Assembly and C89, and don't see any reason to move beyond that. Most recent example "Embedded & C++ - Meeting 2017 Keynote" https://www.youtube.com/watch?v=mNPfsUZb3vs https://www.youtube.com/watch?v=mNPfsUZb3vs
curiousGambler 9y ago
I get the impression Go runs the microservice space. It's built for it and is incredibly fast despite the GC. I don't see Rust claiming that position anytime soon.
- eecc 9y ago
  Where I live and work, golang is only used at one major client (because they’re US based, the decision must have happened elsewhere.) Everything else is Spring Boot (java), Akka (Scala) or Nodejs. Apparently nobody wants to embrace a language designed for offshoring, so no Meetups, noisy user groups and so on... even Clojure is more popular
  - K0nserv 9y ago
    Golang is a language designed for offshoring? It was invented at one of the largest engineering orgs to be used in house
    - pjmlp 9y ago
      In the words of Rob Pike: "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1" "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike 2" So a language that makes it quite easy for enterprises to deal with developers as cogs. Source: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/From-Parallel-to-Concurrent http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fro... https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
      - foldr 9y ago
pjmlp 9y ago
Neither I think Rust is fit for that purpose, any GC language is a better fit in terms of productivity, unless we are speaking about tiny IoT devices with a few KBs. Also, it is not yet fit for writing GUI code. It is quite far from what is possible to achieve today in Qt/WPF/Cocoa/Android/... tooling and even the latest NLL improvements don't fix all issues regarding writing callbacks.
- rapsey 9y ago
  You're comparing a language to an OS and three GUI frameworks.
  - sho_hn 9y ago
    I think there's some merit to the statement nonetheless - e.g. Qt is native to C++ and its API designed around C++ language features and semantics in many ways. There has been success in writing bindings for languages that can emulate those semantics without too much pain (e.g. PyQt), but Rust is not one of them. Inside the Rust community, there's been a lot of debate about what an idiomatic Rust API for a GUI toolkit would look like, particularly because the traditional tree-of-widget-objects design of C++ GUI toolkits appears a bit inconvenient to realize within Rust's stricter semantics. IOW, "are we gui yet?" might depend on some sort of new written-in-Rust GUI toolkit to appear. There's 20 years of work by many hundreds of people in Qt, many of whom rallied not just around Qt specifically, but around projects using it. Getting that many people moving isn't easy. Alternatively, major progress has to be made on bindings and bridging to the semantics of other languages in Rust. That said - of course C++ was around quite a while before being adopted by Qt.
    - rapsey 9y ago
      Servo guys have the potential to make something amazing (i.e. a sane electron type library). But I'm not sure how much they care about that. Other then that there is nothing serious going on.
      - IshKebab 9y ago
Yuioup 9y ago
Just out of curiosity, how many web framework platform are originally written and compiled in C? CPython, udev, node, v8, ... rust?
- dmitriid 9y ago
  The platform may be written in C. The OS you're running microservices on is written in C/C++. It doesn't mean that your services are written in C/C++.
- Tuna-Fish 9y ago
  IIRC, the rust compiler started out as an OCaml project, but is now self-hosting.
  - steveklabnik 9y ago
    This is true.
Shoothe 9y ago
Thanks for mentioning the page. I'm about to write a simple JSON/HTTP service and decided to use Rust but I was wondering why the author would not use Rust for web services.
penetrarthur 9y ago
It is not about languages. It is mostly about frameworks. I want to write my next web project in a mature framework.
FridgeSeal 9y ago
I'm actually writing a lambda function in Rust at work right now! Whilst I could do it in Python, it was straightforward enough to be a good first thing to try with Rust and it's actually been easier to write than I anticipated. Plus the performance benefits will be nice.

by eecc 9y ago

banachtarski 9y ago

> Nobody with a sane mind would write C or CPP micro-services why? I do this all the time. Maybe I should check into a nearby asylum.

michaelchisari 9y ago
It must depend on what you're building with it. I haven't seen any reason why it couldn't be used for serving up data for an api. But as far as using it as a full featured web framework, a la Rails, Django or even Laravel, I can see why people say it's got a long way to go. That said, I haven't built anything production or large scale in Rust, so I can't claim to be an expert.
shadowmint 9y ago
The point isn’t that no one does it, its that its hard to do right. ...and that is flat out the case for c++, unequivocally. In rust you’d expect it to be better, because of (reasons rust is good here, like safety, having a package manager and an ecosystem, etc etc), but practically, there are too many halfbaked solutions, too much ‘use nightly’ and few good stable proven solutions to look at. Rust isn’t the right solution for every problem, but it should be a good solution for secure very high performance network services. Its definitely a good goal for the year~
- e12e 9y ago
  > ...and that is flat out the case for c++, unequivocally. Arguably, this is why Google made go. But I'm not sure c++ micro services are a terrible idea. I think the real problems come with a) feature creep as opposed to writing new micro services, and b) the temptation to write "fast" c++. Just writing plain obvious c++ should give you a leg up on most languages (esp for micro services). But then, rather than refactor and think about the algorithm and data structures (and get a 10x performance benefit from a simpler solution), you could probably get a 2x improvement from a more convoluted, "special" c++ implementation. And that's where you're likely to encounter elder horrors lurking. [ed: I'm however more and more convinced there's no such thing as "plain obvious c" that doesn't have a number of serious issues along the lines of not checking mallloc return values, to utf8 string handling etc.]
fauigerzigerk 9y ago
>Maybe I should check into a nearby asylum. If you do, make sure it says "believes in micro-services" on the referral ;-)
- banachtarski 9y ago
  I just mentally edit "micro-services" to "services" any time I read it hehe.
  - StavrosK 9y ago
    What, do you edit the "web" out of "webscale" too? Certifiable.
  - paulddraper 9y ago
    And "REST" to "HTTP"
raverbashing 9y ago
Because your code has bugs and/or security vulnerabilities. It's pretty safe to assume this without looking at your code
- kbwt 9y ago
  I wouldn't be so sure lower level code necessarily has more vulnerabilities. It's certainly easier to find the vulnerabilities because the attack vectors are well-known. Software written in higher level languages is often less widely deployed, so less people are trying to find vulnerabilities. All the complexity adds up, and can result in new vulnerabilities that wouldn't have been there if the code was written in a simpler language.
  - sambe 9y ago
    What complexity adds up?
- civility 9y ago
  Heh, so does yours. I can say this without even knowing what language you use to write your software, much less looking at it... All software has bugs, and most of those are security vulnerabilities waiting to happen.
  - raverbashing 9y ago
    Of course. Code is hard. Using a safer language makes it easier and less prone to out-of-bounds memory accesses. By using C/C++ you're choosing to make a hard problem harder.
    - duneroadrunner 9y ago
      C++ does have a practical, memory-safe subset[1]. Recommended for anyone writing internet facing C++ code. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus
    - 9y ago
sebcat 9y ago
I also do this. I make use of Capsicum/seccomp-bpf and jail/chroot to a ro mountpoint, use SSP, ASLR where possible, ... But I still use C as my primary programming language. I've also written code in golang professionally for a year or two. It's quite common in the embedded space to use C or C++. It's easy to run everything as root and skip fundamental bound checking, so those languages get a bad rep in that space. Totally understandable. But it is possible to engineer solutions that are a lot safer too. It's just a question of priorities. Companies not prioritizing writing safe code or not working on having a safe architectural design will not bother with Rust or other memory safe languages. There's little to no market incentive in most areas. Sad but true.
- pjmlp 9y ago
  Even using C++ in embedded is an issue, mostly cultural. A common theme in the C++ community is to advocate C++ to devs that only see Assembly and C89, and don't see any reason to move beyond that. Most recent example "Embedded & C++ - Meeting 2017 Keynote" https://www.youtube.com/watch?v=mNPfsUZb3vs https://www.youtube.com/watch?v=mNPfsUZb3vs

curiousGambler 9y ago

I get the impression Go runs the microservice space. It's built for it and is incredibly fast despite the GC. I don't see Rust claiming that position anytime soon.

eecc 9y ago
Where I live and work, golang is only used at one major client (because they’re US based, the decision must have happened elsewhere.) Everything else is Spring Boot (java), Akka (Scala) or Nodejs. Apparently nobody wants to embrace a language designed for offshoring, so no Meetups, noisy user groups and so on... even Clojure is more popular
- K0nserv 9y ago
  Golang is a language designed for offshoring? It was invented at one of the largest engineering orgs to be used in house
  - pjmlp 9y ago
    In the words of Rob Pike: "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1" "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike 2" So a language that makes it quite easy for enterprises to deal with developers as cogs. Source: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/From-Parallel-to-Concurrent http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fro... https://talks.golang.org/2012/splash.article https://talks.golang.org/2012/splash.article
    - foldr 9y ago

pjmlp 9y ago

Neither I think Rust is fit for that purpose, any GC language is a better fit in terms of productivity, unless we are speaking about tiny IoT devices with a few KBs. Also, it is not yet fit for writing GUI code. It is quite far from what is possible to achieve today in Qt/WPF/Cocoa/Android/... tooling and even the latest NLL improvements don't fix all issues regarding writing callbacks.

rapsey 9y ago
You're comparing a language to an OS and three GUI frameworks.
- sho_hn 9y ago
  I think there's some merit to the statement nonetheless - e.g. Qt is native to C++ and its API designed around C++ language features and semantics in many ways. There has been success in writing bindings for languages that can emulate those semantics without too much pain (e.g. PyQt), but Rust is not one of them. Inside the Rust community, there's been a lot of debate about what an idiomatic Rust API for a GUI toolkit would look like, particularly because the traditional tree-of-widget-objects design of C++ GUI toolkits appears a bit inconvenient to realize within Rust's stricter semantics. IOW, "are we gui yet?" might depend on some sort of new written-in-Rust GUI toolkit to appear. There's 20 years of work by many hundreds of people in Qt, many of whom rallied not just around Qt specifically, but around projects using it. Getting that many people moving isn't easy. Alternatively, major progress has to be made on bindings and bridging to the semantics of other languages in Rust. That said - of course C++ was around quite a while before being adopted by Qt.
  - rapsey 9y ago
    Servo guys have the potential to make something amazing (i.e. a sane electron type library). But I'm not sure how much they care about that. Other then that there is nothing serious going on.
    - IshKebab 9y ago

Yuioup 9y ago

Just out of curiosity, how many web framework platform are originally written and compiled in C? CPython, udev, node, v8, ... rust?

dmitriid 9y ago
The platform may be written in C. The OS you're running microservices on is written in C/C++. It doesn't mean that your services are written in C/C++.
Tuna-Fish 9y ago
IIRC, the rust compiler started out as an OCaml project, but is now self-hosting.
- steveklabnik 9y ago
  This is true.

Shoothe 9y ago

Thanks for mentioning the page. I'm about to write a simple JSON/HTTP service and decided to use Rust but I was wondering why the author would not use Rust for web services.

penetrarthur 9y ago

It is not about languages. It is mostly about frameworks. I want to write my next web project in a mature framework.

FridgeSeal 9y ago

I'm actually writing a lambda function in Rust at work right now! Whilst I could do it in Python, it was straightforward enough to be a good first thing to try with Rust and it's actually been easier to write than I anticipated. Plus the performance benefits will be nice.