4 ms·

i've seen a lot of these posts ending along the lines of "it's time for rust". two languages that are always conspicuous by their absence are D and ocaml. D in

by zem 11y ago

i've seen a lot of these posts ending along the lines of "it's time for rust". two languages that are always conspicuous by their absence are D and ocaml. D in particular seems like it would be the logical upgrade path from python or ruby. it has a comfortably familiar C lineage, supports a variety of programming paradigms, and has good concurrency support. i wonder why people don't at least give it a look. (personal experience - i tried to use it twice, several years ago, and gave up because the tooling was bad, but from what i've heard that's very much improved today)

FraaJad 11y ago
D has replaced Python for my regular programming. D is the sweet spot for Python programmers to upgrade to without going backwards to Go (Programming language design wise) nor weighed down by all the new (and very good) stuff in Rust. D has everything from a nice IDE(Xamarin Studio), debugger, package management (Dub), statically compiled binaries, pretty decent std lib (not as good as python or Go, but very good nonetheless). I still write Python if it's a "script" that has to run on a $work server, where it is safe to assume that Python would be available and sufficient for most tasks.
- ylh 11y ago
  People saying "backwards to Go" instantly reminds me of the following quote: Are you quite sure that all those bells and whistles, all those wonderful facilities of your so called powerful programming languages, belong to the solution set rather than the problem set? — Edsger W. Dijkstra
  - FraaJad 11y ago
    Interestingly, ALGOL failed because it was too complicated to implement.. And Djikstra played a huge role in the formulation of that language. Why aren't you using ALGOL?
    - ylh 11y ago
      ALGOL-60 saw fine use in its day; Dijkstra criticized ALGOL-68, which indeed failed because it was too complicated to implement.
      - agumonkey 11y ago
        Too complicated for its time or in absolute terms ? It surely did a lot.
      - NevilleDNZ 11y ago
        Hmmm... It is interesting how many years urban myths can persist.... 45 years and counting.... "In December 1968 the report on the Algorithmic language ALGOL 68 was published. On 20–24 July 1970 a working conference was arranged by the IFIP to discuss the problems of implementation of the language,[1] a small team from the Royal Radar Establishment attended to present their compiler, written by I.F. Currie, Susan G. Bond[2] and J.D. Morrison. In the face of estimates of up to 100 man-years to implement the language, using up to 7 pass compilers they described how they had already implemented a one-pass compiler which was in production use in engineering and scientific applications." cf. https://en.wikipedia.org/wiki/ALGOL_68-R https://en.wikipedia.org/wiki/ALGOL_68-R
flogic 11y ago
I've tried a couple of times to play with Ocaml. In seem like something that should be great but it just falls short. Some of that is tooling that isn't fully baked. Another issue is the syntax. The weird split between the interface description file and the code file. The lack of a unified DB interface. The lack of proper Windows support.
- zem 11y ago
  i enjoy using ocaml a lot, but the lack of a good orm and the bad windows support are indeed very painful. the tooling used to be bad, but at least under linux i'm pretty happy with it these days for my small hobby projects. it's one of those languages that i'd love to be able to use at work; i miss the type system when i'm doing c++.
  - mercurial 11y ago
    Having worked with and without ORMs, I'm not sure what a "good ORM" is. On the other hand, a somewhat type-safe generic SQL query builder would be very nice to have.
    - zem 11y ago
      the other end of the process is pretty useful too - unmarshalling raw sql results into ocaml objects or records, converting foreign keys into references, etc.
- pjmlp 11y ago
  That weird split is how most languages with modules work.
  - JulianMorrison 11y ago
    In languages that don't fully parse the dependencies (which Go does), that split uncouples "the implementation needs recompiling" from "all the dependencies need recompiling."
rdtsc 11y ago
Or Elixir, Clojure, Erlang, F# depending on context they could be a match as well.
dom96 11y ago
Another language that is missing from such posts is Nim. It is a far more logical upgrade from Python than any of the other languages that you mention (or ones that others mention in reply to you) in my opinion. Especially so for the use cases explained in this post, for example Nim supports async very well with a syntax that is very similar to C#'s async await.

by zem 11y ago

FraaJad 11y ago

D has replaced Python for my regular programming. D is the sweet spot for Python programmers to upgrade to without going backwards to Go (Programming language design wise) nor weighed down by all the new (and very good) stuff in Rust. D has everything from a nice IDE(Xamarin Studio), debugger, package management (Dub), statically compiled binaries, pretty decent std lib (not as good as python or Go, but very good nonetheless). I still write Python if it's a "script" that has to run on a $work server, where it is safe to assume that Python would be available and sufficient for most tasks.

ylh 11y ago
People saying "backwards to Go" instantly reminds me of the following quote: Are you quite sure that all those bells and whistles, all those wonderful facilities of your so called powerful programming languages, belong to the solution set rather than the problem set? — Edsger W. Dijkstra
- FraaJad 11y ago
  Interestingly, ALGOL failed because it was too complicated to implement.. And Djikstra played a huge role in the formulation of that language. Why aren't you using ALGOL?
  - ylh 11y ago
    ALGOL-60 saw fine use in its day; Dijkstra criticized ALGOL-68, which indeed failed because it was too complicated to implement.
    - agumonkey 11y ago
      Too complicated for its time or in absolute terms ? It surely did a lot.
    - NevilleDNZ 11y ago
      Hmmm... It is interesting how many years urban myths can persist.... 45 years and counting.... "In December 1968 the report on the Algorithmic language ALGOL 68 was published. On 20–24 July 1970 a working conference was arranged by the IFIP to discuss the problems of implementation of the language,[1] a small team from the Royal Radar Establishment attended to present their compiler, written by I.F. Currie, Susan G. Bond[2] and J.D. Morrison. In the face of estimates of up to 100 man-years to implement the language, using up to 7 pass compilers they described how they had already implemented a one-pass compiler which was in production use in engineering and scientific applications." cf. https://en.wikipedia.org/wiki/ALGOL_68-R https://en.wikipedia.org/wiki/ALGOL_68-R

flogic 11y ago

I've tried a couple of times to play with Ocaml. In seem like something that should be great but it just falls short. Some of that is tooling that isn't fully baked. Another issue is the syntax. The weird split between the interface description file and the code file. The lack of a unified DB interface. The lack of proper Windows support.

zem 11y ago
i enjoy using ocaml a lot, but the lack of a good orm and the bad windows support are indeed very painful. the tooling used to be bad, but at least under linux i'm pretty happy with it these days for my small hobby projects. it's one of those languages that i'd love to be able to use at work; i miss the type system when i'm doing c++.
- mercurial 11y ago
  Having worked with and without ORMs, I'm not sure what a "good ORM" is. On the other hand, a somewhat type-safe generic SQL query builder would be very nice to have.
  - zem 11y ago
    the other end of the process is pretty useful too - unmarshalling raw sql results into ocaml objects or records, converting foreign keys into references, etc.
pjmlp 11y ago
That weird split is how most languages with modules work.
- JulianMorrison 11y ago
  In languages that don't fully parse the dependencies (which Go does), that split uncouples "the implementation needs recompiling" from "all the dependencies need recompiling."

rdtsc 11y ago

Or Elixir, Clojure, Erlang, F# depending on context they could be a match as well.

dom96 11y ago

Another language that is missing from such posts is Nim. It is a far more logical upgrade from Python than any of the other languages that you mention (or ones that others mention in reply to you) in my opinion. Especially so for the use cases explained in this post, for example Nim supports async very well with a syntax that is very similar to C#'s async await.