> Immutability (const) by default

The author clearly knows this, but others may not, so: immutability and "const" aren't the same thing. Const typically prevents name rebinding (as the type system permits). Immutability is the presumption that the whole data structure can't be mutated by default (though there are usually ways to mutate cheaply--without bulk copying, that is--provided by most immutable data APIs).

Const works like this:

  not_const int[] foo = [123, 456]
  const int[] bar = [456,789]
  foo = [1,2,3]     // no problem; rebinding is allowed if it meets the 'int' type constraint.
  bar = [1,2,3]     // compile error!

  mut int[] foo = [123, 456]
  not_mut int[] bar = [456,789]
  foo[0] = 789    // no problem; mutation is allowed so long as it's with valid types.
  bar[0] = 123    // compile error!

In C++ you can only call `const` methods through a const binding. `const` methods mark `this` const, so such methods cannot modify member variables. (Minus all escape hatches, such as `const_cast`.)

The author clearly knows this, [...] Immutability is the presumption that the whole data structure can't be mutated by default

The situation in Rust is a bit more complex. Rust distinguishes between interior and exterior mutability.

`let mut` bindings and `&mut` references exhibit exterior mutability - you can call methods that borrow `self` mutably (`&mut self`). Whereas `let` bindings and `&` references cannot. By the way, you can simply use moves to introduce exterior mutability for data that you own:

    let a = Vec::new();
    // Not allowed: a.push(1);
    
    // Move the vector.
    let mut b = a;
    b.push(1);

https://play.rust-lang.org/?gist=6816dc9a03aca1e779f08443224...

The downside of interior mutability is that borrowing rules are enforced at run-time rather than compile-time.

    let bar = [456, 789]; // const binding to owned data
    let mut bar = bar; // allowed if nobody else can see `bar`
    bar[0] = 123; // OK!

You cannot get around that behavior by assigning the reference to a non-const copy. That isn't allowed.

That difference severely weakens the meaning of the const property in C++.

C++'s const is your "immutability".

  struct X {
    const int i{123};
    const int j;

    X(int j_) : j{j_} {}
  };

  // non-const object; x.i == 123; x.j == 111
  X x{111};
  x.i = 222; // compilation error
  x.j = 333; // compilation error

  struct X {
    X(Y val) : y_{val} {}

    // Can be called on const and non-const X objects
    const Y& y() const { return y_; }

    // Can only be called on non-const X objects
    Y& y() { return y_; }

  private:
    Y y_;
  };

  void f(X& x) { x.y() = 222; }
  void g(const X& x) { x.y() = 222); }

  const X x{123};  // x.y() == 123
  x.y() = 222; // compilation error
  f(x); // compilation error (f's parm is non-const)
  g(x); // compilation error (can't assign to const ref)

  // Cannot take non-const ref or ptr of x
  X& xr{x};  // compilation error
  X* xp{&x}; // compilation error

  X& xr{const_cast<X&>(x)};
  X* xp(const_cast<X*>(&x)};

So, a const value cannot be mutated locally or globally. So if you make something const and expose it, it cannot be changed.

Huh? That's a CRUD app. A "microservice" is a service which is a component of a larger service. Usually a service run by the same organization. Many microservices don't speak HTTP; they use Google protocol buffers or something similarly efficient. Serving a Facebook page involves about a hundred microservices, and they don't talk HTTP to each other.

Is it? Isn't it a purely organizational paradigm where each teams are responsible for a specific service and clear API boundaries are defined between teams? rather than the "size" of an application? (which is hard to quantify, if my app does AI and needs 100,000 line of code for a single endpoint, is it still micro?).

That's why I believe "micro" is an unfortunate qualifier what is essentially basic SOA.

Mapping each team directly to a microservice seems dangerous because it encourages the service to be as big as the team, rather than as big as it needs to be. The "microservices" approach is all about keeping your components small.

But you're right, microservices is pretty indistinguishable from a (healthy) SOA. And SOA is pretty indistinguishable from the UNIX philosophy when you get down to it.

