Hacker News Reader

Comment by t-writescode | Hacker News Reader

I, personally, happen to like writing in Kotlin more than Java - with a lot of experience in both (though admittedly, all? the Java I wrote is in the pre-Streams style).

I like:

  * data class Foo(val theImplementationAndStyleOfDataClasses: String)
  * elvis?.operator?.chaining
  * the order of variable declaration (type afterward)
  * how function pointers at the end of a method call can be auto-inserted as the next curly bracket
  * how you can have fun foo() = returnValue; in one line.
  * fun `method names that can have spaces - and dashes - in them`()

The preceding 3, combined, allow for:

  @Test
  fun `much easier testing`() = commonTestSetupWrapper {
    // the code under test
  }

  * val immutable by default

While I agree that Kotlin has definitely helped push Java in the right direction; and I agree that it's probably not especially necessary to migrate 10MM lines of Java code to Kotlin, especially since they're fully interoperable, I definitely would prefer writing _new_ code in Kotlin over Java for the for-the-lazy devex improvements, if nothing else.

fwiw, my "good at it" programming history follows the lineage in historical order of:

  * Java (8?? years of it including competition programming)
  * C# (5+ years)
  * Python (2016ish to current)
  * Ruby (3-ish years, lots of Rails)
  * Kotlin (2-3 years, through current - written over 40k lines of Kotlin in the last year, alone)

View on HN

  `method names that can have spaces - and dashes - in them`

Eugh, that is a turnoff. Maybe I have programmer Stockholm’s, but at least with a single connected word, I can always double click to select the token. Maybe, I might have wanted dashes at some point, but spaces seem like a step way too far.

Generally these are only used in test methods, which is fine. I've never seen anyone use them outside that.

What benefit do they provide in testing scenarios? I've never written Kotlin, but from an outsider's perspective, it seems like a slim benefit, outweighed by the cost of the mere existence of this syntactical oddity in the language's grammar.

When writing tests, you can name the methods more useful things, such as:

  class MyTestableClass {
    fun `methodName - when input does not parse to valid regex throw exception`() {

    }
  }

It's pretty clear what is under test in a situation like that. That's basically the only situation I ever see it used in (and would code-smell the heck out of it if I saw it in other circumstances).

People who are familiar with RSpec-style testing are very used to this sort of thing.

  describe MyTestableClass do
    context 'input parsing issues' do
      context 'when not valid regex' do
        it 'throws exception' do
          ...
        end
      end
    end
  end

Anecdotally, I've also found that such style naming for tests allows me to write out the desired names for all the tests ahead of time more easily and then implement them. That happens to be my flow.

I like how tests are made in Python - you don't even need classes, just functions, and use a single assert keyword for everything. Also it's easy to parametrize them using decorators.

Parameterized tests are a huge, huge win, yeah. I am a big fan of them and look for how to do them in every test framework I use. RSpec was the weirdest for me; but NUnit and JUnit have been quite easy, and I'm not surprised at all they're easy in Python too (admittedly, I don't remember if I ever wrote them in that language).

Parameterized tests in Junit are basically the same as decorators:

    @ParameterizedTest
    @ValueSource(strings = {"first", "second"})
    void fooGoesBar(String param) {
        ...
    }

Also, once you get used to assertj, you'll never want single-assert again. It's fantastically useful to know (for example) not just that two lists aren't equal, but specifically what elements differ.

> It's fantastically useful to know (for example) not just that two lists aren't equal, but specifically what elements differ.

Pytest shows the diff as well when using assert:

    >       assert y == x
    E       assert [1, 2, 3] == [1, 4, 3, 6]
    E         
    E          At index 1 diff: 2 != 4
    E         Right contains one more item: 6
    E         Use -v to get more diff

Great, what's the equivalent of this?

    assertThat(someCollection).map(Thing::getValue).containsExactlyInAnyOrder(3, 4, 5);

If the list contains numbers or strings, you can use

    assert sorted(x) == sorted(y)

If you want to add map, then you have to write

    assert list(sorted(i.getValue() for i in someCollection)) == [3, 4, 5]

If the list contains non-sortable values, but they are hashable and unique, you can use sets:

    assert set(x) == set(y)

If the values are not unique, but hashable, you can use a counter (like a set but with count for repeating values):

    assert Counter(x) == Counter(y)

(by the way I learned about this trick from a LLM)

And if the values are neither sortable, nor hashable, you'll have to write a helper function.

But still, pytest tests are less wordy and they don't require you to create a class.

This situation is familiar to me, I had to write such helper function when writing tests in PHP, for some reason it is not included in PHPUnit assertions.

methodName_whenInputDoesNotParseToValidRegexThrowException

They did a study and it isn't hard to read camelCase. https://ieeexplore.ieee.org/document/5090039

I mean, it's harder to read compared to normal text with spaces and punctuation.

That doesn’t seem to be the case based on the study. And normal for one thing, such as paragraphs of prose, might not translate to another thing, such as a sequence of words in a line of code.

> That doesn’t seem to be the case based on the study.

The study does not say that camelCase is unequivocally as easy, or easier, to read.

Selecting the correct identifier from a list of 2-3 words (expandAliasTable, expandAliasTitle, etc.) is a wholly different exercise.

Ah thank you for actually reading the referenced study

That’s just one study, and I’d argue we should write books in camel case to make them more compact if there’s truly no difference.

Sure, but I like writing the other more. It's entirely a style thing and you're not required to do it :) it's also basically only ever seen in tests :)

