I would probably do the same before using kwargs.

  {-# LANGUAGE RecordWildCards #-}


  main =
    transport
      ("2025-09-05T09:00:00Z", "2025-09-05T11:00:00Z")
      foo123
      kwargs
    where
      foo123  = Foo
      kwargs  = Kwargs {..}
      bar     = Bar
      person  = Person {..}
      name    = "Alex Smith"
      phone   = "+1 (555) 555-5555"
      options = Opts {..}
      fragile = True
      window  = PM


  data Foo = Foo
  data Bar = Bar

  data Kwargs = Kwargs
    { bar     :: Bar
    , person  :: Person
    , options :: Opts
    }

  data Person = Person
    { name  :: String
    , phone :: String
    }

  data Opts = Opts
    { fragile :: Bool
    , window  :: HalfDay
    }

  data HalfDay = AM | PM


  transport (start, end)
            foo
            Kwargs { person = Person{ name = who, ..}, options = Opts{..}, ..}
    = do
      doStuff who foo
      moreStuff phone end window
      otherThings start fragile bar


  doStuff who foo               = print "called doStuff"
  moreStuff phone end window    = print "called moreStuff"
  otherThings start fragile bar = print "calle otherThings"

  transport
    myTuple@(start, end)
    foo
    kwargs@(Kwargs { person = Person{ name = who, ..}, options = Opts{..}, ..})
  = do
      ...

Can you elaborate on the effective difference between colocations in your example and this:

  transport Kwargs {person = Person{name = who, ..}, options = Opts{..}, ..}

In JS/TS it's a lot more conventional to use objects once you go past 2-3 arguments. Sometimes patterns from other languages are great in other languages (like, functional ways of modelling errors, making invalid state impossible, not using nulls, etc), but other patterns like the one shown here don't seem great.

function findAll(tableName: string, opts?: { where: Record<string, any>; limit?: number; sort?: "DESC"| "ASC" }) {}

Like option structs in Go. Simple.

First, there's very rarely a value that really makes sense to be the "default". People often use a default value when it's a "commonly used" value: I don't think it's a good reason, other values usually are just as valid and important as the most-commonly-used value. It's like saying someone in Sweden is "white by default" because it's the most common case: it's going to be often correct but _why would you do that_ when you could just make it explicit. The typing you're saving isn't worth it.

Second, it makes your API less easy to use. Devs _should_ read through all the available arguments anyway to make your function do what they want, including these default arguments (even if they decide not to set them), so what did you gain from making them optional? A bit of typing, a bit of screen real estate? Sure, but devs _do not actually behave like that_ and often don't read or don't pay enough attention to optional arguments. They just (consciously or not) hope that the default values will be reasonable for their specific use-case. Well, too often it's not and that result in a bug or incident: the typing and screen estate you gained are not worth it. FORCE devs to think about what's the correct value, that's good design.

Third, it's much less readable. The reader doesn't know that there are invisible arguments with an implicit value, despite these arguments modifying the behaviour of the function. Make everything explicit and no-one needs special implicit knowledge to know what a function is doing (even Python says "explicit is better than implicit").

Fourth, what would make sense as a default at some point might not make sense later. You pick a default that seems to make sense, people use this default value all over the place, things change and actually new use-cases usually need a different value... well sucks to be you. Now you have a footgun, as it's not even a good default for new use-cases and it's more likely to be misused, or you need to go over all previous use-cases to give an explicit value so that you can change the default... might as well have never made it a default.

There's exceptions of course: I wouldn't want `key` or `className` to be explicit in React, but for 99% of backend stuff, default values are a bad design. I hate Go for this: zero values have caused _countless_ issues to almost everyone I know, whether they acknowledge it or not.

However, on many non-trivial projects I've worked on we ended up making the default explicit and then creating wrappers for specific use cases (i.e. randFileName, randFilePath not being case sensitive on some platforms and randTestFilePath including additional characters for tests but production variants sticking to portable sets).

Its further worth noting that rarely do I allow the default global random to be used and instead dependency inject it via params/factories.

* 1-2 args: fn(arg1, arg2)

* More args: fn({ arg1, arg2, arg3, ... })

* Sometimes: fn(mainArg, { ...optionObject })