An URL shortener is a micro service without SOA. A huge web application with four services that are half a million LOC each is SOA, but not micro services.

I wonder what Martin Folwer has to say...

> Although “microservice” has become a popular name for this architectural style, its name does lead to an unfortunate focus on the size of service, and arguments about what constitutes “micro”. In our conversations with microservice practitioners, we see a range of sizes of services. The largest sizes reported follow Amazon's notion of the Two Pizza Team (i.e. the whole team can be fed by two pizzas), meaning no more than a dozen people. On the smaller size scale we've seen setups where a team of half-a-dozen would support half-a-dozen services.

> This leads to the question of whether there are sufficiently large differences within this size range that the service-per-dozen-people and service-per-person sizes shouldn't be lumped under one microservices label. At the moment we think it's better to group them together, but it's certainly possible that we'll change our mind as we explore this style further.

[0]https://martinfowler.com/articles/microservices.html

People get too caught up in “how small is micro”, which is just silly extremism.

It may be useful to some people, as we've most of the feature you find in a "real life" service

   * database connection
   * schema creation
   * json handling
   * pagination
   * some endpoints are non-json
   * support for CORS
   * automated isolation test (i.e we test the service as a blackbox)
   * generation of a minimal bin-only docker image that with travis-ci
   * self-contained dev environment (vagrant up and you're good to go)

If you're going to use Rocket, I recommend pinning the Rocket version in a Cargo.lock, and setting a specific version of nightly with rustup override.

In case you're not familiar with Swagger/OpenAPI, it's a format for specifying (generally REST-ful) HTTP APIs. The key benefit over just writing your API directly in Rocket is that you specify your API once and then generate client and server implementations that join up - even if they're in different languages.

(I did a lot of the development work on the "rust-server" Swagger codegen, and blogged on it at https://www.metaswitch.com/blog/metaswitch-swagger-codegen-f...)

https://github.com/modern-project/modern-ruby

IMO it's a smarter framework than Grape for the tasks I've set out to tackle--JSON-based RESTful APIs (though, as it's an OpenAPI-first service, there's no reason you can't handle binary data or XML or whatever you want) that leverage tools like dry-types to unambiguously define OpenAPI schema--and it addresses a lot of my pet peeves with stuff like weirdly stateful and mutable DSLs during the definition step.

The reason I mention it is because there are three languages I've been using regularly: Ruby, Node, and Rust. I intend to, next time I need a service in Node or Rust, write a Modern equivalent there. =)

The key point with the Rust Swagger codegen is that it generates a whole crate, so you just import it and don't really need to worry that it's auto-generated.

Our Swagger/OpenAPI specifications are mastered in a repository separate from our client/server code.

Our plan is to use CI on these repos to generate crates and push them to an internal crate repository. We've prototyped this, but are limited until the alternative crate repositories (https://github.com/rust-lang/rfcs/blob/master/text/2141-alte...) work completes. (We've been quite active in pushing this forward.)

All the client/server code that uses the APIs then just imports the crate as usual.

(I think this is pretty slick.)

It's kind of clever to generate the OpenAPI document from the service that's implementing it, but how do you handle multiple parallel implementations of the same service?

For example, we're building software that we sell to telecoms operators, and one of our APIs is for retrieving information about a telephone number. Depending on the operator, they might store their data in a number of different types of databases (there are standards, but not everyone follows them :( ). These databases are fundamentally different from each other; it's not just different flavors of SQL - it's actually different query primitives. As a result, we have different implementations of this service - one per database type (there is essentially no common code between them). I think defining the API separate from the implementation is pretty crucial to making this work.

> It's kind of clever to generate the OpenAPI document from the service that's implementing it, but how do you handle multiple parallel implementations of the same service?

I don't. Like, emphatically I don't. I don't view an OpenAPI document as a standard to code against (though that idea is interesting)--I view OpenAPI documents as an easy way to document an API and to generate clients.

Someday I will finish my Express port...

1. write the service specification in Thrift.

2. Generate the server and client stub with the framework.

3. Write the service functions.

4. Most probably you'd need to include some database/cache libraries. Poco project does a fairly good job.

5. Add some more logging and metric libraries.

6. General tools/libs are available in poco and folly.

7. If you are messing with REST, Microsoft Rest SDK and Facebook Proxygen is already providing a very solid foundation. High performance servers are already written. You just need to fill the call backs and configure the thread pools.

Why do you consider this more difficult than doing the same in Go? You just need some intermediate C++ knowledge for above tasks. No need to touch template programming, manually managing threads, ...

The cleanest asynchronous io model that I have ever seen.

Simple serialization by default.

Did I mention the blazing fast compile times? Just that would make it way more “faster” to build your service in Go :)

And above all the language is simple with robust idioms.

Okay, I admit it is somewhat too simple, cough generics. And you won’t get C like performances for sure.

Generally Go code isn't written like typical multithreaded code with synchronization unless you're really trying to optimize something.

When you talking about async/await, you're actually talking about asynchronization, and when you talking about goroutine, you're talking about parallel (which is a selling point of Go).

If the thread that responsible for executing the async/await blocks, then the entire progress/thread rely on that async/await will block. So if you want to comfortably use async/await, the entire call stack must be build for it, and that can be a huge challenge for the ecosystem of that language.

goroutine resolved that problem by spawn a new system thread so the rest of the progress will not be effected too much by the block. Go also resolved that problem by wrapping IO on top of an internal async API so basic IO operation will not cause actual block for too long.

When a thread responsible for async/await needs to block, the task is parked and another one will get allocated to the running thread.

[1] https://github.com/rust-lang/rfcs/pull/2033 [2] https://github.com/alexcrichton/futures-await

I like how grpc/protobuf work. And generating the code saving it in a repo and using it, is fine. for RPC-like stuff.

However, generating code with a compiler can actually suck. Like having your database layer (jooq like) generated while compiling so the code does not get checked in anywhere.

I think it's good that other languages are evolving that are safer, make it easier to do concurrency, have an idiomatic style and still are performant whilst removing legacy cruft. It's the natural evolution of things. Every C++ team I've been on debates every feature usage (e.g. auto/lambdas/etc) where one team's good code is another's bad idea due to sheer amount of legacy features vs new ways, what language constructs are good vs completely bad ideas (everyone has completely different opinions), how should I import libraries, what build tool to use, etc.

Any complex language that gets wide market adoption evolves into "complex beast that due to its age has quite a number of disadvantages and no two codebases I've seen are the same".

Even something like C.

That's in no way a fair characterization of the parent poster.

well yeah, and if you then ask these people to debate instead the use of $LANG instead of C++ you will get 100 times more debate.

It doesn’t seem to be an advertisement for C++ or a condemnation of Rust.

Apologies to the commenter then. I misread that to be a "why bother?" to the original blog post and do this instead. All tech has its pros and cons and trying other things can be good too.

It's because it's written using a low level library. Here's the first two sections (the http handling part) in Rocket:

    #![feature(plugin, custom_derive)]
    #![plugin(rocket_codegen)]

    extern crate rocket;

    use rocket::request::Form;

    #[derive(FromForm, Debug)]
    struct NewMessage {
        username: String,
        message: String,
    }

    #[derive(FromForm, Debug)]
    struct TimeRange {
        before: Option<i64>,
        after: Option<i64>,
    }

    #[post("/", data="<message>")]
    fn message_create(message: Form<NewMessage>) -> String {
        format!("{:?}", message)
    }

    #[get("/?<times>")]
    fn message_query(times: TimeRange) -> String {
        format!("{:?}", times)
    }


    fn main() {
        rocket::ignite()
            .mount("/", routes![message_create, message_query])
            .launch();
    }

A Python equivalent using the typing module:

    @app.get("/<times>")
    def message_query(times: TimeRange) -> str:
        return format("{:?}", times)

I really think people need to get over syntax. I don't find rust particularly good looking either, but I get over that because I like the semantics and it sits in a nice place in the ecosystem of programming languages. Likewise i don't like how C# uses PascalCase everywhere, or puts opening braces on its own line - yet when I program in C#, I adhere to those conventions.

Syntax is incredibly subjective, and also superficial. If you think the semantics of a language suck or are not a fit for what you are doing - that's a reasonable conversation. But you really shouldn't limit your language choice based on non-alphanumeric characters or whatever your objection is.

I like the semantics of Rust, I actually use Rust, and plan on continuing to do so. I still hate the syntax and module system though.

edit:

And no I'm not talking about the borrow-checker, I like that and it took very little time to figure out.

Your negative is my positive, I can transform a &[u8] to &str without any allocations for instance.

Timeframe: fairly soon. You can already try out most of it on nightly. There's still some final details to work through though.

Before we get into details, none of these things are breaking changes; in Rust 2015, we will add lints to nudge you in this direction, in Rust 2018, those will move to deny by default. This means if you truly love the old system, you can still use it, by allowing instead of denying the warnings.

Main ideas:

* absolute paths begin with the crate name, or "crate" if they're paths in the same crate.

One of the core issues that these changes address is that, if you don't develop the right mental model around defining items and use, counter-intuitive results can happen. For example:

  extern crate futures;

  mod submodule {
      // this works!
      use futures::Future;

      // so why doesn't this work?
      fn my_poll() -> futures::Poll { ... }
  }

  fn main() {
      // this works
      let five = std::sync::Arc::new(5);
  }
  
  mod submodle {
      fn function() {
          // ... so why doesn't this work
          let five = std::sync::Arc::new(5);
      }
  }

> In other words, while there are simple and consistent rules defining the module system, their consequences can feel inconsistent, counterintuitive and mysterious.

With the changes, the code looks like this:

  extern crate futures;

  mod submodule {
      use futures::Future;

      fn my_poll() -> futures::Poll { ... }
  }

  fn main() {
      let five = std::sync::Arc::new(5);
  }
  
  mod submodle {
      fn function() {
          let five = std::sync::Arc::new(5);
      }
  }

That being said, there's also some discussion here that hasn't been totally sorted. Using the crate name in this way has some technical problems, and so we might make it that it's "extern::crate_name", so that is

  mod submodule {
      use extern::futures::Future;

* "extern crate" goes away.

Speaking of the code above, why do we have to write `extern crate futures` anyway? It's already in your Cargo.toml. Cargo already passes --extern futures=/path/to/futures.rlib to rustc. In the end, it just feels like boilerplate. Again, there's that inconsistency between std and futures in the code above. Removing the extern crate line makes it more consistent, and removes boilerplate. 99% of the time, people put the line in the crate root anyway, and half of the 1% who don't get confused when it doesn't work when they do this.

* The "crate" keyword can be used like pub(crate) can today, for making something crate-visible but not public externally

This feels superficial, but ends up also being a much easier mental model. Here's the problem: you see "pub struct Foo;". Is Foo part of your public API, or not? Only if it's in a public module itself! pub(crate) is longer than just crate, and is often the thing you actually want when you use 'pub' inside something that's not public. So let's encourage the right thing, and one that's easier to tell at a glance.

* mod.rs is no longer needed; foo.rs and foo/ work together, rather than foo/mod.rs

There's tons of awkwardness here. Most people use foo.rs until they give it a submodule, then they have to move it to foo/mod.rs. This just feels like meaningless change for no reason. Instead of "mod foo; means look in foo.rs or foo/mod.rs", it becomes "mod foo; means foo.rs". Much more straightforward. Same with a "mod bar" inside foo.rs, it becomes foo/bar.rs, (well, as it is today, but you can see how this is more consistent overall. If it had submodules, it might be foo/bar/mod.rs!)

Also, if you have a bunch of `mod.rs` files open in your editor, you have no idea what module they corresponds to, as they all say `mod.rs`. Now they'll say the file name instead.

----------------------------

That's the quick summary. I've left out some details. If you want to try this yourself, grab a nightly and add this:

  #![feature(
      crate_in_paths, 
      decl_macro, 
      extern_in_paths,
      crate_visibility_modifier,
  )]

