> first popularized by certain functional languages

Basically that.

People associate all kinds of different thinks with the term functional programming. The only think in common is that it's focused on functions, including first class functions.

For other thinks including things like (strict) immutability, lazy evaluation, syntax, algebraic data types, linear typing, etc. it is different from person to person weather or not they think about this as part of FP or just another think which happens to be part of the FP language they use/looked into.

> Is it just that pattern matching and enums were first popularized by certain functional languages?

Not only were Sum Types first popularised by functional languages, most imperative/OO languages still don't have them (although I'm not quite sure why not). E.g. none of Java/C#/C++ have them. Neither do Python/Ruby/JavaScript/PHP (although the need is somewhat reduced in dynamic languages)

  std::variant<int, bool, double> options;
  options = true;
  
  bool value = std::get<bool>(options);
  bool has_bool = std::holds_alternative<bool>(options);
  
  // or test which alternative is held
  if (auto i = std::get_if<int>(&options)) {
    // do something with int
  } else if (auto b = std::get_if<bool>(&options)) {
    // do something with bool
  } else {
    // do something with double
  }

  $v:|[:int, :bool, :double] = 5;

  $vi: = v.[:int];
  $holds_int: = v.?[:int];

  switch v {
    .[:int]$i { /std cout << "got int:" << i };
    .[:bool] { /std cout << "got bool" };      
    .[:double]$d { /std cout << "got double: " << d };
  };

  $v:|[:int, :int]<(.[0] = 5);

  switch v {
    .[0]$i0 { /std cout << "got first int:" << i0 };
    .[1]$i1 { /std cout << "got second int: " << i1 };
  };

  // Helper for creating anonymous visitor functions
  template<class... Ts> struct overloaded : Ts... { using Ts::operator()...; };
  template<class... Ts> overloaded(Ts...) -> overloaded<Ts...>;

  using var_t = std::variant<int, long, double, std::string>;

  std::vector<var_t> vec = {10, 15l, 1.5, "hello"};

  // Type matching visitor
  for (auto& v: vec) {
        std::visit(overloaded {
            [](auto arg) { std::cout << arg << ' '; },
            [](double arg) { std::cout << std::fixed << arg << ' '; },
            [](const std::string& arg) { std::cout << std::quoted(arg) << ' '; },
        }, v);
    }

One of my teachers liked to use the term value-oriented programming for the FP subset that does not make use of functions for data representations, or even first class functions beyond combinators like 'map'. I've always liked that term and that concept, and I do believe value-oriented programming, understood as programming with pure functions and simple values as much as possible, is 75% of the value of full functional programming. And I say that as someone who has both used Haskell as my primary language for over a decade, and implemented my own functional language.

My take: sum and product types exist in various type theories (enums with their elimination rule being pattern matching). Some of the first type theories to feature them were for the lambda calculus, which functional programming is based on. As a result, they've been ubiquitous in functional programming, and have become associated with it heavily.

Rust enums aren't like C style enums. They are a kind of algebraic data type: a sum type. Sum types haven't, until recently, been very well represented outside of functional programming languages. In haskell for example you might have a function that accepts a sum type, and to handle it you pattern match each variant and provide an implementation for that variant.

This is pretty core to functional programming languages like haskell, and its very similar to how rust behaves, and is omnipresent much like in haskell. For example, rust does not have exceptions, but repersents errors via the `Result` enum which is analogous to Haskell's `Either` data type. In order to access any value wrapped in an Result you must pattern match on it and explictly handle the possibility of an error.

All of this comes from functional programming languages, but they are starting to become common place in mainstream languages.

Yes -- sum types have historically not been present in imperative languages, whereas products types have essentially always been present. Imperative languages have correspondingly good support for various uses of product types, but even if sum types can be encoded, you generally can't abstract well over them due to the nonexistent language support for their use.

C does have unions, but you can't distinguish which field is safe to read without additional information. Discriminated unions are a design pattern built on top of the language feature to give a true sum type, but since they aren't core to the language, pattern matching still isn't a thing.

(Technically, "pattern matching" encompasses both dispatching on sums and destructuring assignment on products, and to be fair, not a lot of imperative languages have good support for the latter either. But many do!)

They make it much easier to do certain kinds of things as expressions (as opposed to, say, an if/else chain which in many languages is a statement and not an expression, or a switch statement which I don't think is ever an expression)

In general the article is woefully imprecise. Yes, Rust does support higher order functions and other aspects of functional programming, but closures can have side effects. There is no concept of referential integrity in the language (I wish there was something like a “pure” keyword). Don’t get me wrong, I love Rust, but in the scheme of things, it’s a very imperative language.

Functional programming is philosophically aligned with purity and immutability. When you have enforced immutability, many of the features of OO programming disappear, and you're left with having pointers to a bundle of values with various getter style methods. In order to recover the ability to make complex data structures, you need to encode variants. This can be done with Null and the bundle of values, or it can be done with Algebraic Data Types, aka Rust's fancy enums.

I think variant records (aka 'enums' in Rust) were first popularized by Pascal. They were in ALGOL 68 even earlier, but that language wasn't widely used.

I believe, on the pattern matching side, it has to do with the fact that it's a higher level feature that feels much more declarative. Inside of writing a sequence of instructions to check whether a list is 3 and the first two are equal, one writes the declarative syntax:

  (define (f x)
    (match x
      [`(,x ,x ,y) y]
      [_ #f]))

  fn f(x: &[i32]) -> bool {
      match x {
          [x, y, _] if x == y => true,
          _ => false,
      }
  }

  fn f(x: &[i32]) -> bool {
      x.len() == 3 && x[0] == x[1]
  }

pattern matching comes along with discriminated unions (enums). discriminated unions come along with functional programming, probably because they give you a more complete set of types mathematically (AND types as we are used to with structs/classes and OR types)

To start a discussion about that topic while bringing users who are unfamiliar up to speed quickly?

Even if it's not the only way to implement iterators, using closures which maintain state and yield values one after another seems to be a very popular way to do it.

In that case you're passing around a function, which matches how this chapter characterizes "functional programming".