The context here is people transitioning from other languages.

I believe I understand your point, I just don't agree with your conclusion. Technical issues don't seem to be all that important for adoption outside of the small initial group of early adopters, where it's very important. Lack of inheritance (and generics!) in Go was bemoaned by many, yet I'd say in terms of adoption it's been a success. JS adopting classes came after it's success, and didn't drive its success at all. Clojure has never been "classically" OO at all.

OCaml, which I believe you are familiar with, has a very different sort of object system, and it's not widely used at all in the OCaml community; I bet they could drop the O and few users would care. I didn't mention OCaml before because it's hardly a success in terms of adoption.

I agree with you that it is annoying that vtrefs are not yet implemented, so we can't even try them yet with our OO programs. But that goes to the real hindrance to Nim adoption, the perception that it's an unfinished hobby language, not worthy of consideration for "real work". That perception affects all non-mainstream languages. Few want to become expert Dylan programmers, only to see it die on the vine. Nim has been "about to get some 1.0 release" for a few years now. Anyone who reads that starts thinking "It's the language of the future, always has been, always will be".

@canyonblue77 and @Libman

There are a huge number of potential users amongst data scientists and bioinformaticians for whom Nim's Python-like syntax is an enormous draw, so much so that I just use "looks/reads like Python, compiles to fast C code" as my Nim line, and they're very interested. Ruby is not that popular in data science, so people there don't care about a language that looks like Ruby.

2017-08-05 15:05:19

bpr: Lack of inheritance (and generics!) in Go was bemoaned by many, yet I'd say in terms of adoption it's been a success.

Go de facto has inheritance via embedded types and delegation. The differences in semantics (such as lack of open recursion) are an annoyance, but can be worked around; it leads to a lot of copy-and-paste programming, but that's already common in Go. Parametric polymorphism (generics) is orthogonal to subtype polymorphism; dynamically typed OO languages do not have or need generics, plenty of statically OO languages historically didn't have generics (such as Simula 67). OOP does not mean "exactly like Java".

In any event, the bigger point is that you can mechanically replicate most things that you can do in (say) Python in Go.

bpr: JS adopting classes came after it's success, and didn't drive its success at all.

Javascript had success because it had a monopoly on browser scripting, despite having horrible semantics in too many ways to count (such as {} + [] == 0).

bpr: Clojure has never been "classically" OO at all.

Clojure is a fairly marginal language. A very well-designed one, but as far as adoption goes, it's not going to displace other languages anytime soon. And the adoption it has comes from the FP part of the crowd, where many also are involved in a religious war with OOP.

bpr: OCaml, which I believe you are familiar with, has a very different sort of object system, and it's not widely used at all in the OCaml community; I bet they could drop the O and few users would care.

OCaml's object system is a very traditional one, with the exception that it supports structural subtyping (and that is only unusual for statically typed languages). That it is not widely used has two reasons: (1) the usual religious war between FP and OOP advocates and (2) inefficient method dispatch discourages its use.

And in the end, OCaml ended up with no less than six ways of doing runtime polymorphism, including two full-fledged and independent OO systems. These are: variant types, polymorphic variants, extensible variants, records of closures, objects, and first-class modules (first-class modules along with generative functors give you a completely separate OO subsystem).

Edit: to clarify something: I think in principle either multi-methods or vtrefs can be close enough with sufficient stdlib support. The biggest problem with methods is the uncertainty about their future and with vtrefs the fact that so far they only exist on paper.

2017-08-05 15:49:43
My current plans for method are:
  • Change the semantics slightly: Only the first argument is considered in the dynamic lookups. Nothing else will change really.

The only problem with that is that then we have 4 ways to do dynamic binding:

  1. via closures.
  2. via proc type fields with explicit this argument. (Still my favourite when performance is most important and you actually have polymorphism at runtime...)
  3. via method
  4. via vtref.

Which is at least one way too many...

2017-08-05 21:35:55

Agree with BPR mostly.

For me OOP is not really a big deal compared to V1.0 and in that regard Crystal has the same drawback as Nim.

I think the obvious trade off with the more aggressive type inference is the much slower Crystal compiler. Also you can do things like this in Crystal which I don't like:

a = "hello"
a = 1

I've tried Crystal and I mostly enjoyed it.

Positives have been mentioned about Crystal in this thread I think the main positives for Nim are, has much better FFI, much more powerful macro system, better package manager, better control over the compiler, probably better stack trace, and probably better tooling. I didn't mention javascript backend because Typescript/Flowtype/Clojurescript/Scala.Js/Purescript/Bucklescript etc have far better tooling than Nim so I personally don't see Nim as attractive for doing javascript target stuff.