If you'd like to read the details yourself: https://github.com/rust-lang/rfcs/blob/master/text/2126-path... and https://internals.rust-lang.org/t/the-great-module-adventure... ; the former is the RFC that was accepted, the latter is the discussion about the extern issue, with a few different variants.

I'm actually most hyped about `#![feature(crate_visibility_modifier)]` to be honest. I know it's essentially just an alias for pub(crate), but I'm all about typing less parens in my item definitions! I didn't know about the other `pub(...)` modifiers for the longest time, but they've been so useful for things like games programming, where the entire point of the exercise boils down to "cross cutting concerns" and "eh you've got a &mut Player anyways, just reach in there and poke at the state!"

The `../mod.rs` change is also quite nice. I mean, at the end of the day it'll only save me a `mv` command and a refresh of my directory listing in vim, but sometimes those small context switches can have a surprisingly large impact on flow; since now I'm thinking about filesystems and module trees rather than the problem at hand.

> I mean, at the end of the day it'll only save me a `mv` command

Yeah, as you say, it feels minor, but hopefully, a lot of tiny ergonomic changes will end up feeling significantly better. It's also why the epoch concept is important; it gives us a way to talk about how all these little changes every six weeks build into something much bigger and nicer.

    import QtQuick 2.7

* You only need to go to up to 1 file to add an import * Tools like cargo-script don't need special comment syntax for inline dependency specification. * The source code functionality arguably depends on the version of the libraries included as well as the name, so it keeps it together.

