Glad to hear there is more to come! I do think OCaml 5 not only keeps the language relevant but also makes it even more interesting.
4,485 karma · joined June 30, 2015
If the list is not being used in a critical section, what's the problem? The implication here is that OCaml is slow or inefficient. OCaml is often orders of magnitude faster than other high-level languages (e.g. Python). Arrays in OCaml can result in some very fast code.
OCaml supports type annotations practically anywhere, if you want to add them. Alternatively, you can use an editor that supports querying or showing types for bindings. VSCode and Emacs support this.
> Remember recursion? How about linked lists?
A lot of beginner material uses List to introduce algebraic data types, inductive and equational reasoning - but you don't have to use them. In fact, the standard library encourages Seq instead over List.
It's a shame the author did not get past the basics, as there are many interesting comparisons to be made. For example, OCaml 5 effect handlers are a very interesting alternative to Rust's Async.
Define better. I enjoyed computers more in the 80s. There was less bureaucracy. Cubase on the Atari ST never crashed. The modern C++ one does crash, often.
Why not offer both and be clear about it? Rather than just "length", why not call them code points? The Python docs for "len" which can be called on a unicode string say "Return the length (the number of items) of an object.". It doesn't look like a clear and easy to use API to me.
They are not necessarily substitutes, they are lower level primitives that allow more complex models, like Actors, to be implemented.
All execution models have trade offs; and sometimes we might prefer an execution model without deadlock, livelock and starvation. So for a general purpose language, a complex model like Actors is ideally a library and not enforced as the only way of achieving concurrency.
Well, every time I see someone claim this, I roll my eyes.
Actually, Rust could still learn a lot from these languages. In Haskell, one declares the call site as async, rather than the function. OCaml 5 effect handlers would be an especially good fit for Rust and solve the "colouration" problem.
It's probably the right abstraction for Haskell, or any other language that works well with functional programming, lambdas and monads. Loom is a better fit for Java. Rust also would have probably been better off with something else. Effect handlers might have been a good choice.
Gradles own docs say "Well-designed build scripts consist mostly of declarative configuration rather than imperative logic".
When it's up to the programmer to make a script declarative, it's not a declarative language.
Of course you do, especially in applications where there is no benefit to be gained versus using a GC. This is why Java was such a huge success, despite offering very little else over C++ other than GC (I think OCaml is a much better example of a GC language). Consider that an entire book has been written on such details as move semantics. For most GUI apps, a GC or other automatic memory management has proved fine.
> Gnome programs are largely still written in C, but it isn't actually C.
It's still C whatever libraries are used. It's still manual memory management with footguns. This is why they created "Vala".