Rust and Go pull in some stuff from functional programming (first class functions) but are not really designed around functional programming as the way to get things done.

Most go programming I've seen is like python where you are slinging around maps that are getting modified all over the place. Very antithetical to functional programming.

> Very antithetical to functional programming.

You are confusing functional programming for pure functional programming. This is like confusing Smalltalk-style OOP with OOP in general and then complaining about C++.

Mutability and functionalness are orthogonal, although the immutable style lends itself well to functional programming and mutability is more kludgy in FP.

But given that both Rust and Go have first class closures, they qualify as a functional programming language. The definition of FP is that functions are data. Python, Rust, Go, etc all fit this definition. Modern c++ does as well.

There is no reason not to include these languages, not only they support functions as data, they also support higher order functions (functions that take callbacks accepting callbacks accepting callbacks, ad infinitum).

While I agree with you, I think, in general, it’s functional patterns that people are after but not necessarily pure functional programming which I’d argue often times still is weird and counterintuitive (at least to people who have started with imperative paradigms in a procedural or object oriented language).

JavaScript isn’t a functional language, neither are Rust nor Go (and Go in general is probably one that the least bets on functional patterns all around), they all just provide constructs from functional languages like mapping arrays.

I vehemently disagree that JS, Rust, and Go are not functional languages. We have no problem classifying C++ as OOP despite it being an equally good procedural language. For some reason, we don't extend the same benefit to FP because it's foreign.

It's true that JS, Rust and Go are multi-paradigm languages (so is Haskell and other FP BTW), but FP is one of those paradigms.

I have my doubts. If I need to implement say Dijkstra's in Haskell and pick up a random algorithms book then it's not going to help me at all. If I then ask a hundred programmers how they would do it I'd get a hundred wildly different answers. From my point of view algorithms and data structures in functional languages are not very well understood or explained due to their stateful nature. If functional programming was the most popular paradigm I'd expect a lot more literature on this topic.

IMO with Go. Yes, it eschews object-oriented programming. Yet, funnily enough, whenever I use Go, I am noticing that I can work fine with it when thinking about it in an object-oriented way. Structs + methods were all the features I used in object-oriented programming anyway.

I've been going a similar way. Data and the methods to act upon the data.

But i also find myself writing in a more functional style too, limiting the amount of side effects, pure functions when i can manage it. It makes testing so much easier when you don't have to have a bunch of set-up and teardown logic to get your object into the right state before running a test.

> Data and the methods to act upon the data.

This logical grouping is what Rich Hickey called the attractive thing about objects. So a namespace in Clojure does exactly that: lets you refer to “a logical grouping of data and the functions specific to acting upon it” with a meaningful name. (It also handles the specifying of dependencies, and seems like the right place to do that, but that’s not relevant here.)

Clojure also supports private functions with “defn-“ but oddly requires using metadata for binding ns-private vars. I wonder how many folks have written their own “def-“ macro to do this. It’s never come up for me, but I haven’t written production code with it either.

It eschews inheritance and achieves polymorphism and abstraction through structural typing and implicit interfaces. Whether it is more "object oriented" than other languages is a bigger discussion.