I have used Kotlin professionally for a couple-few years; and, in my experience, infix operations are a choice and you don't have to use them. - in fact, I don't think any bit of code in anything I've used uses infix operations, this is my first time seeing them in Kotlin in the wild.

For example, I haven't used them even once.

That said, I, personally, have done almost no Android programming in Kotlin, so perhaps I'm missing the main environment where such things are done? For me, Kotlin has mostly been an aggressive amount of syntactic sugar to make Java a nice experience?

And most of the DSL-style code that I write uses function pointers as the last parameter, so I can do doTheThing(parameters) { anonymous function } and that's about it?

I'm sorry that the organization you work with has aggressive bikeshedding. Perhaps this is something your organization, in general, could have a conversation about?

I agree, you nailed it. Operators are something that feels like using the new shiny but are repeating well-trodden mistakes that are well-understand in languages ranging in age from C++ to Swift.

I was referring to in-fix, like can be found in Kotlin and Ruby, not necessarily operator overloads. I've found pretty usable operator overloading, in appropriate contexts, like adding two lists meaning append.

You can bikeshed in any language. Kotlin introduced a lot of optional syntactic sugar so that Java devs could choose their level of comfort with the language features. I don't really see this as a problem unless your devs are prone to this sort of bikeshedding (see: your use of "smells funny"). I've used kotlin for Android since right before it was officially supported and there has been almost no downside other than the occasional hiccup with Java/Kotlin nullability interop

Hear hear, agree whole heartedly.

Minor nit: bike shedding refers to, in the original, arguing about the color of the paint on the shed.

It follows that not all discussion is bike shedding.

In this instance, the references to C++ allude to a common best practice for programmers of avoiding custom operators, which goes far beyond an aesthetic, i.e. style, i.e. color of paint on the bike shed difference. There are engineering consequences. This also applies across languages, I'm familiar with it only from trodding the same path you are, through Swift.

Bike shedding bike shedding is indeed possible, so I won't suggest an umabiguous definition. :)

The bike shedding reference in OP is to the different flavors, but equivalent, syntactic sugar that you mention. This uses the new shiny. But this creates toxic baggage, because among other things, because to a naive implementer, there is no solid engineering reason to e.g. avoid custom operators, it's just a scarred C++ graybeard enforcing their opinion :)

No, not in every language like in Kotlin.

I’ve never seen this amount of bikeshedding like in Kotlin. It’s as if whole identity of Kotlin developer is based on “do it differently from Java” which is super ironic for people who use JVM language.

> so that Java devs could choose their level of comfort with the language features

and thus complicating teamwork because there is no "right" way

kotlin is great for the lone cowboy. not so much for teams.

In my previous job, we had a mid-sized team of ~34 software engineers and Kotlin worked like a charm. We set common standards and practices early on and it paid off. The lone wolves will exist regardless of the programming language. I've seen them in different flavors: Ruby, Elixir, PHP, JS, Python, Perl, Java, Kotlin, and etecetera throughout my career. It's a matter of team dynamics.

Anyway, I'm not a Kotlin die-hard but I found it quite fun to code in the language. IMHO, it has a gentle learning curve and the community has plenty of great libraries (e.g., Ktor, Koin).

Nevertheless, I think I leaned too much on using the syntactic sugar of the language when writing the docs and the introductory article. But by no means users are bound to this way of coding.

I hear what you are saying but there is the other side. Perhaps the opinion/feeling you are having is related to getting older.

We've learned a lot about what works and what doesn't in programming languages. Goto considered harmful and all that kind of stuff. If you want to get a Lisp/Haskell fanatic really going point out how so many of the features in those languages have finally made their way into mainstream languages (lambdas, etc.).

What we don't often consider are all of the language features that didn't make it.

This process didn't stop sometime in the past. It is happening right now. That feeling of unease may not be an indication of the quality of the features you are considering. It may largely be uncertainty about what features will or will not stand the test of time.

Perhaps as we get older, we want languages that have all of the good stuff we've learned from the past and none of the experimental stuff that we aren't too sure about yet. That might be because we are starting to notice that we won't have enough time left in our remaining days to sort all the new toys into the good/bad bin.

Stirring call to action for creativity, but it is unclear how a comment that boils down to "new things might be good" applies in this context.

as OP refers to, custom operators are considered harmful in languages ranging from C++ to Swift. It's a great contemporary example of goto.

I suppose the more poetic: "don't speak too soon, for the wheel's still in spin" is another way to state it. It isn't "new things might be good" it is more a reminder that your self-described feeling of unease may say more about you than it does about the language feature under question.

I've seen some horrors in my time due to custom operators. I've also suffered through some horrors when they are missing and would clearly be appropriate. They seem appropriate for linear algebra libraries for example. Not everyone agrees, obviously.

As an aside, I have been watching a lot of YouTube videos of people programming C. I notice that goto shows up very frequently, especially in modern C. Usually it is a label at the end of a function to manage resource cleanup before returning, almost like a manual `defer`. Sometimes it is to break out of nested loops. I mean, I've always taken Dijkstra's point to be that long jumping out of a procedural boundary was the real problem, not the keyword "goto". And built-in language features that obviate the need to use goto even for the reasonable use cases are my preference.

I feel the same about custom infix operators. I too share an unease about them. But I have to admit they feel right sometimes. I admit I don't have enough information on their use in this kind of case to know if it is one of the good ones or one of the bad ones.

> The infix is weird and footgun-y.

If it's a foot gun, then I'm not seeing how the gun is loaded?

> Extension methods on int/double serving as constructors smells funny.

It doesn't feel meaningfully different from the static factory pattern in traditional Java, where 10.percent() would be something like MoneyUtils.createPercent() or Percent.create() with several overloads. Under the hood, that is essentially what is happening. Only downside I can see is that it muddies what truly belongs to the class, but that's true of any extension function and Kotlin is intended to be used with IDEA's introspection anyway.

The Kotlin standard library has lots of extension functions that construct new objects.

It also reminds me of Ruby, which perhaps you're also not a fan of and that's OK.

I think that's more an effect of the language being new to you, and the company coding culture not having developed around it yet, than a problem with the language. Kotlin has warts, sure, but we have been using it for seven years now, and while we did have some bikeshedding in the beginning, it is virtually absent from our code reviews now. The language didn't change (well, it got even more features), but we did.