Hacker News Reader

Comment by FraaJad | Hacker News Reader

I wish someone would do this in nim and compare the results.

My wishful thinking is that nim would come in at the same number of lines as Python and very close to Rust's performance.

View on HN

I was thinking the same thing with OCaml. I wrote in OCaml years ago and I still remember how incredibly terse the language is/was. You can accomplish so much with very few lines of code (with the minor exception of the whole reduplicate signatures and way too many artifacts (mli, cmi, ml, etc)). It also compiles much faster than Rust (I'm not sure about Go but since Go doesn't have that sophisticated type system it isn't really fair).

I have to say Rust got fairly hard to read and think about writing code with lifetimes when using closures. I couldn't decide at times whether to just use a trait with some cells or get the closure stuff working. This was in part because of some bugs (about 1.5 years ago) and the fact that their are 4 types function things. It is also probably because I haven't programmed in anything analogous that has lifetimes (I haven't programmed in C++ in more than 1.5 decades).

There is the Python -> OCaml story for 0install:

http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...

This article in particular tackles polymorphic variants http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain... which solve one of the issues that the author had with Rust (enum subsets)

I recently used that nice article in a discussion on Lobste.rs given its Type System section does a good job showing what good, static typing can catch without developer thinking to test for it. Get in habit of specifying basic stuff right then the compiler pulls its weight a lot. On top of it, key components in ML's get formally verified on occasion due to their easier modeling in theorem provers, etc. The last benefit is the compilation is apparently straight-forward and easier to get right given Esterel managed to certify SCADE code generator in it. That requires source-to-object code equivalence proof which is a bit hard in some of these popular languages. ;)

Sort of tangental but oone thing I have always appreciated about the Python community and Guido is the flexibility and open mindedness in adding features to the language from other languages. I can't remember where I heard/saw it (it was video iirc) but Guido had pointed out there is real value to having static type analysis to a language.

While Python does now have type annotations (pep 484) that are more powerful than Golang (generics) they currently aren't checked. I wouldn't be surprised if future Pythons start readily using these type annotations. At the same time I wouldn't be surprised if Golang never has generic (just my opinion).

that was my first thought too. ocaml would have addressed all the complaints he had with rust:

  * far more concise  
  * familiar exception handling mechanism  
  * classes and inheritance for the few places he needed them  
  * mutability  
  * bytestrings

missing are

  * proper support for enum subset types (i've felt the need for those too)  
  * exhaustiveness checking for uint8  
  * bit length (seems like a very niche thing; i'm sure someone's implemented it in a library somewhere)

rust makes a compelling competitor to d as an upgrade path from c++, but if you're porting code from a high-level, dynamic language like python, ocaml is almost always going to be a better experience.

Reply on news.ycombinator.com