I did feel the Crystal documentation is better organised, more extensive, and easier to consume.

V1.0 for Crystal is promised at the end of the year but I'm fairly doubtful but its nice they have a roadmap with goals. But basically has the same major drawback as Nim at the moment which is no V1.0.

Kotlin will probably be a big mover now with Google backing it in Android and also that it will have LLVM backend soon. The IDE is great for Kotlin. The compile times are poor like Crystals. Its something you cannot ignore because compile time was a big part of Go's success. Nim tells a pretty good story in this regard.

2017-08-05 21:50:20


Which is at least one way too many...

Drop method.


I agree that the Nim JS backend is interesting, but I would not try to argue for using it in our SW stack. Even OCaml is more of a contender in that space since Reason .

I also agree that Kotlin got a huge boost because of Google backing it. On the JVM, I still favor Scala, which now has a solid JS backend and an up-and-coming LLVM backend. I don't code for Android so Kotlin doesn't interest me much yet. A compiled Scala with user value types interests me a lot. Scala's slow compile times do not

2017-08-05 22:47:54
I don't think is a matter of whether one likes methods or not. They are popular, crystal has a more traditional oop approach, and nim doesn't. Javascript's ways are even easier to get than oop, but oop is popular enough. And i have seen this a lot of times in the forum/chat, people asking how to create classes and how methods work. I think the nim community suffers of a severe bias because many have a c/c++ background and probably want nim for the speed/won't care about oop. Now, let's think what are learning new programmers. 2017-08-07 09:52:33

to be fair, I feel that (in general) the critical approach to OOP that people tend to have nowadays is refreshing. c.f., Stroustrup's OOP without inheritance

IMO, what most people need from OOP is dot notation I really like Nim's uniform function call syntax, and, for now, I really haven't missed inheritance (but I confess I never developed something large with it); OTOH, applications I've been developing lately (not Nim) usually DON'T have very deep inheritance chains

vtref really is cool, powerful and unique; my only fear is that it might be hard to grasp for people looking for a cpp/java-like OOP. This should be addressed with clear documentation and examples

2017-08-07 10:19:30
I think a set of macros implementing regular old OOP (and maybe methods too ) should probably go into the standard library. This may require the ability to call macros in a few new ways though.
2017-08-08 04:58:30

Crystal has gotten a highly distinguished mention in this month's update summary of the prestigious TIOBE prog lang popularity index:

The top programming languages are in a long term decline: both Java and C have all time low scores in the TIOBE index. And almost all of the other top 10 languages are going down as well year to year.

So what languages are taking advantage of this? It is all happening down in the charts around position 40. A new set of languages is gaining ground, notably Crystal (#32), Kotlin (#41), Clojure (#42), Hack (#43) and Julia (#46).

Especially Crystal with its jump from position 60 to 32 in one month is doing very well. The Crystal programming language is a statically typed Ruby variant. Since it is compiled it is superfast and has a small memory footprint without losing the feeling of being easy to use. It seems worthwhile to give it a try.

This is very impressive, given that Crystal is a 3-year-old newcomer that we've watched take its first steps, while Nim is still fighting its way into the top 100...

This has just made me realise how unreliable TIOBE is. This is one of the searches that they use: +"crystal programming". Last time I checked (when I was submitting Nim to TIOBE) the number of results was around 20k. Now it's 256k? Go's is 331k (and strangely enough it was 230k, less than 5 minutes ago when I checked it before writing this post, proving once again how unreliable this is). D's is 225k.

Now, sure, TIOBE uses multiple search engines to make its ranking. But I doubt it makes much of a difference to the reliability of these results. I could be wrong but I seriously doubt that Crystal is so close to Go's popularity and that it's more popular than D. And actually TIOBE itself lists Crystal (#32) as being more popular than Clojure (#42), I'm very sceptical that this is the case.

It seems to me that results such as these are giving this result count boost. They obviously have nothing to do with the programming language.

IMO we can nowadays do a much better job at finding the popularity of a language by combining a number of indicators. For example: commit frequency on GitHub, number of watchers on GitHub, number of projects in that language on GitHub, activity and number of users in the respective language's IRC/Gitter/Slack channels. I would have built something that combines all of these already if I had the time because I am very interested in such statistics.

So yeah, let's take this with a pinch of salt.

2017-08-13 00:19:28