[3r8Oltr0ziouVDM]

We should switch to using pure functional languages by default. Most of the packages don't need to do any side effects and only perform pure calculations. In a pure functional language it is obvious from function signatures if these functions are able to perform side effects, so it's not possible to hide a backdoor inside a pure function. An average project would depend only on a few impure packages, such as a HTTP client or a framework, therefore it would be much easier to verify the security (for small impure packages you could just inspect their code yourself, and bigger packages like frameworks would have many contributors that check the code and strict policies about their security). Languages like Rust and C++ for which the pure functional model doesn't work should then only be used for performance critical code, and projects written in impure languages should avoid third-party dependencies as much as they can.

[moonchrome]

> An average project would depend only on a few impure packages, such as a HTTP client or a framework, therefore it would be much easier to verify the security (for small impure packages you could just inspect their code yourself, and bigger packages like frameworks would have many contributors that check the code and strict policies about their security).

OK so just a random list of common packages a web app could use that come to mind :

- HTTP server

- HTTP client

- Logging

- Database

- Distributed cache

- File storage/blob storage

- Email

- Push notifications/SMS if dealing with mobile

- Auth (eg. OAuth/OpenID Connect middleware)

- Background task management/queue

And then there's libraries that wrap access to external services, specific protocol libraries like gRPC or GraphQL.

I would say the number of pure libraries that you reference directly in a modern webapp is probably very low, that's all a layer below.

[3r8Oltr0ziouVDM]

Ok, but in Rust or NodeJS an HTTP server may depend on a package A that depends on a package B that depends on a package C that then introduces a backdoor in its 1.0.1 release. In a pure functional language you can quickly look through dependencies of an HTTP server, and if it has zero impure dependencies then you just need to trust the developers of this one HTTP server package.

[platinumrad]

You seem to be suggesting that impure actions never depend on the results of pure calculations.

Also System.IO.Unsafe exists.

[frenchyatwork]

I don't get how that would solve you problem at all. You can implement a bitcoin miner using functional code then just add an http client as a dependency for getting data to/from the blockchain.

[3r8Oltr0ziouVDM]

You can't perform HTTP requests from a pure function without making it obvious in its signature that it does side effects. For example in a language like Haskell:

  add : Int -> Int -> Int
  add x y = x + y

There is no way a function like this can run a Bitcoin miner, all it can do is to return an `Int`. In order to do side effects, a function must return a special `IO` type that should then be returned from `main` (and only then these side effects would be performed).

[thewakalix]

unsafePerformIO exists, though. I suppose Safe Haskell might provide what you want, but (as someone mentioned elsewhere), the point of evaluating a pure function is to use its result somehow; a pure function that is supposed to look up a bitcoin address in a Map, but is changed to always return a constant one, could be just as bad of a backdoor.

[Findecanor]

Another approach would be to harden the software supply chain by requiring that dependencies and side-effects are entitlements in metadata that are visible and would need to be approved by the programmer that imports the module.

There are already some frameworks out there who use signed metadata and databases to track code and where code comes from. But on the source code level, I think the metadata could just be extracted from the existing Crate metadata and source code.

[peterth3]

So, you’re claiming that pure FP languages need less dependencies than FP-adjacent languages like rust?

This is really interesting. Do you have a source to cite proving this claim?

[3r8Oltr0ziouVDM]

No. What I'm saying is that many of the dependencies in any language don't need to perform side effects, they only do pure calculations. For example a JSON parser takes a JSON string and returns some data structures. It's a pure function. However, in a language like Rust you can easily hide malicious code that has access to network inside such a function. In a pure functional language you can tell from the signature of a function you're calling that it is indeed a pure function and is guaranteed to not perform any side effects. So it is safe to call any function from a third-party dependency that doesn't do side effects (which you can immediately see from the type signature) without even inspecting the code.

[bertylicious]

Parent only claimed that most Haskell packages are pure and thus cannot execute impure side-effects. They didn't say anything about the overall number of dependencies.

[jhgb]

> FP-adjacent languages like rust

What does that even mean? Rust is very far from having anything to do with FP. FP implies immutability and heavily shared structures. Rust hates shared structures with a passion, it requires ownership. You have to jump through some massive hoops to get the same benefits of shared data structures in Rust.

[peterth3]

Just seeing this…

> FP implies immutability and heavily shared structures

FP does imply immutability, but not sure what you mean by “heavily shared structures.”

If you’re referring to a type system like Haskell’s then that’s what I meant by “FP-adjacent.”

> Rust is very far from having anything to do with FP

This thread has a pretty deep rust vs haskell discussion: https://www.reddit.com/r/rust/comments/4jh8hv/question_about... Clearly, there are some similarities.

> You have to jump through some massive hoops to get the same benefits of shared data structures in Rust.

Again, not sure what you mean by “shared data structures.” Functional styles work well in rust. You could use only immutable variables with clone/copy sprinkled throughout and the borrow checker won’t complain.