Not always. There's no Minecraft for Mac, they even prohibited Macs running the iPad version. It's essentially been ported to Apples APIs but purposely withheld from macOS.
Yes, it will also have 5 mins of battery life when unplugged and have a power adapter the size of a shoe box. I tried a similar machine from Lenovo at work and quickly returned it.
Does this really test Claude in a useful way? Is building a highly derivative programming language a useful use case? Claude has probably indexed all existing implementations of imperative dynamic languages and is basically spewing slop based on that vibe. Rather than super flexible, super unsafe languages, we need languages with guardrails, restrictions and expressive types, now more than ever. Maybe LLMs could help with that? I'm not sure, it would certainly need guidance from a human expert at every step.
I certainly don't mean to knock nominal types. But I think structural types are more fundamental. A language would only need a single "newtype" or "nominal" keyword to create nominal types from structural types.
Most languages have poor support for structural types though. If you try and join two records together (like a SQL join), what will your favourite language infer then?
What you are describing is structural types. It is indeed a mystery that these are so under used, especially as they are a cornerstone of type theory. Structural types are so useful that they creep into most languages in some way. Even in Java, the Kingdom of the Nouns, where the rulers refused to merge a pair class, functions essentially take tuple arguments and these tuples don't have to be named and defined. You can't return a tuple though, so there is an unfortunate asymmetry. In Haskell and OCaml, we like to describe functions in a structural way, so com.google.android.Predicate would be just "a -> Bool". You wouldn't have to convert your com.google.guava.Predicate. But even these languages lack structural records and variants and suffer for it.
It's overblown until it isn't. Hoare didn't pluck that number from thin air. This is now a solved problem in modern programming languages. If Odin doesn't have this and other essential memory safety features, it's certainly not worth the massive retooling effort.
Yes it's the burden of proof. That's why writing Rust is harder than C++. Or why Python is easier than anything else. As a user and customer, I'd rather pay more for reliable software though.
Less of the personal attacks please, you know nothing about me. I actually think it is you that is missing context here. Don Syme personally visited and presented at a variety of investment banks. He was the creator not a marketing type. I was present at one of his pitches and met him. One bank, Credit Suisse ended up adopting it. Any comparisons he made to C# where based around readability and time to market (C# is very verbose and boilerplate heavy compared to both Python and F#). This was all on the 2010-2015 timeframe. Python ended up winning in these markets. My point has always been that this now puts it in a difficult position, it's simply not radical enough to disrupt but still carries the perceived "functional programming" barrier to entry.
F# was pitched by Microsoft to be used in areas where Python dominates, especially for scripting in the finance domain and "rapid application development". So it doesn't make sense at all that C# and Java are a "better comparison".
Haskell. But there are other examples of "pure functional programming". And the state of the art is dependently typed languages, which are essentially theorem provers but can be used to extract working code.
It absolutely does make sense to compare it to the worlds most popular programming language, especially when dismissed as "functional programming". Who benefits from an OCaml comparison? You think F# should be marketed to OCaml users who might want to try dotnet? That's a pretty small market.
Both OCaml and Clojure are principled and well designed languages, but they are mostly evolutions of Lisp and ML from the 70s. That's not where functional programming is today. Both encourage a functional style, which is good. And maybe that's your definition of a "functional language". But I think that definition will get increasingly less useful over time.
I'd much rather code F# than Python, it's more principled, at least at the small scale. But F# is in many ways closer to modern mainstream languages than a modern pure functional language. There's nothing scary about it. You can write F# mostly like Python if you want, i.e. pervasive mutation and side effects, if that's your thing.
It all depends on the lens one chooses to view them. None of them are really "functional programming" in the truly modern sense, even F#. As more and more mainstream languages get pattern matching and algebraic data types (such as Python), feature lambdas and immutable values, then these languages converge. However, you don't really get the promises of functional programming such as guaranteed correct composition and easier reasoning/analysis, for that one needs at least purity and perhaps even totality. That carries the burden of proof, which means things get harder and perhaps too hard for some (e.g. the parent poster).
Arrays have a static fixed size though, making them far less useful in practice. Anything one builds with generics is boxed. Dotnet doesn't have this problem.
The JVM famously boxes everything though, probably because it was originally designed to run a dynamic language. An array list of floats is an array list of pointers. This created an entire cottage industry of alternative collections libraries with concrete array list implementations.
No it's not pleasant at all. It's boilerplate heavy, non-local and indirect. It's presumably a large part of why pattern matching is arriving in Python.
The vast majority of which unfortunately still come with Intel processors, especially the premium models. I handed my work issued Lenovo X1 back to my employer as being unusable due to overheating and excessive thermal throttling. The M4 Macbook Pro I now have is such a huge positive difference, I have adjusted to macOS and enjoy Intel outside.
I would argue that not sanitising strings is analogous to a form of memory unsafety. You take as an input, an opaque blob of bytes that you then pass on to a myriad of other libraries and pieces of code. Nothing is captured in the types other than "String". Mainstream programming languages need to make it easier to define new types and parse strings into them. Rust is very promising in this area, as it features algebraic data types.