filter VS actix-web

Here’s Rob Pike’s (one of the original Go designers) attempt to “see what the hubbub is all about”: https://github.com/robpike/filter

I find the language really solid but asking on r/golang is quite an adventure. It's extremely distant from go's spirit, the grammar is even more rich than Rust. Typical example: let, run, with, apply, and also - they all practically do the same but with a different scope of this and return value. Just looking at the flow API can get your head spinning. To illustrate how much it's completely the opposite of Go, see how Rob Pike pokes fun at map/filter and tells people they should not use it . I guess you can't force all developers to adhere to this mental model, but that's about it, but that's about it, technical arguments are irrelevant except for extremely niche concerns about memory and startup time

I mean sure, let's praise the ergonomics of channels and the reliability of maps. As for datastructures, we already have datastructures at home . They just work fine. Nobody needs more than that because rob pike told us so

Go will never have a map/filter syntax, to the point rob pike even makes fun of it , do you really want to use it for that kind of domain ?

Also since generators are mentioned I recently came across this rob pike moment, he implemented a reduce function that takes and returns all interface{} types and uses reflection to check if the call is valid at runtime - that's the most typical Go that can ever be written in 40 lines - all that to make the point that it's useless. Such a great spirit. https://github.com/robpike/filter

A few points that stood out to me: error handling in Go is generally pretty good. It's much more performant compared to throwing exceptions and the high frequency of error handling helps a lot with debugging and avoiding unexpected errors. What you've described as "poor OOP'ish" is partly true, yes Go does poor OOP, because it doesn't try to do OOP. The language favours composition over inheritance. Strongly applying OOP concepts in Go is simply not using the language in its intended way. For implicit interfaces, it's completely fair that you don't like them, but it's not a disadvantage of the language. I for one find implicit interfaces very intuitive and feel it's the right way for it to be done. No function overloading and lack of ternary operations is absolutely intentional, both of these are overcome by writing more expressive code, which is not a bad thing. Similarly with no built in map/filter/find, these can be achieved using for-loops. Reference https://github.com/robpike/filter for Rob Pike's implementation of filter, stating in the readme that there's not much use for it and to just use for-loops instead. Last thing, enums are expressed using iota: https://go.dev/ref/spec#Iota

> I didn't get that desire for purity that you gleaned from it.

'Folks who develop an allergic reaction to "big balls of mutable state without sum types" tend to gravitate towards languages that gives them control over mutability, lifetimes, and lets them build abstractions.'

This mutability argument is present throughout the article. Seems like nothing sans Rust or niche functional languages is enough.

> Nil pointer exceptions, for example, don't have to exist anymore..

The language most notorious for those is Java due to almost everything being passed via a nullable reference. When everything can be nullable, how can you know where to check for it? Go addresses this to an extent by explicitly separating pointers from values. Values are the default and cannot be nil, so the opportunity for null dereferences is greatly diminished. It's not a perfect solution, but it's not nothing either.

> and yet they do in Go because they couldn't be bothered to add sum types.

Damn those lazy Go devs!

> Its type system is barely a step above a dynamic language.

Turns out even a basic type system is a huge improvement over none. Just being able to restrict values to concrete types goes a long way.

> You have to write the same imperative looping code over and over because Rob Pike would rather just use a for loop than something mildly expressive like map or filter (https://github.com/robpike/filter).

There are arguments to be made either way, but I definitely agree generics (along with iterators) should have been there since day 1.

> Every function that does meaningful work is littered with if err != nil { return err }.

One big positive of this that I don't see in other languages is every `return` in a function must be on the start of a line. That is, every single exit path of a function is easily findable by visually scanning

Actix Web Documentation: Detailed documentation on using Actix-web, including examples and best practices for building web applications with Rust.

I can't speak to the "is it any good" part, but (after a bit of research) I can share what I've found. I'll try to represent things as best as I understand, but I may have some finer details mixed up.

ntex is written by the same person that started actix-web, Nikolay Kim (fafhrd91 on GitHub). There was a bunch of drama a while back due to actix-web using (what many reasoned to be) avoidable unsafe code, which was later found to be buggy. Nikolay was pilloried online, resulting in him transferring leadership of actix-web to someone else. ntex is, as I understand it, essentially Nikolay picking back up on his ideals for what could have been actix-web, if people hadn't pushed him out of his own project.

How ntex compares to the pre-/post-leadership change of actix-web, I don't know.

Here are some jumping points if you want more of the backstory.

https://www.theregister.com/2020/01/21/rust_actix_web_framew...

https://steveklabnik.com/writing/a-sad-day-for-rust

https://github.com/actix/actix-web/issues/1289

Are you ready to embark on another journey in Rust? Today, we'll explore how to create a REST API that performs basic mathematical operations: addition, multiplication, and division. We'll use Actix, a powerful web framework for Rust, together with Rhai, a lightweight scripting language, to achieve our goal.

Within actix-web, middleware is used as a medium for being able to add general functionality to a (set of) route(s) by taking the request before the handler function runs, carrying out some operations, running the actual handler function itself and then the middleware does additional processing (if required). By default, actix-web has several default middlewares that we can use, including logging, path normalisation, access external services and modifying application state (through the ServiceRequest type).

Rust is a popular system programming language, known for its robust memory safety features and exceptional performance. While Rust was originally a system programming language, its application has evolved. Now you can see Rust in different app platforms, mobile apps, and of course, in web apps — both in the frontend and backend, with frameworks like Rocket, Axum, and Actix making it even easier to build web applications with Rust.

actix to handle HTTP requests