This seems pretty obvious though so I'm guessing there's a reason it wasn't done?

Another way to think of it is, Cargo.toml contains all metadata about the build, and this is fundamentally metadata.

This is probably the most important reason to make the change tbh. It doesn't seem like a big thing but it's one of those ergonomic papercuts that will make the user experience subtly better once it's fixed.

While that would make you unnecessarily build the dependency the first time, it at least wouldn't be in your final binary, since everything would be unused. That said, we could still warn about it anyway, even without extern crate.

Often I'm writing code that's as high-level as other languages. Though by its nature it also has aspects that you don't even have to think about in other languages, like Fn vs FnOnce vs FnMut when working with closures. So it's undoubtably going to be more difficult than other languages.

For example, I think most Rust users would agree that it could be confusing when a fn returns a Cow<&str> vs OsString vs String. But it's straight-forward to convert those into String even if you don't care what the differences are.

I think it's fair to simply not have an appetite for a certain language's set of idiosyncrasies.

Compared to what? Compared to Python, JS, Go, etc, yes, those are different tools for projects with different requirements, that allow for a leaner syntax. Compared to other languages of it's category (non garbage collected, manual memory management), Rust looks alright, IMHO.

I think generalizations such as this one don't make much sense. But I agree with the rest of what you say.

Like someone hijacking Haskell discussion because they didn't grasp functional programming and don't see how anyone else could.