This study only compared camelCase to snake_case and what the results are mixed, depends on what you call "hard to read". They only seem to have tested finding identifiers from a word cloud, and it did take more time to read camelCase identifiers (although they were also resulted in more accuracy).

It's important to note that the researchers only tested short phrases with 2 and 3 words. "getNextPath" is a different beast compared to "methodName_whenInputDoesNotParseToValidRegexThrowException".

On the other hand, there is a good body of research that generally shows that proper sentences (not just 2-3 words) without spaces are harder to read, at least for English speakers[1]. Early medieval Latin manuscripts did not use space between words[2]. The fact that spaces were seen as an improvement when they were introduced, is probably telling.

[1] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C5&q=unsp...

[2] Roman-era inscriptions did use an interpunct (a small middle dot) to separate words, but this practice fell out of fashion in Late Antiquity and Early Middle Ages and I'm not sure if it was ever the norm in handwriting.

From experience CI test reports are vastly more comprehensible at a glance.

That study compared camel case to underscore spaces. Well underscore space is still not as readable as methods with spaces and dashes.

In the RSpec case, those don't have to translate to method names with embedded spaces. It seems that using fun `...` instead of a dsl: test "..." is the mistake.

It's a place to put intetion that isn't so much of a second class citizen that it will likely be ignored and/or not updated if it ceases to be true. You want your test methods fine grained (many methods that each check one variation, instead of one method that checks a whole list of them) and every extra redundancy (method naming vs the variation of data actually passed vs documentation) increases the the chance of those redundancies getting out of sync.

In fact I've occasionally found myself writing reflection code to parse the test method name as input just to avoid that problem altogether (for name and data, not for documentation). And that was in plain Java even, the pattern could be far more useful with that kotlin naming freedom.

The test frameworks typically output the passing/failing function names. Adding spaces like this make them more human readable.

expectInternalServerErrorOnBadInput

expect internal server error on bad input

Isn't this breaking Jakob's law of the rest of the tooling though? I can se flows borking with something like "x failed at expect" in a majority of reporting tools not specifically meant to deal with this spaces in functions stuff.

Not really—-most CI reporting is based off junit/testng report XML files. I doubt your CI reporting is parsing out test names with regexes out of log files.

So that programmers have one more bikesheddibg reason, obviously.

It reminds me of Spock tests written in Groovy. I have to help maintain a code base like that now at work where a Groovy zealot (who has moved on) convinced the teams to write tests in Groovy instead of Java.

When a test fails, the method name describes what it was supposed to do written out like a sentence enclosed in double quotes which seems like a win but not much of one.

When you need to add a new test or analyze if an existing test needs to be changed, you have to eyeball all the code in the test class because even with methods named with spaces, it's not always indicative of what it does.

With Java, I can sort a list of method names and have a better idea immediately what needs to be updated or added.

Spock is an exercise in syntax cleverness with regular confusion opportunity and little gain IMO. Way too much implicit syntax that IDEs struggle with.

Refactoring Spock tests sucks due to how the context is different based on the clause you’re in.

It’s better to quote a reserved word than to be unable to use it.

> Maybe I have programmer Stockholm’s, but at least with a single connected word, I can always double click to select the token.

If you're using anything that can do syntax coloring correctly, you can still do that.

While that is avoidable by sticking to a coding style, that horrid and unavoidable 'fun' instead of 'function' (or 'fn') just saps my will to work on such a codebase.

