4 ms·

Java doesn't even have "await" feature, while C# has it since more than 10 years.

by oijfio23 3y ago

nsonha 3y ago
Congratulation for spreading a disease in PL design. Await is controversial at best and should not be considered a pro.
- neonsunset 3y ago
  Then why Swift, Rust, TS/JS and Python went with it as well?
  - nsonha 3y ago
    Yes I literally called it a disease. Just look up “what color is your function”, I’m hardly the only person who thinks so. There are more languages without async await that ones that have. The language that’s known most for massive concurrency, go, does not have it. None of the functional programming languages needs it either.
    - neonsunset 3y ago
      Oh no. Not the function coloring debate again (congratulations, with 1/100 of the talent, the author of that article is now inflicting similar damage as misquoting Donald Knuth on performance). But if we have to do this, all functions in Go are colored but you simply can't do anything about it. Not allowing a method call to represent a delayed operation that produces a result (Promise/Future/Task) is the major mistake, and a reason why Go is surprisingly limited at concurrency even if it not seems that way if you come from a language which had even worse UX.
      - nsonha 3y ago
        Why do you need to know what/what not is a delayed operation? Seem like the worse languages are ones you have to do that, instead of just caring about the computation. Polluting your function signatures with some abstraction that has nothing to do with the domain is pretty lame too.
        neonsunset 3y ago
        "The group I belong to is obviously right and the other group is obviously wrong" Forcibly hiding away the nature of the call shifts the priorities from easy concurrency especially when there are multiple calls in-flight to only logically sequential code being convenient to write with all other options requiring significantly more boilerplate (which is the case for both Go and Java). It is a tradeoff, and I think it is a bad one for the domain that both Java and Go are usually applied to. Java had to retrofit a GT approach because async/await would be unfeasible at this point. It was a good choice in the context, but maybe not so if one were to reinvent it from the ground up. On the other hand, Go took a similar route but for completely different reasons - it was specifically tailor made to first and foremost solve Google issues with internal dev culture and scaling of the organization (e.g. syntax styling being the function visibility modifier) and strictly prioritized being as quick to on-board as possible. It resulted in Go being a language that is, as someone neatly put it here on HN, "Newbie friendly but professional unfriendly". This is further evidenced by the amount of surrounding code generation tooling and code written in DSL required to maintain an average complex project written in Golang (remember the HN post on a multi-million dollar project in dev hours to just work around Go's issues with nils?), something that is often a sign of inherent language limitations or its overall inadequacy (e.g. the criticism regarding C#'s source generators/interceptors or Java Lombok is valid because they exist for the same reason).
bsder 3y ago
That's because Java has "java.util.concurrent" which kicks everybody's ass at concurrent programming. Seriously. Any of the GC languages would be several orders of magnitude better simply by doing nothing but copying "java.util.concurrent" into their language.
- neonsunset 3y ago
  Have you tried PLINQ? Much better than Java streams like LINQ which is a common knowledge but can easily parallelize arbitrary list comprehensions.

Java doesn't even have "await" feature, while C# has it since more than 10 years.

nsonha 3y ago

Congratulation for spreading a disease in PL design. Await is controversial at best and should not be considered a pro.

neonsunset 3y ago
Then why Swift, Rust, TS/JS and Python went with it as well?
- nsonha 3y ago
  Yes I literally called it a disease. Just look up “what color is your function”, I’m hardly the only person who thinks so. There are more languages without async await that ones that have. The language that’s known most for massive concurrency, go, does not have it. None of the functional programming languages needs it either.
  - neonsunset 3y ago
    Oh no. Not the function coloring debate again (congratulations, with 1/100 of the talent, the author of that article is now inflicting similar damage as misquoting Donald Knuth on performance). But if we have to do this, all functions in Go are colored but you simply can't do anything about it. Not allowing a method call to represent a delayed operation that produces a result (Promise/Future/Task) is the major mistake, and a reason why Go is surprisingly limited at concurrency even if it not seems that way if you come from a language which had even worse UX.
    - nsonha 3y ago
      Why do you need to know what/what not is a delayed operation? Seem like the worse languages are ones you have to do that, instead of just caring about the computation. Polluting your function signatures with some abstraction that has nothing to do with the domain is pretty lame too.
      - neonsunset 3y ago
        "The group I belong to is obviously right and the other group is obviously wrong" Forcibly hiding away the nature of the call shifts the priorities from easy concurrency especially when there are multiple calls in-flight to only logically sequential code being convenient to write with all other options requiring significantly more boilerplate (which is the case for both Go and Java). It is a tradeoff, and I think it is a bad one for the domain that both Java and Go are usually applied to. Java had to retrofit a GT approach because async/await would be unfeasible at this point. It was a good choice in the context, but maybe not so if one were to reinvent it from the ground up. On the other hand, Go took a similar route but for completely different reasons - it was specifically tailor made to first and foremost solve Google issues with internal dev culture and scaling of the organization (e.g. syntax styling being the function visibility modifier) and strictly prioritized being as quick to on-board as possible. It resulted in Go being a language that is, as someone neatly put it here on HN, "Newbie friendly but professional unfriendly". This is further evidenced by the amount of surrounding code generation tooling and code written in DSL required to maintain an average complex project written in Golang (remember the HN post on a multi-million dollar project in dev hours to just work around Go's issues with nils?), something that is often a sign of inherent language limitations or its overall inadequacy (e.g. the criticism regarding C#'s source generators/interceptors or Java Lombok is valid because they exist for the same reason).

bsder 3y ago

That's because Java has "java.util.concurrent" which kicks everybody's ass at concurrent programming. Seriously. Any of the GC languages would be several orders of magnitude better simply by doing nothing but copying "java.util.concurrent" into their language.

neonsunset 3y ago
Have you tried PLINQ? Much better than Java streams like LINQ which is a common knowledge but can easily parallelize arbitrary list comprehensions.