I'm writing most of my new code in Rust that I would've written in Node or Go. Sometimes it makes more sense to use something else. So what?

Maybe it's time to leave the theater so others can enjoy the show. Your "me no likey" posts have kinda overstayed their welcome without advancing the discussion.

I wrote a working Macho-o Parser in rust and I plan on continuing the symbolic execution engine I started in rust, so I'm not a complete beginner to rust. Also there is such a thing as the best tool for the job. And for web services I don't think rust is that tool of choice.

> Like someone hijacking Haskell discussion because they didn't grasp functional programming and don't see how anyone else could.

I understand why rust exist and it makes sense, a safe low level systems programing language. What I don't get is why one would use rust for the vast majority of microservices. There are easier more productive tools available.

> I'm writing most of my new code in Rust that I would've written in Node or Go. Sometimes it makes more sense to use something else. So what?

So you acknowledge that there are better tools for building microservices but your defense for using rust is "so what"? I mean that's fine for personal projects but when your putting things in production you should be using the best tools available.

> Maybe it's time to leave the theater so others can enjoy the show. Your "me no likey" posts have kinda overstayed their welcome without advancing the discussion.

Lol, so only positive opinions of rust are allowed here? But seriously, steveklabnik responded to one of my post with so much useful and awesome information that your, I need to leave post is ridiculous.

