Not sure I follow. The function coloring problem is still solved in that scenario. You can apply structured concurrency to any function (there’s no colors), and any function can contain structured concurrency within it (ie, using structured concurrency doesn’t color your function)
You don't follow. Nothing against you in particular, but this is why we've had 10+ years of "color problem" articles and no real solutions. The problem isn't the colors, it's the ergonomics.
The naive solution doesn't work because it turns out the difference between functions that return a value and functions that return a promise matters..
Really cool analysis and visualizations! Although there’s an interesting wrinkle with Mario Kart 8 + 200cc - most players don’t want speed over a certain level because you’re too fast to control. So rather than trying to maximize absolute speed stat you may want to minimize the delta from your optimal speed stat
That sounds not so different from building a race car irl. There's no point in a big engine if you have to brake so early that you get passed in the corners. Plus all that braking will cook the brakes. It's often letter to have a lower top speed and never have to slow down.
A common example is try-with-resources where you don't actually need the resource and are just using it for the closing effect. For example, let's say you have a metrics library that allows you to time code blocks like so:
Another common example is when you are implementing an interface method or overriding a superclass method, and your implementation doesn't need all the arguments. Would be great for the programmer to have a way to express this intent (to the compiler and to the reader)
This JEP would allow stronger static analysis rules like "every declared parameter and variable MUST be used", and _ would serve as the canonical escape hatch for edge cases.
One datapoint: searching our codebase for variables named "ignored" produces >1,000 hits. And probably an order of magnitude more unused variables that aren't named ignored.
> Another common example is when you are implementing an interface method or overriding a superclass method
This doesn't seem to be supported and could cause many issues e.g. if a base interface adds an overloaded method with a similar signature. Suddenly we will have a conflict and compilation issues.
> This JEP would allow stronger static analysis rules like "every declared parameter and variable MUST be used", and _ would serve as the canonical escape hatch for edge cases.
This is a good point. I'm not sure if it's worth the odd syntax and potential misuse but it is interesting.
> > Another common example is when you are implementing an interface method or overriding a superclass method
> This doesn't seem to be supported and could cause many issues e.g. if a base interface adds an overloaded method with a similar signature. Suddenly we will have a conflict and compilation issues.
I think this is already a risk when modifying interfaces or superclasses. For example, if you add a method to a superclass, a subclass might already have a method with the same name/arguments but different return type, which would break compilation.
When do you record the message as processed? If you do it before the processing is complete, you have at-most-once delivery (because processing could fail after you've recorded it as processed, and it won't be retried). If you do it after the processing is complete, you have at-least-once delivery (because marking the message as processed could fail, and it will be retried).
What if the receiver process fails? How do you know which messages it processed successfully? You can shuffle the problem around indefinitely but it doesn’t go away.
If your processing doesn’t have any external side effects (make external API calls, send emails, charge credit cards, etc) then one option is to put your message queue in a relational DB alongside all your other data. Then you can pull a message, process it, write the results to the DB, and mark the message as processed all inside one big transaction. But not many use-cases can fit these constraints and it also has low throughout.
