111–120 of 178 posts
Earlier quoted context omitted.
Maybe they should have used a horse, they are much more reliable than camels and more mature than ponies.
I'm not sure, AoE2 taught me that camels always win against horses. And if you consider Rust to be OCaml's child (which is kind of true if you really stretch things), it seems like young camels win against young horses too.
Earlier quoted context omitted.
It's also why C++ won - for the most part, you could just reuse C libraries as is by including the header inside an extern "C" block. These days, Zig seems to be explicitly trying to do the same thing, but without paying the backwards compatibility tax: https://ziglang.org/documentation/master/#Import-from-C-Head...
Nim does it better, it can be used anywhere C can; zig cannot.
Earlier quoted context omitted.
Why not use Rust? It can do what you want.
With 21st century developer workstations having >= 8 cores, >= 2Ghz, >= 16Gb memory, it is ridiculous to have the scaffolding that Rust, Zig and other modern languages have. Source files dont live on their own and shouldn't be compiled as isolated units, they live in projects and need to be compiled as a batch. I'm stunned to see that so many developers are used to needing scaffolding, they just accept it as being ne…
Rust has no headers or forward declarations, and compiles the whole project ("crate") as a single unit.
Earlier quoted context omitted.
Yeah I mean that's fair too. My impressions are poorly formed but the analogy is that both F# and OCaml are based on functional programming, which to my mind takes a step back from the "imperative programming -> OOP -> shared state multithreading" history into an alternative history, I'm phrasing this as them being "electric cars" for the first half. OCaml is not really the swankiest of swank in the alt-languages com…
I have a very different perception of OCaml compared to you (compared to most people?) When I think of OCaml, the concepts that come to mind are brilliant French computer scientists and hedge funds. A practical Haskell. When I think of F#, I think of... .NET, bright enterprise programmers who want to work with a tolerable language, and that's about it. If forced to name a user of it, I'd say "uhh, no idea... Maybe St…
Earlier quoted context omitted.
I used to work at an OCaml company and it wasn't nearly as much of an issue as one might predict. You can (it turns out) build a very successful business even if there aren't a lot of existing libraries, or if the language lacks certain basic features like native multithreading (same with Python of course). I don't have a great model for why this isn't devastatingly expensive, but it's probably some combination of *…
Multi-threading can often be handed off to the OS in the form of just run more processes. So in most cases there is really no need for the language to handle it.
I've seen this save tons of dollars in cloud setups (100,000's) in my career in more than one place. Safe multi-threading was marketed as part of the advantage of functional programming to many people; which IMO why I find it strange that OcAML didn't have it for so long. Lightweight threads (e.g. Tasks, Channels, etc) use less system resources than processes as well.
You can do anything with anything but you usually pay some price of inefficiency to do so. That may be small, but sometimes it is large enough to matter.
Earlier quoted context omitted.
> Rust shares a lot with OCaml, and so with F#. F# is "the" functional programming language of the .NET world, but it's also because it's the only one, and it's a second class citizen. I thought F# was OCaml?
No, F# has a lot more OO than OCaml, and there’s a significant difference in features (ex active patterns in F#, functors OCaml). I liked what I used of F#, but for any serious program it’s more Multi-paradigm than functional, since you’ll end up doing a lot of OO.
Having some experience with large scale F# codebases its rare you define a class compared to records, unions and functions. 100's of functions, 50-100 small types, 1-2 classes approx is usually the ratio I've seen for a typical microservice (YMMV).
This feels like the same pattern as Dark leaving OCaml for F#: https://blog.darklang.com/leaving-ocaml// . Ecosystem matters a lot these days. Outside of these two specific cases, I wonder if we're, as an industry, too afraid of writing this kind of stuff now I feel like it was done a lot before, and not at all these days. Sure, NIH syndrome is a fallacy, but having to write one library may not be so bad. I would be…
It's not just the libraries, it's the tools, and those are a much bigger lift. I noticed it with Scala dropping Eclipse support and some users shifting to Kotlin; you couldn't have a clearer example of a strictly worse language, but JetBrains and Google are supporting it, and the difference between a good IDE and not is huge. And when I tried to step up and fix the Scala Eclipse plugin myself and saw what kind of byz…
Earlier quoted context omitted.
It's also why C++ won - for the most part, you could just reuse C libraries as is by including the header inside an extern "C" block. These days, Zig seems to be explicitly trying to do the same thing, but without paying the backwards compatibility tax: https://ziglang.org/documentation/master/#Import-from-C-Head...
Nim does it better, it can be used anywhere C can; zig cannot.
Earlier quoted context omitted.
It's not just the libraries, it's the tools, and those are a much bigger lift. I noticed it with Scala dropping Eclipse support and some users shifting to Kotlin; you couldn't have a clearer example of a strictly worse language, but JetBrains and Google are supporting it, and the difference between a good IDE and not is huge. And when I tried to step up and fix the Scala Eclipse plugin myself and saw what kind of byz…
Kotlin is strictly worse if you value language features above all else. In that, there are several (several!) features it doesn't have.
This is in contrast with Kotlin, that tries to gain popularity by including many features, but always feeling “just sugar syntax over Java” to me.
Earlier quoted context omitted.
I'm not sure, AoE2 taught me that camels always win against horses. And if you consider Rust to be OCaml's child (which is kind of true if you really stretch things), it seems like young camels win against young horses too.
It's not a stretch, it's a stated inspiration: https://doc.rust-lang.org/reference/influences.html