Haven’t really seen anyone trying to use JVM options to get performance benefits without benchmarks for their specific use case the last 10 years or so.
No offense to Tokio and Rust, I really like Rust, but having someone rewriting their app because of performance limitations in their previous language choice, isn’t really someone picking the right tool for the job necessary.
I’m not so sure they would have done the rewrite if the Go GC was performing better, and the choice of Rust seems primarily based on prior experience at the company writing performance sensitive code rather than delivering business value.
Correct. They wouldn't have considered Rust if the GC was performing better. They also wouldn't have even adopted Go if Elixir was sufficient. This team seems to have an incredible talent pool who is willing to push further for the sake of, as you say, delivering business value. Improving UX, investing in capabilities for growth, are valid business reasons why they're iterating over so many solutions. It's really impressive to see what they're accomplishing.
Right tool for the job should also take into account the experience of the devs you have at your disposal. For an omniscient Dev, is Rust the best tool for the job? Unsure. But for them with already significant rust experience? Sounds like it.
too much focus on "business value" often ends-up with codebase in a state that makes delivery of that business value pretty impossible. Boeing was delivering a lot of business value with MAX ...
They are not that similar to a struct in C in that they are not just about being a data carrier. So that might be confusing if that is what you expect.
Future work is intending to solve the third point and add deconstructing the record for pattern matching.
“We can declare a simple x-y point abstraction as follows:
record Point(int x, int y) { }
which will declare a final class called Point, with immutable components for x and y and appropriate accessors, constructors, equals, hashCode, and toString implementations.”
Would dependent types help in this case?
Add the reference type when creating the type and then you could have the compiler check that the contract holds.
It might be expressible with dependent types. I think what I'm suggesting ought to be able to express a superset of dependent types.
I think a lot of type theory tries too hard to have certain "desirable" properties, like being decidable (that is, type checking will always complete in finite time). IMO it's fine if there are cases that will go into an infinite loop, as long as the developer has tools for debugging and fixing them. After all, we rarely use programming languages where the actual programs aren't allowed to loop -- such languages exist, but they are far too restrictive to be useful for most purposes.
Maybe what I want is not even a theorem prover, but just a way to write little scripts that execute in an imperative fashion, which can iterate over the code and look for errors. Why does it have to be a fancy logic language that only academics understand?
Dependent types prevent infinite loops at compile time because if you have nonterminating terms, your types are unsound as a logic (you can derive true and false properties altogether)
That's because theorem proving with dependent types is based on the idea that you can prove something by providing a proof object that is a witness that what you want to prove is true. But a nonterminating function can fake it: you can write a function that promises a proof that something is true, while it never returns (so it never has to build a proof object). That way you can prove that false things are "true".
Does this non-terminating function run at compile time or at runtime?
If it runs at compile time, and it doesn't terminate, then presumably no executable is generated? That's good enough for me.
Or are you describing a function that checks some property at runtime, which the type system then depends on afterwards? But if that function never returns, then the subsequent code that depends on the property it was checking won't ever execute. So a false thing is only proven true in code that never executes. That seems fine to me.
(Also note that as a practical matter I mostly don't care if it's possible for a developer to maliciously trick the type system. I only care about catching accidental errors. Relying on a complex type checker for sandboxing of malicious code seems too risky.)
Participating countries are allowed to check your identity documents at a Schengen border in order to confirm that you are entitled to cross it without any other steps. They're even allowed to record that you crossed, using the ID to track who you were (and Poland does), though they aren't allowed to record that on a passport or similar travel document.
Having confirmed you're an EU citizen who isn't subject to an arrest warrant you're entitled to cross the border and there are no other checks permitted. They aren't entitled to ask you to explain where you're going or why or anything like that.
There's a similar internal border not far from me at the local airport. There's a painted line and it has a nice sign which explains that they don't actually have any officials present at the border, but if you don't have documentation allowing you to cross or if you've arrived with products that are prohibited you can phone them, they'll send somebody over in a few hours to interrogate and if necessary arrest you. There's a phone provided, it looks pretty dusty. I guess it's possible that people decide not to call?
They are still allowed to have police present at the internal border and checking both your id, itinerary and asking questions about your visit as long as it’s not “systematic”.
Aren't splay trees terrible because they turn all reads into writes? (Which means the cache lines bounce between readers, instead of being shared as they would be with pure reads.)
Yeah, having reads rebalancing the tree in a multithreaded subsystem is probably not optimal. Might be that the Splay-trees have outstayed their welcome :)
FreeBSD’s tree.h used to have, iirc, both RB- and Splay-trees.
I've implemented this in Kotlin with sealed classes, and it's slowly taking over within our org. You don't get a few things (like the ? sugar) but it's still really nice.
I have no idea why the Kotlin std lib has a Result type but limits it to exceptions - such a missed opportunity.