The best part about lots of languages being around is that you can pick the one that resonates most with you :)

Right. You have selection of Kotlin and Kotlin in Android/Kotlin heavy company.

If that's the case, it doesn't sound there was much will to work to begin with...

Why do you hate fun so much?

Agreed. Obviously `func` wasn't going to happen because it is already so similar to Swift, but `fn` at least should be an option.

I like it for unit tests. Makes naming them easier

>Eugh, that is a turnoff.

That's because you're too used to C/Algol style languages

As others have said, I would not expectany any style guideline to tolerate those names outside of tests. But it's not entirely test-only: When you are dealing with code generation for schema defined in/for other languages, being able to just drop names in backticks and be done with it would be far less hassle than making up your own transformation and deciding between verbosity and safety from collisions.

> at least with a single connected word, I can always double click to select the token

I'd expect an IDE for Kotlin to detect `stuff like this` and select the entire name. Considering Kotlin came from JetBrains, IDEs are most likely already in the Kotlin community's DNA.

(i never wrote or anything related to Kotlin myself but i do appreciate IDEs helping with stuff like this)

> Considering Kotlin came from JetBrains, IDEs are most likely already in the Kotlin community's DNA.

Idea understands and performs dramatically better with Java.

I my experience it performs quite similarly, but Kotlin code can be a lot denser so similar files don't look similar at first glance.

It also really doesn't like Java with generics for some reason. Still beats any other Java IDE I've seen.

This also means that JetBrains will never write a language server for Kotlin, locking you into their ecosystem.

It doesn't lock you into their ecosystem given that other people can (and have) written language servers for Kotlin.

Which are not nearly as capable and will forever be catching up. For a better situation look at Apple’s sourcekit. I’d take kotlin over swift in less than a heartbeat if it was more open source than Swift. Which us a very low order.

How’s Apache 2?

https://github.com/JetBrains/kotlin

Name is wrapped in ``, so it’s not “true” use whatever you want. You also have to use `` on call site.

The better benefit is that you can use the right name for something instead of tiptoeing around reserved keywords.

The feature isn't just about spaces. It's also how you'd work around interacting with JVM code that uses what would be Kotlin keywords. For instance, Java classes with a method named "is" or "val" can be called through

    val isBar = foo.`is`(bar)

rather than needing to use reflection like you would to accomplish the same in Java.

The Kotlin style guide basically says "never use this outside of test names" and some targets, such as old Android, don't even support the feature in test cases.

If you use a good IDE it will select the whole method name.

In general you would not use spaces for method names of anything that’s a shared/common use facility. They are best used to give test methods readable names. E.g. “test parallel writes are thread-safe”. And not “write with timeout.”

I used to do Java and Scala.

In 2020 I started a new project in Kotlin.

I like Kotlin, but what I hate is that in the meantime I migrated all my programming to Neovim and Helix. All programming? No, not Kotlin, because the LSP isn't there and JetBrains clearly has no interest, they want to sell their IDEs.

Now don't get me wrong, I have an IntelliJ license since 10 years, even back when I was employed and paid it out of my own pocket.

It's not about the price. I would gladly pay for the LSP implementation. But I don't want to use IntelliJ anymore.

So a new project on the JVM where I have a say in the stack? Java or maybe Scala. No more Kotlin.

This is the biggest issue with investing in Kotlin IMHO. The stewards of the language have a conflict of interest in democratizing the tools.

Not only that. Their official position is sitting with smug face saying “well, duh, you’re free to roll out your own LSP and IDE implementation”, ignoring the fact that nobody outside of Google and JetBrains cares about Kotlin. And why would they? If the stewards aren’t interested in investing into healthy ecosystem.

IntelliJ CE is free and destroys any LSP in terms of dev productivity. Other than consistency, why would you not use it?

When it's "sleeping" code, not as in unused but as in not currently being worked on (no changes in open branches), then it can be quite valuable to have some bulk translation run while the code actually is sleeping, and not at some future time when there'll likely be a whole burst of activity happening in parallel. Repo host products might actually add "transform while sleeping" a possible feature, with their cross-branch knowledge, and perhaps some history mangling for a best effort approach to retaining some of th knowledge available through blame through the conversion.

