brianrogoff: It's hard to quantify the benefits without doing the experiment, so you have to rely on judgement.
Honestly, I don't think there's much performance to be gained. Exceptions can be made fast by using the C++ target or libunwind and there are (non-portable) efficient solutions to deal with integer overflow. Tail calls don't matter much for Nim; C compilers will optimize them where they can, but Nim doesn't need any guarantees (unlike a functional language).
The one big thing that you can't really do well with a C/C++ target is copying GC. The problem is that a copying GC has its own issues, especially for a system programming language. Copying GCs means that the FFI quickly becomes very, very difficult to handle both efficiently and cleanly (see P/Invoke or the JNI).
In contrast, there are actual benefits to having C/C++ as the target that make it worth dealing with the annoyances.
- The code generator is pretty easy to understand. You don't have to be a compiler expert to hack the Nim compiler. This can be pretty important for adopters; you don't have to rely on a Nim core contributor to fix things, you can generally do it yourself.
- Integration with third-party libraries written in C/C++ becomes much easier. I don't mean just c2nim, but being able to use macros, C functions/variables with specific __attribute__((...)) declarations, or interfacing with C++ template magic. Hooking up __int128 or SIMD intrinsics amounts to pretty much only a bit of typing.
- You can package the compiler with your application and bootstrap it in under a minute to build from source even on systems that don't have Nim installed; outside of interpreters, there are not many language implementations that can do that (OCaml is probably the most prominent example, and D currently allows for it, since the compiler is still written in C++).
- The generated code is pretty portable and you can leverage C's cross-compiling facilities without much effort. This matters especially for a system programming language that may need to target oddball embedded architectures, but also for Windows.
A related example here is Unity's IL2CPP, which translates CLR bytecode to C++. They are presumably driven by similar concerns, such as having to interface with third-party C++ libraries that don't magically rewrite themselves in C# or needing to target a variety of architectures.
Would it be nice to have an LLVM target? Definitely, but I'd argue that it'd be even nicer to have a JVM or CLR target to be able to tap into their ecosystems.
- I would much enjoy more aggressive type inference. Even though I like hardening my apps, I want to be able to quickly prototype algorithms.
If one can implement three algorithms for the same problem, in the same time as one algo in, say Rust, or strictly typed Nim, then one immediately has an advantage for the app one is writing. It's important for prototyping to be in the language one is actually going to use it in, otherwise the performance and memory profile of the tested candidates are moot. This is one of the things that make Rust less attractive to me - it's a bit Java-esque - you might not be able to shoot your self in the foot - but you'll shoot yourself in the head instead. Nim is very swift to code in, and more type inference would make it even more prototyping friendly.
- "Pythonish" "inferring" imports would be nice in a 'clang style error messages' way, rather then implicitly silently importing: "Error: undeclared identifier: 'arity'; did you mean to use 'import typetraits' in your module?". Kind of best of both worlds imo.
# On backends #
The fact that the primary backend for Nim is gcc/clang etc. was one of the things that attracted me to it. More options for code generation. I think I can speak for most when I say generating machine code from Nim is out of the question, unless an envelope of $10^9 would happen to fall down into say Araqs mail box.
- LLVM is an interesting backend for future targeting:
- Code that Nim generates seems to benefit from clang - in contrast to that most my C++ projects are always faster in gcc
- LLVM is a cleaner solution (internally I mean) than gcc, and thus will probably beat gcc on most everything in a not to distant future (faster progress).
But such an endeavour should probably be saved for when the language has stabilized post 1.0.
I like that backends are treated like gcc, clang, etc. specifically and not 'general C'. That should be prioritized even more, making use of more pragmas in the backends from the information that exists in the Nim sphere. Of course, it is important to always be able to target 'generic compiler' as to not shut out platforms for no reason.
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...
Perhaps the most important thing that "Nim can learn from Crystal" (referencing my thread title) is how to quickly attract a fan-base. Crystal appealed to the base of millions of Ruby programmers by being much closer to it than Nim is to any existing language. (Crystal is still slightly behind D, Nim's closest competitor with a copyfree license, which also rose by appealing to a specific base of C++ devs.) Promoting Nim to Python programmers (ex), on the other hand, has been a lot more difficult...
I still think that Nim has a lot of potential for mainstream popularity, but the problem is that most programmers out there don't instantly like its syntax. Having multiple syntax skins / compiler front-ends could widely broaden Nim's appeal. It would be like having several languages that share the same AST, compiler back-end, module ecosystem, etc.
Libman: 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...
First, keep in mind that the Tiobe index is of somewhat questionable quality. You'll get a lot of esoteric sites about "programming crystals" when searching for +"crystal programming" on Google, for example, which have nothing to do with either programming (in the IT sense) or the programming language. Crystal still does get more genuine hits than Nim, but it's difficult to get an accurate comparison with other languages.
Libman: Promoting Nim to Python programmers (ex), on the other hand, has been a lot more difficult...)
That's because other than the syntax, Nim and Python don't have a whole lot in common other than the syntax.
Libman: I still think that Nim has a lot of potential for mainstream popularity, but the problem is that most programmers out there don't instantly like its syntax.
If syntax were an issue, Go would never have become popular. I think syntax is in general a red herring, and having multiple syntax skins would just create a "Tower of Babel" effect where people have difficulty reading each other's code.
If I had to guess, I think the biggest problem with Nim is its really unclear approach to OOP. No matter how much forum warrioring goes on about OOP, the reality is that traditional class-based OOP (or a reasonable facsimile thereof) is present in most popular high-level programming languages and (more importantly) virtually every programmer is familiar with it.
Currently, Nim has the following problems with OOP:
- The multi-method approach is unfamiliar to lots of people, multi-methods are verbose, and to use something that looks more familiar, you have to basically roll your own macros.
- The future of multi-methods is uncertain.
- Multiple dispatch can be inefficient if you have a large number of subclasses.
- The vtref approach is not yet implemented.
- Even when implemented, it'd again be different from what people were used to.
- Using vtrefs has different tradeoffs compared to more traditional OOP.
Overall, OOP feels like an unloved feature that exists as a checkbox on a feature list more than anything else. And if you want to transition from Ruby or Python, it's likely to be a much bigger deal than syntax, given how prominent a role OOP plays in both languages. Same goes for C++/C# or most top 20 languages of whatever programming ranking you prefer.
I agree with @Jehan on most points, which really complement rather than contradict what I've said.
Yes, there's no such thing as a perfect benchmark, a perfect survey / opinion poll, etc. But that doesn't take away from the fact that these things are still useful, and that the TIOBE index is a long-standing and reputable source for estimating language popularity. It highlighting Crystal this month was a noteworthy thing to mention as an update to this thread. By all measures, Crystal's popularity grew very quickly.
Yes, syntax isn't everything, but it's still a factor. Nim doesn't have the privilege and prestige that Google Go had right off the bat.
[...] syntax skins would just create a "Tower of Babel" effect where people have difficulty reading each other's code.
Syntax skins wouldn't "JUST" have that one negative effect - which isn't really as bad as a "Tower of Babel", because people who understand Nim wouldn't have such a hard time understanding its more Pythonic flavor, the curly brace flavor, the Ruby-ish flavor, etc. Those flavors would use the same modules and share most of the concepts and tooling.
More importantly, syntax skins would have a positive effect of growing the Nim ecosystem while taking nothing away from the Nim language itself.
I think the biggest problem with Nim is its really unclear approach to OOP.
I happen to really like Nim's approach to OOP. But, when talking about what affects Nim's popularity, we should be basing our claims on opinion survey results... (Which means we need more and better surveys.)
If I had to guess, I think the biggest problem with Nim is its really unclear approach to OOP.
I doubt that that's the biggest problem.
No matter how much forum warrioring goes on about OOP, the reality is that traditional class-based OOP (or a reasonable facsimile thereof) is present in most popular high-level programming languages and (more importantly) virtually every programmer is familiar with it.
bpr: I doubt that that's the biggest problem.
The context here is people transitioning from other languages. In this regard, OOP is probably the single biggest impedance mismatch. The point I'm getting at is that Nim supports pretty much all other major features that you typically find in mainstream languages such as Java, C#, Ruby, and Python. OOP is the big exception as far as language semantics are concerned.
For all the rhetoric, Go's object system is a pretty traditional one. Its one unusual feature is that it allows for structural subtyping, but that's hardly unique and (importantly) less of a constraint than nominal subtyping. Note that the absence of a "class" keyword as such does not mean anything. You could do OOP in C++ by using struct instead of class, too (which only affects visibility rules).
We'll see where Rust goes; in many ways, it's too radical a language to have seen much adoption outside of its core niche (programming close to the metal where automatic memory management is not an option), but the borrow checker is probably a much bigger pain point here than anything else.
Julia has its own domain (mathematics), which has different needs compared to a general purpose language and also a ready-made audience that's willing to trade a learning curve for a language that's well-suited to its domain.
- Language:....Claim To Fame........................Failure Point
- Crystal:........Slick As Ruby Fast as C;..........No Windows Support(Yet)
- Red:............Full Stack, EASY! gui;...............Documentation LACKING!
- Nim:............Multi-platform, Great GC;.........Nothing significant
- I realize this is a naive and over-simplified perspective but I think it may help highlight the way many "outsiders" see it.
- Crystal and Red are good examples of languages that have a pretty significant failure point but have "Claims to fame" that entry level programmers get excited about.
- Nim is a solid language with good performance and no obvious failure points.
- Imagine cheerleaders (who doesn't like doing that) chanting the tag lines. yay.. platforms... garbage collection. VS "SLICK AS RUBY FAST AS C!!!"
- I think marketing plays a bigger influence on language popularity than it should.