3 ms·
That's a good question. I think F# and Haskell have stolen a fair amount of OCaml's thunder. Meanwhile, Rust caters to everybody who is tired of C/C++ (putting
by mercurial 12y ago
That's a good question. I think F# and Haskell have stolen a fair amount of OCaml's thunder. Meanwhile, Rust caters to everybody who is tired of C/C++ (putting D in the same position as OCaml, I guess?), while having nice enough constructs that people coming from high-level languages get interested in it. By contrast, OCaml doesn't have the "shiny new" feeling of Rust (also suffers from other issues, such as its standard library/libraries, and the tooling, and the "mlis are documentation" attitude that is fairly prevalent in the community). I'd say with more polish and a lot of marketing, it could easily gain more market share (even though some things have gotten much better since opam).
Sometimes, working in OCaml feels like flying a starship equipped with XVIIIth century cannons. The awesomeness of many of its features is in stark contrast to the gaping holes of its ecosystem (no good INI parsing library in 2014? no usable pure OCaml regexp library?).
- swah 12y agoDoes OCaml still doesn't compile 1.0 + 2.0 or has that changed? Small stuff like this really bother some people and they fly off to Pythonland never to be seen again.
- mercurial 12y ago> Does OCaml still doesn't compile 1.0 + 2.0 or has that changed? I'm not quite sure what you mean? In any case, the compilation speed isn't really an issue (especially since we're talking about Rust, which last time I used it wasn't exactly fast).
- bam365 12y agoHe's probably referring to the fact that you have to use different arithmetic operators for int and float in OCaml, so it would have to be 1.0 +. 2.0
- mercurial 12y agoAh, that makes sense. It's still the case, but I guess it may be going away once implicits are released.
- edorrington 12y agoI think he's talking about the fact that OCaml has separate operators for floating point (i.e. in his example, you'd use 1.0 +. 2.0).
- swah 12y agoYep, that's <float><int><float> and doesn't typecheck since you missed it too, my point is made :)
- mercurial 12y agoYeah. Honestly it's a quirk, but I prefer quirks going this way than the other way (like universal compare). That said, all languages have warts. And that's the best kind of warts, the one that is explicit and happens at compile-time.
- swah 12y agoGood point. And to be honest, OCaml was the first language I used to have insanely fast compile times - and a REPL!
- pjmlp 12y agoI guess it depends on the nature of the work being done. Personally I never used Python for anything other than glorified shell scripts and Websphere installations (after Jacl got replaced by Jython). For everything else I prefer languages with type inference and availability of native compilers (AOT/JIT) in their toolchains. How good is PyPy for production code nowadays?
- DasIch 12y ago> How good is PyPy for production code nowadays? Unless you are using CPython extensions, PyPy is usable as a drop-in replacement that's significantly faster in almost all cases. In order to notice any significant speed gain, the JIT needs a chance to "warm up" though, so on short running applications or on web applications for the first couple of requests PyPy can be slower than CPython.