Discussion on: Rust or Go for web development?

[Oliver Jumpertz]

Thank you really much for your reply!

Yes you are right, Rust has a heavy emphasis on FP-style.
But consider this two examples:

JS:

function foo(bars) {
  return bars.filter((bar) => bar.isGreat).map((bar) => bar.give());
}

Java:

Collection<Bar> foo(Collection<Bar> bars) {
  return bars
           .stream()
           .filter(bar -> bar.IsGreat)
           .map(bar -> bar.give())
           .collect(Collectors.toCollection(LinkedList::new));
}

These are only two examples, specifically tailored to your point of Rust's FP-style.
What I just want to showcase is: It's not that much new. If you got the concept somewhere else, you'll get it within Rust.
The same could be made up for variable declaration, and nearly everything else.
It's just a similar style. :-)

On Go being dumbed down:
Yes, absolutely.
IIRC, one reason for Rob Pike, Ken Thompson and Robert Griesemer to design Go the way it is, is, that Google faces some unique challenges.
They had to invest an enormous amount of money to get their C++ infrastructure right and they have to onboard a lot of new engineers very often. Concurrency, of course, is very difficult and so they wanted to create something very easy to understand and write working Software with. They also wanted to fight the enormous build times Google's C++ projects sometimes have.
Their intention was to create a language with the minimal feature set needed to accomplish a task at Google scale by negating the drawbacks they previously faced.

Rust's compiler gets faster and faster with every release, but for all the checks and safety features it comes with, there need to be some drawbacks.

What do you think about the following?

async fn foo() -> u8 { 5 }

fn bar() -> impl Future<Output = u8> {
    async {
        let x: u8 = foo().await;
        x + 5
    }
}

It may not be that fancy as a go func... and then using channels and so on, but we're getting closer. :-)

Edit regarding the job situation:
I think we will have to give it a little more time. Let the ecosystem mature more and I'm, pretty sure that, as the community grows, job opportunities will also arise.

[leob]

Haha yes you're right - the map/filter/reduce style isn't that new really if you look at what you can do in Java and Javascript.

So yes, Java and JS (but not Go) already allow you to do this. But, arguably, Rust takes FP a step further - its type system is very refined and reminded me of Haskell's, which enables Rust to do some really nifty things.

So my point was more that Go does not allow you to use this style (at least not in a generic way).

But I understand the point about the problems that Google wanted to solve with Go.

I was already impressed with the size and quality of both the ecosystem and the community around Rust - ORM is there, web server/REST API server, remoting etc. If they are able to speed up the compiler a bit, then I think Rust can have a good future competing with Go.

By the way, your example of an async function makes sense, Go Routines aren't that much more than the "Promises" and "async/await" style that we already know from JS, but with some nice "syntax sugar".

How would you implement Go's "channels" in Rust?

[Oliver Jumpertz]

Yea, our opinions seem to match there. :-)

If we simplify Go's channels into just an unbound stream of typed messages, we could use reactive streams RxRust e.g..
But we won't be able to exactly reproduce the comfort of language level features for asynchronously waiting for a return value, while the runtime takes care of halting the thread execution until said response really arrives.

[leob]

Right, I see, yes that's what Rust doesn't have, Go's runtime ... so that means it would be hard to implement it in exactly the same way.

Some "history" on Reddit (reddit.com/r/rust/comments/a6f85e/...

"While the concept of 'goroutines' is unique to Go, they represent a feature of many languages known as green threads, where there are an arbitrary number of green threads per system thread.

Once upon a time in pre 1.0, Rust natively implemented green threads. It was decided however that green threads were somewhat antithetical to Rust's philosophy, particularly the aim of having a minimal runtime, so they were dropped in favour of system threads."

So okay, you can achieve the same thing but it will probably "feel" less seamless than it does in Golang.

[Oliver Jumpertz]

Yes, exactly. :-)

[Oliver Jumpertz]

One more thing I actually forgot about and which may actually help and is more native than using something like Rx: Rust channels

[leob]

Right! so there you have it ... however when I read the article that these Rust channels are for "native OS threads" rather than the 'green threads' or coroutines that we're talking about?

[Oliver Jumpertz]

Yep, no green threads for Rust. Those channels are indeed thread backed. :-)