Came here for the Uniform function call syntax link. This is one of the little choices that has a big impact on a language! I love it!

I wrote a little pipeline macro in https://nim-lang.org/ for Advent of Code years ago and as far as I know it worked okay.

``` import macros

  macro `|>`\* (left, right : expr): expr =
    result = newNimNode(nnkCall)

    case right.kind
    of nnkCall:
      result.add(right[0])
      result.add(left)
      for i in 1..<right.len:
        result.add(right[i])
    else:
      error("Unsupported node type")

```

Makes me want to go write more nim.

I really wish you couldn't write extensions on nullable types. It's confusing to be able to call what look like instance functions on something clearly nullable without checking.

    fun main() {
        val s: String? = null
        println(s.isS()) // false
    }

    fun String?.isS() = "s" == this

The difference between .let{} and ?.let{} has great utility. You'd either have to give that up or promote let from regular code in the standard library to magic language feature.

And you'd lose all those cases of extension methods where the convenience of accepting null left of the dot is their sole reason to be. Null is a valid state, not something incredibly scary best dealt with with a full reboot or better yet throwing away the container. Kotlin is about making peace with null, instead of pretending that null does not exist. (yes, I'm looking at you, Scala)

What I do agree with is that extension methods should be a last ditch solution. I'd actually like to see a way to do the nullable receiver thing defined more like regular functions. Perhaps something like

   fun? name() = if (this==null) "(Absent)" else this.name

that is defined inside the regular class block, imported like a regular method (as part of the class) and even present in the class object e.g. for reflection on the non-null case (and for Java compat where that still matters)

Personally I find ?.let et al to be terrible for readability; most of the time you're better off doing a standard != null check. The same with nullable extension functions; they hurt readability.

> Null is a valid state, not something incredibly scary best dealt with with a full reboot or better yet throwing away the container. Kotlin is about making peace with null, instead of pretending that null does not exist. (yes, I'm looking at you, Scala)

I honestly find this to be such a weird thing to say or imply. No one is "scared" of null.

> Null is a valid state, not something incredibly scary best dealt with with a full reboot or better yet throwing away the container.

Agreed. It should be a first-class construct in a language with its own own proper type,

  Null null;

rather than needing to hitch a ride with the Integers and Strings like a second-class construct.