101–110 of 111 posts
Earlier quoted context omitted.
What makes you think that Kotlin should be mentioned? Especially since concurrency in Kotlin is really not great, compared to concurrency in Erlang or Scala.
For starters, because the concurrency story in Kotlin is also built on the structured concurrency idea.
The same is true for Scala and other languages. Languages that even existed before Kotlin.
Earlier quoted context omitted.
> Could you articulate or point me to some of the arguments or thoughts that lead to the conclusion here? I gave a talk about exactly that recently at Code Mesh. I expect them to post the video soon. https://codesync.global/speaker/ron-pressler/#745why-user-mo... > Also, this statement makes you sound like Goliath. Maybe, but it's not just a matter of size but also trajectory. And, as you say, our competition is most…
You didn't answer a few of the interspersed questions, so I'll press you on the records one. What about Java records are different than Kotlin's data classes besides forgoing the auto-generated `copy()` method? I understand there are some implementation details, such as inheriting from a Record base class, and how it handles serialization. But I mean as a user. Can records implement interfaces? Can records be variant…
Yes.
> Can records be variants in a sealed class hierarchy?
Yes.
> Can records have a private primary constructor?
The accessibility of the constructor is roughly at least that of the record class itself. If the record class is public, then the canonical constructor must be public. However, thanks to the positive answers to the two previous questions, you can have a readable-though-not-publicly-constructible record -- make it a private implementation of a sealed public interface.
> Can I customize the getters (to e.g., make defensive copies)?
Yes. Although in most cases, defensive copying in the constructor is sufficient.
Earlier quoted context omitted.
* Java offers both user-mode and kernel threads. You pick at creation, and can even plug your own scheduler. * Loom's virtual threads are completely scheduled in library code, written in Java. * FFI that bypasses the JDK and interacts with native code that does either IO or OS-thread synchronization is extremely rare in Java. * Cancellation is the same for both. Also, IMO, coordination is simpler for threads than for…
One headache I see that no one seems to mention is thread affinity seems a lot harder to manage in an implicit system. Many patterns use a single thread for synchronization but often times one thread is special. UI systems often have a UI thread that controls the GLContext or what have you. In something like C#'s async, you can easily schedule tasks off and on that thread. I'm not sure how you could do this implicitl…
>I would also argue its rare because its hard to do.
Is it? I recently had to write some simple code with C to interact with WinAPI and JNI was pretty straightforward to do.
Earlier quoted context omitted.
I'm not sure I really think of function coloring as a "problem" ... facebook is experimenting with auto differentiation for Kotlin and looks like it's adding a new "differentiable" function color -- https://ai.facebook.com/blog/paving-the-way-for-software-20-... It looks very easy to reason about and use to me ... and i personally find async a similarly useful marker ... It's about being able to push constraints from…
There was a series of essays about esoteric language features posted here a few weeks ago, and one of them was exactly what you're talking about. It was a functional language, with the ability to mark functions as involving I/O, non-terminating, or (I think) arbitrary custom "colors." It was an academic language, but very interesting. Sadly, I don't remember the name. Maybe somebody else can post the link.
Earlier quoted context omitted.
There was a series of essays about esoteric language features posted here a few weeks ago, and one of them was exactly what you're talking about. It was a functional language, with the ability to mark functions as involving I/O, non-terminating, or (I think) arbitrary custom "colors." It was an academic language, but very interesting. Sadly, I don't remember the name. Maybe somebody else can post the link.
I believe it is https://news.ycombinator.com/item?id=25178437 and the language discussed is Koka https://koka-lang.github.io/koka/doc/manual.html#sec-effect-...
Earlier quoted context omitted.
Additionally Kotlin also targets native. `suspend` in Kotlin was very much designed with this in mind as it's easier to implement than something that requires an extensive runtime like Loom. Kotlin will still support Loom on JVM and there will likely be integration with suspend/flows etc also.
That's a good point. Generally, I opt for languages that either compile away their nicities to avoid runtime hits, such as Rust being compiled to WASM, or languages that bring nicities in runtimes that they _completely own_, such as Java on the JVM. The problem with Kotlin and the like is that they can't easily compile away their features due to inherent runtime dependencies, e.g. garbage collection, making them poor…
Earlier quoted context omitted.
I don't think "task cancellation" is quite the major difference you think. If you model it as thread A wants to cancel thread B, then while threading means that A runs and cancels B, but B may need some time to catch up, the async world has the problem of thread A running at all to cancel B, if B is having a problem that requires cancellation. It's "obvious" and "safe" until it doesn't happen at all. This is a pervas…
Async, and cooperative multitasking in general, requires all members participate in the contract: you shall not block and you shall not go too long until yielding. Once a piece of code violates that, all bets are off. Python has explicit debugging mechanisms to help a developer detect the latter. Cancel safety is less about killing an out-of-control task, and more about making sure the state after cancelling a task i…
Arn't those effectively the same?
I think the only contract is "you shall not go too long until yielding". Or if you're designing for performance, not for responsiveness, it might be: "you shall not hold unto CPU and IO resources that you're not using".
Earlier quoted context omitted.
There was a series of essays about esoteric language features posted here a few weeks ago, and one of them was exactly what you're talking about. It was a functional language, with the ability to mark functions as involving I/O, non-terminating, or (I think) arbitrary custom "colors." It was an academic language, but very interesting. Sadly, I don't remember the name. Maybe somebody else can post the link.
I believe it is https://news.ycombinator.com/item?id=25178437 and the language discussed is Koka https://koka-lang.github.io/koka/doc/manual.html#sec-effect-...
Earlier quoted context omitted.
That's a good point. Generally, I opt for languages that either compile away their nicities to avoid runtime hits, such as Rust being compiled to WASM, or languages that bring nicities in runtimes that they _completely own_, such as Java on the JVM. The problem with Kotlin and the like is that they can't easily compile away their features due to inherent runtime dependencies, e.g. garbage collection, making them poor…
Clojure doesn't actually use invokedynamic from what I know.
Earlier quoted context omitted.
I'm not familiar with concurrency in Erlang or Scala, could you explain how it differs from the approach in Kotlin (which I know)?
I've posted above how Scala's IO/Task is different from C#/Kotlin async-await. https://news.ycombinator.com/item?id=25305574 I hope you will find it helpful.