The language is a tiny piece of the end-to-end development experience.

Now, for playing around on a ESP32? C++ or Rust (when available).

You should check out Rocket or Actix-Web or Gotham for something a bit more higher-level. Also know that it's Rust we're talking about - it's an expressive languages, but it's also a systems language, if you want something you can toss in a breakpoint and start introspecting or experimenting you'll probably want Ruby or Elixir.

    extern crate actix_web;
    use actix_web::*;

    fn index(req: HttpRequest) -> String {
        format!("Hello {}!", &req.match_info()["name"])
    }

    fn main() {
        HttpServer::new(
            || Application::new()
                .resource("/{name}", |r| r.f(index)))
            .bind("127.0.0.1:8080").unwrap()
            .run();
    }

I'm a big fan of Rust, and I don't deny that it's possible for it to be faster, but my understanding of where Rocket's async story is that it isn't there yet.

You're also using reqwest::Client inside your handlers, which is synchronous.

I'd just find it hard to believe that could beat an async JVM or Go implementation.

Since language ergonomics and productivity are inferior over e.g. Kotlin, it would be pointless to pick where it not for technical advantages such req/s, memory usage or latency.

Type inference, explicit non-nullabililty, first class functions, function types, extension methods, etc.

Eveyone I know who's used Kotlin would not willingly go back to Java.

- Java's GC is highly customizable?

- It's one of top contenders in most web related benchmarks (see: https://www.techempower.com/benchmarks/#section=data-r15&hw=...)

I have a thing that listens as root and serves as a user dictated by their id.

so it's

    as root:
       on connect fork:
           forked process:
              read request to determine ID
              drop privileges to UID and GID of ID
              process request

It has node bits there but they aren't necessary for the basic static serving. If it gets a WebSocket connection it punts it on to node.

This looks like something right out of a CTF. I'm pretty sure you can overflow that buffer and smash the stack. It's also vulnerable to a path traversal attack. What happens if the filename is '../../../etc/passwd'?

You should also pass -fstack-protector in your Makefile.

Also: Cookie:../../../<filename>

Where <filename> is a file starting with a value that's interpreted as a valid uid by atoi(). You're saved by a NULL pointer deref when the unchecked getpwuid() fails if the resulting uid is >0 but invalid (unless you're running it on a system where NULL is mapped to readable memory).

The reality is that I only wrote as much as I needed to go back to working on the project I needed it for. It works for the 'Everything is fine' case, which is what I needed to go back to developing the client side. Even a hint of malicious intent could probably bring it to it's knees.

But therein lies the rub. Is it worth hardening it or should I just go to Rust where most of those things just won't pop up?

There's some really interesting advanced features of OpenSSH that most people will never have need for, but you can come up with some really interesting solutions. For example, you could also use a single remote account that allows SSH access and has a separate public key for each user that sets an environment var for the target desires user, and restrict the command run to sudo with that environment variable defining to run as that specific user, and make sure sudo is configured for the users allowed.

A microservice isn't a bad idea, it's just interesting how many ways there usually are to accomplish what seems like odd, specific custom workflow in most UNIX environments.

Another thing, in a make_post_response stub function I think it's better to use StatusCode::NotImplemented instead of NotFound (when trying this code I thought the match did not work correctly as everything returned NotFound).

Made more amazing by the fact that only one ad shows on the entire page.

I wonder why the author chose hyper instead of iron though...

Procedrual macros are not only landing this year, but in the first half of the year. See the roadmap.

:confetti_ball:

Using hyper directly definitely gives you a better idea how everything fits together and it is much more helpful for understanding how Futures work.

You could fix this by passing a `&futures_cpupool::CpuPool` into your database functions and wrapping the post's function bodies in `pool.spawn_fn(|| { ... })` so that they execute on a different thread and return a future of their result.

To have a global IO pool that you pass into fns, you can store it in the Service struct:

    struct Microservice { io_pool: CpuPool }

[1] https://crates.io/crates/pg_async

(I mean - why futures, if the call was blocking and presumably have a real result to return?)