As for Kotlin in general, I agree with your list. I really enjoy the way Kotlin improves the dev experience not so much with audacious new (or "new to a java-like environment", of course I'm looking at you, Scala) concepts but with small trivialities like being able to assign the outcome of an expression chain to a name without polluting that name's scope with intermediates that really don't have any purpose after the result of that chain is assgned.

And I don't hold it against Java that it does not follow that path (it focuses on more impactful changes), I would consider it almost out of character if it introduces e.g. .let. The only thing I'm a bit torn about when it comes to Kotlin is wether the "this" variants of scope functions were a good idea. They are certainly part of kotlin, and some "DSLy" styles would really not be the same without them, but if I were to pull what I like about kotlin into other languages I'd probably introduce let and apply (and the this-less run) and skip run/with/apply (assuming that the target language even has a this to run/with/apply on)

> * data class Foo(val theImplementationAndStyleOfDataClasses: String)

For the purists there are records now in Java (which can be combined with destructuring / pattern matching - there were significant improvements in this area in the last few JDK releases, and more are coming!). In this regard Java had surpassed Kotlin by some margin.

For the enterprise coders, there is the Immutables project (https://immutables.org) which you can say is Lombok on steroids (but implemented correctly, that is, by generating classes which you can inspect as regular source code, instead of relying on hacking the compiler...).

> * elvis?.operator?.chaining

This will hopefully be finally resolved by one of the subprojects of project Valhalla, as a prerequisite for value class support (which cannot be null, so...).

The others on your list are small and subjective stylistic differences, of course your preference may vary, but should not weigh heavily in any Java vs Kotlin discussion.

> pattern matching ... In this regard Java had surpassed Kotlin by some margin.

I did just glance at Java's pattern matching; and yeah, it does look like it is a bit more powerful than Kotlin's pattern matching in that it can, at the same time, look for both type and a conditional. That's relatively neat - not something I've personally needed / wanted; but neat just the same :)

The JVM is a really nice virtual machine in how it lets us use both of these languages fully interchangeably to pick the one we like more.

I'm glad Java has been investing in some of these areas, too. Everyone improves when paradigms and new learnings are distilled.

Kotlin 2.1 has added "Guard conditions in when with a subject" as an opt-in feature https://kotlinlang.org/docs/whatsnew21.html#guard-conditions...

Java records do not have a copy method (or with clause or whatever equivalent), and there are no keyword arguments.

This makes Java records extremely painful to use for any data has more than 3 fields or so. You could use them together with an annotation processor like RecordBuilder (or Immutables or Lombok, but I don't think they support records?), but that's just not pure Java. Annotation processors that generate byte code always come with their own complexity.

Kotlin data classes have their own warts (order-based destructuring can be dangerous and the copy() method is a bit hacky) but the overall ergonomics for large value objects are better than Java records at this point.

Lombok supports `@With` on records, which adds wither methods. And there are ongoing JEP discussions on how to support this natively in Java.

Lombok is so ubiquitous today that I effectively consider it part of the language. And even with Lombok, the Java toolchain is so much faster, easier to use, and more stable than Kotlin.

Kotlin is a great language, marginally better than Java, but I'm not sure it's worth enduring the toolchain. And Java keeps improving.

If you think Kotlin is marginally better than Java, you probably have a superficial understanding of Kotlin. Kotlin is vastly better than Java, which isn't surprising because Kotlin was designed 15 years later with the explicit goal of being a better Java and fixing as many of Java's design mistakes as possible. For example, the designers of Kotlin went through the book "Effective Java" and tried to avoid the listed pitfalls by design.

Java will never get close to Kotlin because even though Java can, and thankfully does, still improve, it's too late to revise many of it design decisions, and large language features often need to be considered in a language's design from the start.

On Android, Kotlin is an even bigger win because Android uses an old Java version and has become Kotlin-first.

In my opinion, Java will remain the best choice for libraries that target multiple JVM languages. For everything else, I use Kotlin without thinking twice. Kotlin 2.0 laid the groundwork for toolchain improvements, which have indeed been a long-standing pain point.

Nah: If you think Kotlin is vastly better than Java, then you have a poor grasp of Java. I offer the same evidence you did.

Having worked professionally in both, I find that good programmers can write excellent code in both languages; bad programmers can write terrible code in both languages. The average cultural practice of the Kotlin community is perhaps better than the average cultural practices of the Java community (which huge and defies averaging anyway). But Java code which emphasizes immutability, uses Optional instead of nulls, uses streams, etc is pretty indistinguishable from Kotlin.

I first learned Java in 1997 and have been using it professionally since 2005. If your Kotlin code is pretty indistinguishable from your Java code, you aren't using Kotlin properly. Here is what I wrote on this topic in 2022:

Here are some of my favorite Kotlin improvements over Java that I leverage all the time:

* Much improved type system (nullable types, function types, declaration site variance, type aliases, contracts, better type inference, reified function type arguments)

* Local variables are final by default ("val")

* Type-level distinction between read-only and mutable collections (but compiled to Java collections under the hood, so no conversion required when interacting with Java)

* Much improved collection API

* Much improved lambdas (e.g., no pain points w/ mutating variables and checked exceptions)

* Extension functions (incredibly useful in practice)

* Much better DSL capabilities (great for UIs, generating HTML, etc.)

* Lazy properties (more generally: delegated properties)

* Coroutines (looking forward to Java's Loom; by then coroutines will have dramatically improved my async code for 5+ years)

* Great serialization support (kotlinx.serialization)

* Pragmatic macro-like capabilities via inline functions and compiler plugins (removes lots of boilerplate)

* Multiplatform support (JVM/JS/WASM/native; Graal native image is a good alternative to Kotlin/native and also works for Java)

I'll go through a few of these, but not all:

* Yes, the Kotlin type system is better, no question. And yet it doesn't really matter for 90% of code, Java's type system is "good enough". And in the places where it tends to suffer, IntelliJ ends up covering the ground anyway (validating various annotation values, spring properties, sql, etc).

* The difference between nullable types and Optional<?> types is not material. TBH I quite like Optional<?> and how it meshes with streams.

* "final by default" is indeed nice. But putting `final` everywhere (which we do) is at most a tiny annoyance. This is not material.

* Clear type distinctions between mutable and readonly collections is better, but not material, because we treat all collections as immutable.

* Java streams hit 90% good enough, and StreamEx tends to fill in another 9%.

* We don't have pain points with mutating variables in closures because we don't use mutable variables.

* We don't have problems with checked exceptions because we don't use checked exceptions (and when interfacing with foreign code that throws checked exceptions, we use @SneakyThrows or wrap).

* Coroutines are a major net negative for Kotlin, and Loom is already here. After many years of async programming in JS/TS, Ruby, and (going back far enough) C++, I've concluded that async programming (and function coloring) is absolutely toxic and should be avoided unless it's absolutely required for performance (or the platform, ie GUIs).

* Multiplatform support has great future potential, but it doesn't seem to be ready yet. I just started a greenfield project and _really_ wanted to use KMP. Decided against it in favor of a React frontend. I don't want to live on the bleeding edge, I have work to do. And I've been bitten by deadended technologies enough times in my life to know the risk isn't worth it.

I could go on but I think you get the point - my Java looks like Kotlin, and the parts of Kotlin that would really diverge from my code aren't things I want. You could tell me that I should use coroutines everywhere and I just simply disagree.

> This will hopefully be finally resolved by one of the subprojects of project Valhalla

I think we'll see them come in through https://openjdk.org/jeps/8303099 although I'm not a huge fan of the approach chosen (tri state nullability: explicitly nullable, explicitly non-nullable, legacy code that should just be treated as nullable).

Except for native support for reification, almost all of Kotlin can be reimplemented by Java if you wait long enough and stack enough class annotations. It's all stylistic up to a certain point, but the classic Java style combined with the glacial improvement process is one reason why some people want to use a different language.

I think I'll have an easier time convincing someone to consider Kotlin than I'll have convincing someone to add Immutables+Manifold to the dependency chain. You end up writing Java that's not really Java like, but also not something that there's a good standard style for, and that usually ends up in a mess.

I'm glad with pattern matching, Java is now pushing Kotlin to improve rather than the other way around. I'll hope to use those features one day, when companies finally upgrade from Java 11 to Java 17 in five or ten years.

Honestly, none of those differences you listed seems especially compelling to me, except possibly for the ?. operator.

What would be compelling: Array types that don't hate generics, or generic collection types that don't hate primitive types. Does Kotlin improve on Java at all here? It's such a pain having to remember this bonus complexity when all I want is a consistent way to manage a bunch of things. (I suspect not, as I think the limitations are at the JVM level, but I don't know.)

Out of curiosity, what are you wanting that autoboxing doesn't resolve?

Stripping out Maps/Lists with boxed keys and values is the first easy thing to do when perf tuning a piece of code. It's so frequently impactful that it's worth doing immediately without any measurement.

You just swap them out with fastutils or trove and call it a day.

I think you're right, that's probably the best (lowest mental overhead, fewest footguns) way -- always use a List instead of a raw array, and always box primitive types. This also avoids the parallel explosion of Stream types and methods (IntStream, mapToInt(), etc. (and the fact that there's no BooleanStream or ByteStream, etc.)).

That said, I tend to get bitten by the fact that == on 2 boxed numeric values is roughly as misleading as possible -- it does reference comparison, but interns small integer values only, so (Integer)42 == (Integer)42, but (Integer)420 != (Integer)420. (So the small values you probably used in your unit tests will appear to work just fine with your broken, ==-using code.)

ETA: Deleted a misplaced "new". I also don't love that, e.g., ++x does a heap allocation + deallocation if x is boxed (since boxed types are immutable). But usually I care more about the cycles I spend coming up with correct code than cycles the CPU spends executing it.

Scala solves the primitives-in-generics, and it significantly improves on the array-hates-generics.

So it's possible.

10+ years in the making, at this year's Devoxx Brian Goetz said that they are almost ready with the design of Project Valhalla and can start JEP-ing it in future JDK releases. No timeline yet, so we probably will not see it until the next-after-next LTS release (29?)... But Java, like Cobol, is not going anywhere, so the wait will be worth it.

Great, though is that perhaps orthogonal to my complaints? My vague understanding is that Valhalla is about transparently allocating local objects on the stack instead of the heap when possible (i.e., when escape analysis confirms that they can't "get out" of the method that declared them), the way primitives are now.

But these are the same problems! I'm not intimately familiar with the current state and internals of project Valhalla, but they were proposing `primitive classes` backed by primitive types, allowing said class to be used as a type in generic code. Moreover, primitives would become ValueObjects, so you would have your int[] which would also be an Object[]. In other words, the difference between primitives and objects would be much smaller in terms of the language.

Bottom line is, you could have your cake and eat it too - have an int[] that looks like a List<Int>, and vice versa, while retaining the performance characteristics of an array.

Thanks, I'd thought that the goal was to reimplement aspects of the compiler+JVM to preserve existing language semantics but be more performant, but from what you've written I take it that the goal is actually to expand the language semantics themselves, in a way that would bring primitive types and objects (and thus generics) closer together.

Valhalla is what you want, at least for some of it.

https://openjdk.org/jeps/402

    interface Box<T> {
        T get();
        void set(T val);
    }

    interface IntBox extends Box<int> {
        int get();
        void set(int val);
    }

https://openjdk.org/projects/valhalla/

It is also about value types. I think the talk parent is talking about is [this], a bit long but worth watching

[this] https://inside.java/2024/12/16/devoxxbelgium-valhalla/

Kotlin does improve on the primitives/boxed situation. For example in Kotlin there is just "Int", not both "int" and "Integer". The language will use stack-allocated primitives wherever possible and boxed objects when necessary (in Collection generics or when you've explicitly opted into nullability). The distinction is abstracted away from you as a programmer. Sounds like the consistency you want.

Wonderful, thanks!

fwiw in modern-Java they have data classes:

  record Foo(String theImplementationAndStyleOfDataClasses) {}

The string is final. While sadly there is no elvis operator, the Optional type helps:

  evlis.map(e->e.operator).map(e->e.chaining)

I still strongly dislike working in Java but Java 23 is a long way ahead of the Java 6 I first learnt Java with.

I also really like conditionals like switches and ifs returning values.

Java 14 introduced switch expressions.

https://docs.oracle.com/en/java/javase/17/language/switch-ex...

try statements being expressions is also especially lovely

I recently started picking up Kotlin and to me it felt like "lesser C#".

I'd personally prefer modern C# as it's been outpacing advancements in other major languages for DX, IMO.

It is sad that its adoption seems to have boundaries defined either by large ecosystems dependent on the JVM or ideological.

Indeed. It's C# that makes me like Kotlin so much. I was trained in Java but used C# in a fully-professional setting for longer. C# as a language make a lot of very smart decisions that Kotlin took into itself when being created and out if it comes a non-Microsoft-owned (which matters for some people), comfortable, powerful language.

If I had to switch and use C# as my main work language for a company, I would be perfectly happy to.

> how function pointers at the end of a method call can be auto-inserted as the next curly bracket

This is one feature I wouldn't mind making it into other languages. It makes so much sense for doing UI stuff.

Reply on news.ycombinator.com