It's interesting to hear the constraints the language developer wanted from the beginning (20k lines, macro system drives most of the language development) and the various compromises they had to make along the way.
> Furthermore, we don't really know yet how to leverage a macro system in order to give us extensibility on the type system level, so Nim's core needed generics and constraints for generics.
I'm curious to dig into Nim and it's type system. I'm not familiar with Pascal style typing, I wonder how it compares with Rusts type system?
I haven't looked into Nim in as much detail as Rust (though I did make some contributions to the compiler/language a number of years ago), but one aspect that has always seemed notable to me is that it seems to defer type checking of generic code until it is instantiated (this is what happens in C++), so these functions will all typecheck until you actually try to use them:
proc foo[T](): float32 =
result = "foo" + 4
proc bar[T](n: T, m: T): T =
result = n(m)(n)
In Rust, such functions would require some sort of explicit constraints on `T`, so it's more-or-less guaranteed to be instantiable (ignoring the issue of polymorphic recursion) and you don't get some error pointing to code internal to the function when the user applies types that don't work.
>it seems to defer type checking of generic code until it is instantiated (this is what happens in C++) ... and you don't get some error pointing to code internal to the function when the user applies types that don't work.
Worth noting that C++ is going the opposite way with concepts. The compiler still won't enforce that `template<typename T> void foo(T t) { t++; }` needs a `requires Incrementable T` (like Rust would require with trait bounds). But if `foo` does use the concept `template<Incrementable T>`, then a call like `foo(S{})` will raise an error at the callsite, not at the `t++` line.
Interesting. From what I remember of Go's generics proposal, they seemed to be trying to do something similar, which seemed a bit hacky to me (as you say, it addresses the error reporting issue but it's difficult to see how the constraints would be used to actually check the generic code, so functions can presumably still lie about being "for all types").
EDIT: actually, Go's generics proposal probably doesn't have that issue, since the contracts are restricted enough to derive type declarations from them.
> EDIT: actually, Go's generics proposal probably doesn't have that issue, since the contracts are restricted enough to derive type declarations from them.
Just wanted to add that my initial memory was apparently of the earlier proposal for generics in Go, as reflected here: https://dev.to/deanveloper/go-2-draft-generics-3333 (in this earlier proposal, contracts simply specify code that is expected to compile, in such a way that it would be difficult/impossible to derive types for symbols introduced by the contract).
I guess the golang people figured out why that was not an optimal system and changed it ... wonder if the same will be true of Nim.
Congrats guys!!! This has been much-anticipated and I'm very excited. I personally wish that the owned reference stuff (https://nim-lang.org/araq/ownedrefs.html) had been part of 1.0, but I think that at some point shipping 1.0 >> everything else.
I've been following (and evangelizing) Nim for a while, this will make it easier to do so.
I don't think the owned reference part will change the language drastically. For people that want to write kernels, games or real time code it would be great. Nim's GC is super configurable already. Yeah owned reference would be better but its already pretty good.
I don't quite understand the definition of "memory safety" in that document. If deallocation can cause other objects to end up pointing to the wrong thing and the wrong data, how is that different from memory corruption?
If your filesystem suddenly starts returning the contents of notepad.exe when asked for user32.dll and vice versa, is that not filesystem corruption?
If an admin user object can suddenly start pointing to the guest user object and still be considered "memory safe", that doesn't seem like a very safe definition of safety.
It's type safety. The pointer will always point to an object of the same type. This is common in operating systems, for example. You have some out of band way of verifying that the object's identity has not changed (deallocation would be a change of identity) when you access the object under some sort of serialization.
It's certainly a weaker definition of memory safety than you and I, and I would guess most people, would have in mind. So in that sense, I think the author is wrong to call it memory safety.
You're totally correct that a logic bug in this category could cause a credentials pointer to point to a different or higher set of credentials, and that is an implementation risk.
i guess the argument is that you'll never read random garbage instead of a well-formed object; and given that random garbage could result in pretty much arbitrary "undefined behavior", it should at least guarantee that your program will behave roughly as intended, even if giving incorrect results
> and given that random garbage could result in pretty much arbitrary "undefined behavior"
Nitpick: UB doesn't come from reading random garbage, it's quite the opposite: UB could result in reading random garbage, but it could also result in many worse things.
I don't get why some languages adopt the 'PascalCase for types' approach (which is fine), but then a bunch of the built-in types such as 'string', 'set', 'int64', etc. are lowercase... it's annoyingly inconsistent.
In C# the lowercased ones are keywords, some of which map to built in types. For example "string" is a keyword that always means the type String (System.String). The word name "String" could be a type that some nefarious person added to your current namespace
On the contrary, I feel that the stylistic [and sometimes semantic] separation of primitive and boxed types in languages (e.g., `byte` VS `Byte` in Java) improves the developer experience, in that I can very quickly dissect the type of value that I’m dealing with when reading the code.
In Java that difference matters a lot for performance: primitives are unboxed, objects are boxed. (Not as true now with auto boxing and escape analysis, but this was absolutely true in version 1.0.)
In C++ it can matter for correctness because primitives are uninitialized by default. But other types might be too and the standard library uses under_scores for things that are initialized on construction, so it's not a great example of this distinction.
Why do you care in other languages? In Rust for example I'm a little fuzzy on why I care if something is considered a primitive.
In this case it might be a 'documentation as code'thing, being able to see at a glance if something is a language primitive or a potentially very different implementation could have value.
However I'm not super familiar with Rust, so I couldn't speak to that why.
I've had Nim installed on my laptop for a long time and I've always enjoyed tinkering around with it over the years. Maybe now it's time to find a bigger project to try it out on.
This is a tiny thing, but just to highlight something unique I like about Nim, using `func` to declare pure functions (and `proc` for others) has been a small, but really nice quality of life improvement. It's something I've been wanting in other languages since Nim added it.
It seems like the 2010s have been a pretty amazing time for new programming languages. The ones that I can think of that I've at least tried are Rust, Go, Nim, Crystal, Zig, Pony, Fennel, Janet, and Carp (I know, some of these are pre-2010, but I think they've all either 1.0'd or had a first public release post-2010), and every single one has made me really excited about some aspect of it. I hope this experimentation continues into the 2020s!
And it turns out Crystal 0.31 [1] is released! And it is ( or should be ) closing to 1.0 release as well, once Windows Support and MultiThreading matures. May be 2020?
On the list of languages I only know the first few up to Zig, will need to check out the others. There is also one noticeable missing and that is Elixir.
Curious why you're adding Elixir in this list ? It operates is in a completely different space than nim / zig, as far as I know (Not statically checked, heavy but powerful runtime, much "higher level" abstractions, etc...)
Not to prevent you from trying it, of course - to each and everyone their own...
Not the same person, but I interpreted the preceding comments to be about programming languages in general, not just ones in the same space as Nim and Zig, and would agree that Elixir fits in that broader list.
That's so interesting. I absolutely love Elixir, but I just never saw it as a replacement for Python. (Which I hold in high regards as well) Perhaps it's only my experience with both langs. Elixir I used for JSON API type things, while Python I used for all types of general purpose stuff. Both are great, but Python is super popular with the science crowd (I used it for GIS/Geoprocessing tasks). Maybe Elixir has similar packages and I just never went to look....
There are a great many people who don't do any heavy maths/sciences data crunching, for whom Python is just their web+scripting language of choice. For those people, "Python" fits in the set of {Perl, Python, Ruby, Node, ...}. Elixir does fit quite comfortably in that set.
I use both Python and Elixir. Python for web scraping and Elixir for my side project website.
I can see if people want to move web dev from Python to Elixir but yeah not entirely bailing out for Elixir. BEAM VM in general is terrible for numerical stuff. Elixir is pretty niche, it solve one thing concurrency problems. Python is a much more general language.
You could argue that Elixir isn't a 'new' programming language. While it obviously technically is, in practice you could see it as a nice coat of paint over Erlang and the BEAM. This is absolutely one of its strengths - it brings tooling, a more familiar syntax and macros, but really just allows us to build using a great programming paradigm and 30 years of solid engineering.
For some reason, a lot of fortran programmers insist on screaming, even though it’s been optional for 3 decades. I mostly program in python these days...
I've really liked that, too. Its approach to mutability is also very nice.
The combined result may not be nearly as principled as the Haskell way of doing controlled mutability with double-checking from the compiler that you aren't breaking your own rules, but it's a nice pragmatic compromise that's easy to understand without having to rewire the way you think about programming.
Also const/let/var declaration keywords for whether something is constant and whether its known at runtime or compile time are also very very friendly.
I'm using a weak-CPU machine these days, and it turns out that everything is slow and cpu-hungry except native code and Lua. Lua blows even JS out. Specifically, my scripts seem to be done faster than Node.js spins up.
I was really excited when I saw V for the first time. Then as I was checking the claims one by one it turned out the author was only half honest. That was bad, really bad. I don't feel like visiting this website again and wonder if any of these claims are true or just a kind of strange marketing in order to collect donations.
I think that's wrong. Isn't Fortran's procedure/function distinction between things that return a value and things that don't, rather than between things without side effects and things that might have side effects? The latter is what Nim's func/proc distinction is about.
(Modern Fortran does have a pure keyword meaning "no side effects", but that wasn't there "since the beginning".)
[EDITED to add:] I checked in the Fortran 77 standard. The difference between a FUNCTION and a SUBROUTINE is just that the former returns a value and the latter doesn't; in the code for a FUNCTION you are absolutely allowed to do I/O, modify global variables, etc. Functions (and subroutines) can change the values of the variables passed to them. There are also things called "statement functions" which have to have single-line definitions along the lines of "square(x) = x*x"; these don't have to be pure either because the defining expression may call functions that have side-effects.
> using `func` to declare pure functions and `proc` for others
What's the limit used by Nim in its definition of a “pure function”? Is function that allocate memory considered a impure one? (technically it is, but it really reduces the usefulness of such keyword if it's too restrictive, that why Rust don't have it for instance).
I love nim! Wrote a several-thousand-line side project in it in 2015 and have rewritten it several times over, partially to improve the project itself, but also to keep up with language changes during the various alpha-releases. Did a little evaluation of Rust along the way, but decided my money was going to continue to be on nim. -- Congrats to the team, and thank you so much for making it happen!
Those are valid questions when evaluating an unknown technology. How could anyone consider this trolling? Not to digress but have we become too sensitive?
It all depends on the tone of the question, which is hard to discern in writing, so the clarification is helpful.
Edit: Yes, those are very valid and reasonable questions. Clarifying that it's not meant as trolling is also valid and reasonable, because writing is easily misunderstood in exactly that way - which is the reason smileys were invented. (And, to be clear, I'm not accusing anyone of missing smileys or of trolling. I am trying to express my agreement with both parent and grandparent.)
I've seen that comic before but have no idea what it's trying to express, could you explain? Is it just when you repeatedly pester someone with questions to annoy them?
Unfortunately, asking questions on the internet is often seen as "opposing" or "arguing against" the thing you're asking about. So many qualify their statements to avoid this sort of misreading.
Communication by writing is harder because you miss facial expressions. Because of this, a lot of it is subject to interpretation on the part of the reader. The tone can be inferred from a lengthy piece, but not so much from a small paragraph.
So, in order to avoid bias on the reader part, I preferred to explicitly tell it was not trolling.
To me Nim is a faster python that prevents typos. It can also compile to javascript.
I used it where I would use python - backend of web apps. But now instead running a cluster of servers I can just run 1 because nim is fast.
I also used to write frontend in CoffeeScript, but switched to nim because I can share code between backend and frontend. I don't have typos. I don't inherit any JS or OOP legacy like TypeScript.
This was sort of my use-case and experience as well. I also find it can do what I needed JavaScript-based CLI tools to do with less dependencies/ecosystem bloat, and the resulting code is a lot nicer to work with. People have told me that's because I was using JS wrong, but I felt like Nim was such a huge step up for my use cases.
It's also just a pleasure to learn something new occasionally.
At first blush, it's easy to describe Nim as C-flavored Python, but I'm not sure that quite captures it. The syntax is similar, but that's about where the similarities end - Python is deeply, fundamentally a dynamic language, and Nim one of the more firmly statically typed non-functional languages out there.
You could also describe it as being competitive with Rust, but with more compromises for the sake of developer ergonomics. Garbage collection, for example.
For my part, I'm finding it attractive as a potential Java-killer. It isn't write-once-run-everywhere, but, now that x86 and Linux have eaten the world, that's not quite such a compelling feature anymore. And Nim smooths things over a bit by making cross compiling dead easy. In return, I get better type safety, better performance, a much better C FFI, and less verbose, easier-to-understand code.
I think there's not much merit in discussing "C-flavored Python" as a description of nim, as that description seems just wrong.
Aside from significant whitespace, I don't find that many similarities with Python syntax.
Describing Nim as non-functional is misleading. Nim does have functional constructs and is a mixed-paradigm language involving both procedural and functional elements, just like Python.
"Firmly statically typed" is misleading. It's actually strongly-typed with great capabilities around type-inference so that, at times, you start to forget that it's typed in the first place and gives you a similar feel to a dynamically-typed language like Python.
Nim can run with garbage collection disabled. As a matter of fact, I seem to recall that the authors postulated that as a basic requirement that the language should be able to run in a low-level systems programming mode with garbage collection disabled (where it would be able to compete with Rust), and in a more high-level mode where it would rather compete on developer ergonomics/productivity.
I find Java-killer a potentially misleading analogy. I do think that it captures the kind of platform-independence that matters nowadays. And that is no longer Intel vs Sparc and Windows versus Linux, but rather the native ecosystem versus the JavaScript ecosystem.
Not agreeing or disagreeing with either of you just wanted to add some details to the garbage collector thing.
Nims GC is able to either be controlled in terms of when and how long it runs, and it can be completely disabled in favour of manual memory management. In fact people have gotten it to run on really low-powered microcontrollers like the Attiny85, as well of course as various Arduino boards. The benefit of Nim in these systems is that since it compiles and has such a rich macro system your are able to write abstractions that the compiler will turn into highly efficient code. So you can still write business logic level readable and maintainable code, while the compiler spits out super-optimised versions. This of course requires you to first write these macros, but often times a little goes a long way.
Well: Nim is similar to Python in many respects, it's just not "C-flavored Python".
It has significant whitespace like Python. But since it has a lot of language constructs that are different from Python, it's a bit tedious to try to otherwise compare the syntax a great deal, and it has many elements to its syntax that are quite unique.
Saying that Nim is statically typed whereas Python is dynamically typed is exactly a feature that's a slightly unfortunate pick for trying to contrast the two, because type inference is trying to bridge the gap and give you something that's a bit in-between in terms of how it feels to the programmer.
Nim is similar to Python in that (a) It's very cleaned-up and allows you to do a lot of stuff and complex stuff with little code, without sacrificing clarity and readability. (b) It puts the programmer in a cognitive mode where he can think first and foremost about the problem at hand and not have to concentrate on the programming language so much. (c) It gently guides the programmer towards good programming practice without being patronizing. (d) It has a fast learning curve,...
Essentially all the things that make Python great are found here as well. But nim gets there on its own, not by replicating elements found in Python a lot. It's very unique in a way that makes nim a great choice of language in situations where Python isn't (like systems programming or writing code for the Browser ecosystem).
I'm not sure I should be getting involved, here, but I haven't had my morning tea yet, so what the hey --
It seems like you're hyper-focused on a rather skewed interpretation of my first sentence, to the point that you largely ignore the second sentence. Or at least you seem to ignore everything after the word "but", which, given what the word "but" is often used for, is a rhetorical move that has a way of enabling interpretations that tend to be close to the opposite of whatever was originally intended.
Parent poster has it right. I picked that initial comparison to Python by way of introducing one of the more popular summarizations of Nim, so that I could say why I don't think it's a good summary. If I didn't put it emphatically enough to satisfy you, I apologize. I apparently don't have anywhere near as strong of feelings on the subject; Nim's just a language I like to program in sometimes.
> In fairness, Python is the first language the Nim team compares itself to in the first paragraph of their homepage.
Probably because most people are more familiar with Python than Ada and Modula (combined) ;)
I guess it depends on your previous experience. Some people will only see Python, others might think of Nim and its syntax as "Pascal for 21st century" (fun fact: the original Nim compiler was written in Pascal).
Nim's syntax is very similar to Python simply because both are expressive, lean and have no braces.
Naturally Python is dynamically typed and this, unfortunately, affects performance and maintainability.
Don't get me wrong; Kotlin is a great language and, if I have to work on the JVM, it's one of my top two picks.
But, being a JVM language, it's still stuck with all of the Java shortcomings that I had listed before: Achieving a decent level of type safety is impossible, the FFI is still a pain to use, and you've got to go through contortions to get really good numeric performance. Because all of those problems are characteristics of the JVM's run-time environment, not the language you're using to target it.
Most of those Java shortcomings are in the process of being fixed, while still enjoying one of the best language eco-systems currently available, with libraries for almost any kind of problem domain.
The fact that it uses C as a compilation target doesn't have much to do with whether it's as fast as C in practice. It's easy to imagine a compiler that generates C but generates terrible C that runs really slowly. (E.g., imagine it goes via some sort of stack-machine intermediate representation, and variables in the source language turn into things like stack[25] in the compiled code.)
Or consider: Every native-compiled language ends up as machine code, which is equivalent to assembly language, but for most (perhaps all) it would be grossly misleading to say "as fast as assembler".
I’m not sure that I understand your argument. If the code from which the resulting machine code is compiled is C, then it’s objectively “as fast as C” … because, at the end of the day, it actually is C. Being “as fast as C” means that your resulting program will perform as fast as a C compiler [worth its salt] can get you.
Your comparison to machine code (or human readable assembly code) is less useful in that such a statement means very little until one knows how said machine code is being produced (e.g., manually, from a IR, etc.).
"As fast as C" would commonly be interpreted as "a program written in it will be as fast as a well-written C equivalent", not as "there is a C program with the same performance characteristics".
That a language is compiled to C does not mean that its compiler is going to be able to produce a C program that's as good as a that well-written C equivalent. (A relatively obvious example would be a compiler that introduces a heavy runtime, and doesn't give the C compiler enough information for it to get rid of the runtime)
It's the same with assembly code: that a compiler produces assembly does not mean the resulting program is fast.
> "As fast as C" would commonly be interpreted as "a program written in it will be as fast as a well-written C equivalent"
That’s your interpretation, which is fine, but the objective meaning stands. Even the idea of “well-written C” is, in my experience, fairly subjective amongst C programmers.
You're missing the point. The fact that a language compiles down to C doesn't mean it compiles down to efficient C. At the simplest level, the compiled code could add a bunch of unnecessary function calls and pointers and other forms of indirection that wouldn't be present in hand-written C. But for a more extreme example, you could also compile an interpreter or VM to C, and it would still be much slower than the equivalent hand-written C code. This is why "as fast as C" typically refers to normal, hand-written C code—even though there is no formal definition for what "normal C" looks like, it's still a useful description.
> The fact that a language compiles down to C doesn't mean it compiles down to efficient C.
Where do you see me claiming otherwise?
> At the simplest level, the compiled code could add a bunch of unnecessary function calls and pointers and other forms of indirection that wouldn't be present in hand-written C.
Again, why are you telling me this? Please quote where I claimed otherwise.
> But for a more extreme example, you could also compile an interpreter or VM to C, and it would still be much slower than the equivalent hand-written C code.
The more that I read your response, the more that it seems that you’re debating yourself, because I’m not sure why you’re telling me this. You started your response by telling me that I’m “missing the point” when, in reality, you seem to have not even read my point. My main point was the following:
> If the code from which the resulting machine code is compiled is C, then it’s objectively “as fast as C” […] your resulting program will perform as fast as a C compiler [worth its salt] can get you.
This is true. I made no claims re efficiency; “as fast as C” and “as fast as efficient hand-written C” aren’t interchangeable claims. Forgive me for not assuming efficiency, because I’ve seen a good amount of inefficient hand-written C code in my years.
> This is why "as fast as C" typically refers to normal, hand-written C code—even though there is no formal definition for what "normal C" looks like, it's still a useful description.
Says who though? I’m professionally experienced in C, and as is very clear by this discussion, it’s down to individual interpretations.
But that's not at all a useful way to describe a language. Why would someone ever describe a language as "as fast as C" and not mean "as fast as typical hand-written C"? What would be the purpose of that? With your interpretation, CPython is "as fast as C", since it's written in C, and yet that's not a claim anyone would actually make.
Remember that we're comparing languages, not programs. A language can be thought of as the space of all programs that can be interpreted by that language. In any language, any algorithm can be implemented arbitrarily slowly. So the only meaningful point of comparison between language X and language Y is the upper bound on the performance of each language's program-space.
That some particular C program exists that is at least as slow as a program in some other language is always true, trivially, and so is not a good interpretation of "as fast as C" regardless of its objectivity.
JVM, CLR, Python bytecode or Lua JIT code are ultimately all transformed into machine code but those are not as fast as assembler.
Being as fast as C is not about using C as an intermediate language but having data structures and control flow that resemble what C compiler have been optimized for.
Case in point, Haskell GHC is capable of outputting C code but the algorithm will not get C performance (or Haskell performance without this intermediate C representation).
Suppose I claim that some programming language achieves performance "as fast as C". Then, unless I very clearly and explicitly say otherwise, it will be assumed that if I write kinda-C-like code in that language I will get performance similar to comparable code actually written in C.
But that doesn't at all follow from compiling to C. I gave one example above; here's another. Perhaps my programming language has arbitrary-length integers and the C code it produces for a simple loop looks something like this:
bignum_t i = bignum_from_int(0);
bignum_t x = bignum_from_int(0);
while (i < bignum_from_int(1000000)) {
bignum_add_in_place(x, bignum_bitand(i, bignum_from_int(1)));
}
Corresponding code in "normal" C would use machine integers and the compiler might well be able to understand the loop well enough to eliminate it altogether. Code like the above would run much, much slower, despite being technically in C.
In fact, you can transpile Python to C with Cython. That typically gets one a speed boost, but only a bit. You still have most of the memory allocation/deallocation overhead of Python objects getting created and destroyed, and all the work needed to keep attributes tracked, so a straight C version with no focus towards optimization would likely outperform it greatly.
(A neat tool in one's toolbox, of course. But just transpiling to C does not get one as fast as C.)
Nitpick, but it actually compiles down to C. Nim works at a higher abstraction and the compilation is a one-way street. But what is more important is that it generates efficient C code, it looks ugly, and it's not something you would ever dream of writing yourself, but it's been optimised to give fast run-times. Often times in benchmarks the Nim code with optimisations comes out as fast as the C code with optimisations, even in some cases beating it.
Since you seem to know how this works -- I hope you won't mind if I ask you a slightly on-topic question about this...
I've been trying to find out if I can take the generated C code that nim produces and, for example, compile it on some exotic architecture (say an ancient solaris/sparc system or some aix/power thing, or some mips microcontroller with linux) however I can't find any examples of people doing this...
Is it possible? Or should I abandon hope and continue writing C for these platforms? :}
As the others have said it should be possible. Nim is already pretty good at cross-compiling, but it is also able to just spit out the C files it generates and allow you to play with those.
Nim occupies an interesting place between Rust and Go. It has an easier learning curve than Rust. I picked up the basics in a weekend, and some of the more advanced functionality over a month. The optional GC is ideal for the application space, and I also don't find myself fighting the compiler very frequently. When compared to Go, Nim provides a lot more functionality. Object variants, a working implementation of generics, not to mention a great macro system.
I stumbled onto nim because a sequencing-data (DNA/RNA/etc) library was written for it (https://github.com/brentp/hts-nim). In addition to Go, it's been a great way to learn a compiled language. It's fast, easy to use, and has a friendly community.
I have only used python (check out cyvcf2 by brentp!), R, and bash previously - so nothing else really compiled (its faster than these in general). But my guess is that you will have an easier time writing nim than the alternatives, and after that it is easy to optimize once you have basic functionality.
For a side project of mine, I recently re-wrote the same code in a dozen or so languages. The application reads input data from text file and does a bunch of conversions to integers and floats (atoi and atof). It then runs through an algorithm that does calculations and identifies proper actions. Finally, it writes the output data as formatted text file. Regardless of implementation, it runs quick. Sorry I can't provide more details on nature of the code (it has IP that belongs to another person).
Here are the top 10 best execution times (all run on same hardware). Times obtained by 'time' utility (e.g., "time ./run.sh"). Some of these were run on Ubuntu 16.04 and a few were run on FreeBSD 11.2. Where the compiler has optimization flags, I used it.
1. C++ 0.04 (gcc version 5.4.0)
2. Rust 0.11 (version 1.37.0)
3. Go 0.13 (version 1.12.7)
4. D 0.16 (tied with Pascal) (DMD64 D Compiler v2.073.2-devel)
5. Pascal 0.16 (tied with D) (fpc 3.0.2)
6. C# 0.25 (mono 4.8.1)
7. Nim 0.50 (1.0.0)
8. Kotlin 0.81 (Kotlin version 1.3.50-release-112, JRE 1.8.0_222)
9. Java 0.95 (openjdk version "1.8.0_131")
10. Scala 1.79 (version 2.12.2, running on 1.8 openjdk)
Surprised to see Nim that slow, typically it ranks much higher in benchmarks. But without looking at the code and compiler options its hard to tell if it is simply the problem or the implementation that's to blame.
The second one has a really useful utility called "stack" that you can use to concatenate datasets where one might lack some columns or the columns come in a different order. It glues it all together and has an option to include the filename. It's useful for data analysis.
Both of these lack 'polish' at this point but a few of the subcommands work quite well.
When I started an enterprise data project with a small team where Python was the familar workhorse we stopped for moment initially to think of ways to improve performance. Cython was the familiar route with Python but we started building small prototyes in Rust, Go, and Nim. Beyond the basics our progress slowed down with Rust and Go (yes, I know Go is very easy for some) but Nim allowed us to put together a fully fairly complex application in short time. Just one book, 'Nim in Action', gave us all the ropes, every example in it worked (thanks Dominic), and some of our key integrations such as Postgresl Client drivers, built-in web UI (Jester) framework, Json processin, Nim's build/packaging support, generics, fast static typechecking, etc were exceptionally robust (for this young a language) and worked in an intutive way for us ... we reached production rather smoothly.
I'm curious why did your progress with Rust stalled and at which point? I’m starting to learn it and so far I haven’t noticed any productivity blockers.
I heartily wish that you continue learning Rust, another significant contribution to open source languages. What has been already commented, things such as borrow/checker are humps you work through and it will work out for you eventually. The other challenges are some of your enterprise 3rd party integrations with the outside world, some of which may again demand your time if they are still in beta, etc.
Also, the organization has no desire to invest in training or experimenting. The project is funded by the "business" and they want to see a business result in return for their money ... so you basically you sneak in a bit of time as you try/test something new. Nim won out by somehow getting a team with python expertise learn and deploy their product fast enough.
When you've internalized its rules, the borrow checker isn't too complicated to keep happy (you may need to use stuff like RefCell and Rc though). It takes some time though, and this tutorial helped me a lot in the beginning: https://rust-unofficial.github.io/too-many-lists/
I'm from Status, Nim's main sponsor and a blockchain company that is doing Ethereum 2.0 research and implementation in Nim.
Nim had the following appeal for us:
- Ethereum research is done in Python, we actually started our code with a tool called py2nim to convert a 50k lines Python codebase to Nim in less than a month (and remove cruft for 3 months but that's another story).
- Nim allows us to use a single language for research and production: the Python syntax, and the fast compilation speed are very helpful. In particular researchers found the Nim codebase easy to debug as the overhead vs the Python spec was quite low (and the Python spec is using types with mypy)
- Nim has a easy C FFI and is one of the rare languages that can directly use C++ libraries, including header-only template heavy libraries.
- Nim allows tight control over memory allocation, stack vs heap objects, has support for Android and iOS and very low-memory devices as well.
- Nim also can be very high-level
- Nim is as fast as C and can resort to inline C, inline C++ or inline assembly when needed. (inline javascript or Objective C are possible as well)
- You can produce WASM code via clang, emscripten, binaryen, there is even a Nes emulator demo from 2015 running in Nim compiled to WASM here: https://hookrace.net/nimes/
- Nim has a strong type-system, including generics and type-level integers, boolean and enums.
- Nim has probably the best compile-time capabilities of all languages. I'm writing a deep-learning compiler in Nim macros. Someone wrote a Cuda code generator in Nim macros, and the code generation is extremely nice to write a VM, an emulator or any kind of assemblers as you don't need to use an intermediate step to generate your opcode tables or generate your functions from that table.
Now on a personal note, I use Nim to write a deep learning framework similar to PyTorch or Tensorflow.
I think it's the best language to solve the 2-language problem, i.e. write research in Python, R or Matlab and production in C, C++ or Fortran.
The operator overloading or even operator creation is very useful. The macros allow me to have a slicing syntax similar to Numpy, something impossible in C++. Compilation speed is very nice as a developer, I don't know how people deal with waiting for C++ CI.
I reimplemented a matrix multiplication with performance similar to handwritten assembly BLAS from OpenBLAS and MKL in pure Nim so I'm not worried about performance as well.
Now I'm onto refactoring the backend with a proper compiler (similar to Halide but since it will be macro-based, there won't be the 2-stage compilation issue)
I like Nim very much, however I do not think it will solve the 2 language problem. One of the things I lean on heavily in Python when experimenting and researching is the dynamic nature of the language. I believe this is also a strong factor for others.
For me, Julia completely addresses the 2 language problem. In practice I think it now simply needs a stronger ecosystem, better static analysis, and bug fixes, but I am very happy with the language design.
Some good arguments, but the "main sponsor is blockchain-y" was a bad start for me. That totally killed my interest in RED... Is this as in "biggest patreon donor" or "company that employs main developer(s)"?
Well the Nim team at Status is a separate team working on an open source Ethereum 2.0 implementation, rather than any blockchain 'product' (unless you count a working 2.0 client as a product).
Their goal is to get Eth2.0 (and 1.0) running on very low resource environments such as raspberry pi and turnstiles.
What this should tell you is that:
* Nim is close to the metal enough to run with high performance and low resources.
* In a cutting edge research arena, where the math is still being decided, Nim allows such rapid prototyping that the team is on par with much larger teams in much more established languages.
* All the tools required to build an ethereum platform are present and running, such as security, encryption, and networking such as devp2p. Here's their eth library docs for some of the contributions: https://nimbus-libs.status.im/lib/nim-eth/
Status is pretty dedicated to open source, and whilst they're the biggest patreon donor, the Nim team is completely autonomous.
It occupies more or less the same space as Go: it produces fast standalone binaries with garbage collection. However, unlike Go, it isn't shy to give more features to the programmer to play with.
The cons are its lack of enterprise backing, its smaller community and its syntax, if you don't like either Pascal or Python.
What I wanted to write was something like type restricted generics, apparently I ended my comment prematurely. Without concepts (interfaces), I find it hard to call this system "good generics" but there might be something I'm missing.
This is super cool. I built a small CLI tool with Nim back in 2017, and it was a joy. It ended up being very accessible to the rest of the team for further development (probably more credit due to the folks building Nim than to my design) and I believe it's still in use. It's a good language, and it was a nice break from JavaScript (which I also enjoy, but not so much for CLI tools). If you haven't tried it out yet, I highly recommend it.
As far as I know, that should be doable. Nim can compile to Objective C as well as C++, and has a `when` statement that makes it easy to produce code for a specific OS or language target. Not an Xcode or .NET expert though, so not sure how difficult it is to hook into those platforms.
Without knowing any more specifics about your problem it seems like this would be possible in Nim. It is cross platform and can generate dynamic libraries across them. I guess you could somehow also set up a static library, but I've never tried that myself. So as long as your target language(s) have the ability to use dynamic libraries then Nim should be able to supply them.
WxWidgets works great, Gtk(2/3) also works great (both have macros that make actually creating UI's much easier than in most other languages). There is also wNim for making Windows UIs and NiGui for pure Nim cross platform UIs (that target the native toolkits). Apart from that there are various bindings to other toolkits, both meant to be embedded in games, and stand-alone things. There's even ways to use Nim code to power Electron apps.
So all in all I'd say it's pretty decent, but I still have plans for my own toolkit that would solve my personal gripes with creating cross platform UIs.
I'm curious about why you want to develop your own toolkit and what will differentiate it from the others. Will it draw its own widgets, or wrap platform-native toolkits?
Well it all started when I wrote the genui macros for wxNim and the Gtk wrappers. I started working on a rather simple note-taking application and had an idea in mind for what I wanted it to look like. Turns out this look wasn't possible in wxWidgets without resorting to custom widgets (because the Windows back-end didn't have support for something none of the others could support it). So I had to switch away from wxWidgets and use Gtk instead, not a huge issue for that project since I was just going to use it for personal purposes anyways, but it made me realise something. There isn't a single cross-platform UI toolkit that allows me to learn that one library and then create UIs for either all the targets, or one specific target. The idea has then gone through many revisions and back and forth on implementation ideas, but the current vision is to base it on Nims powerful type system. So instead of saying that "I want a wxTextCtrl" you say "I want to have a way of editing this string". Then it is up to the target toolkit to have an idea of how a string should be edited. Then any sort of styling of the resulting UIs are done on a per-platform basis, with whatever tools are available for that platform. This will also allow the toolkit "drivers" to take in their own UI specifications (for example Glade for Gtk) and map the types you supply to parts of the UI. Essentially separating the UI generation completely from the code/logic. The benefits of an approach like this is that for a simple UI that is only meant as a front-end for some algorithm you can just specify your inputs and actions and the UI can be automatically generated for you across platforms. If it looks weird on one platform you are able to specify for that platform what modifications to make. Or if you want to create a beautiful shiny graphical application you are able to tailor make every aspect of the UI for the target platform and then bind it back to your code. This is probably already way longer than what you expected, or even wanted, I've been thinking about this and toying around with implementations for a while now. I had an early prototype that created widgets for Gtk and Karax (Nim web front-end toolkit) that worked really well, but I hit some snags with the implementation in an earlier version of the language. Now that the language is more mature, and I'm more used to it, I might finally be able to implement it properly.
I'm enjoying NiGui[0]. It uses Windows (Win32) API for Windows and GTK3 for Linux/Mac. It doesn't have every feature added yet, but it does have quite a few and is easy enough to add more. I've personally contributed a bit to this repo in hopes it grows in popularity, I found it to be one of the easier GUI's to work with (with Nim).
Shameless plug, but by a nice coincidence, Manning has a discount on all printed books today. Among them is my book, Nim in Action, available for $25. If you're interested in Nim it's a great way to learn :)
It was published in 2017 but we've ensured Nim is compatible with it (all book examples are in Nim's test suite), so apart from some minor deprecation warnings all examples should continue to work.
I bought a copy of the book a few months back (and haven't yet found time to read it fully, I can write a lot of programs just after reading a first few chapters), will Manning upgrade it for a newer version for Nim 1.0 ?
> will Manning upgrade it for a newer version for Nim 1.0 ?
The version of the book you bought (and which is still on sale) is compatible with Nim v1 and it is still relevant, no need for another version anytime soon.
I've been intermittently working on my own language ("transpiled" to C) for more than three years before seriously checking out Nim in 2015, at which point I just threw my code away. It already had very nearly everything I thought I could bring to the table, and then some stuff I had never even contemplated. Go, go, Nim!
Congrats and Thanks Nim team. I’ve been tinkering with Nim to build a really efficient pubsub server. Something that can take heavy concurrent connections. Now I can actually build with confidence.
and also https://github.com/status-im/nimbus which is a lightweight Ethereum 1.0 & 2.0 client in development. If Ethereum 2.0 is really able to scale like they plan, a project like nimbus could really enable widespread use of cryptocurrency on phones.
But why do they have to use camelCase? I don't know why it bothers me so, but I see that in a language or a repo and immediately and irrationally despise it.
Not really, when you want to import things from C you simply name them what you like and then you can call them in a case-insensitive fashion. When writing code that should be imported into C code it will either have its name exactly as typed, or you can specify a name for it yourself.
More of a personal preference, but to me, typing all these underscores all the time would probably give me carpal tunnel syndrome within just a few years.
As other have mentioned Nim is style insensitive. This might sound odd at first, but it allows you to use snake_case in your code even though the standard library is camelCase. It also allows me to use your snake_case library in my camelCase code without ending up in mixed_Case hell like you often end up in Python.
I noticed that Araq's personal post about v1.0 mentioned a powerful macro system as a top priority. I wonder if Nim's macro system is now expressive enough that a front-end web framework like Svelte [1] could be implemented using Nim macros, as opposed to Svelte's HTML template language and custom compiler. COuld be useful for developing isomorphic web apps with something lighter than Node on the server side.
Last year I wrote a book on building applications with Nim, now I think it's the time for all of the people waited for 1.0 to pick it up https://xmonader.github.io/nimdays/
I love seeing new languages that do interesting things. I wish I could see what languages everyone will be using in 100 years. Or at least I'm curious what we'd see with 100 years of development towards solving today's problems (and without AI because that's not what this particular fantasy of mine is about).
It's one of my favorite things to fantasize about when I run into another python bug or a write a tedious unit test that feels like I should be able to let my tools deal with for me. Super-future-dependent-haskell's type system with python's ergonomics, and fantasy-future-python's gradual typing to go fast and loose when I feel like it, and C's ability to specify exactly what I want when I need to with rust's ability to keep me from shooting myself in the foot while doing so, and zig's ability to do dead-simple compile time programming, and super-future-idris/coq's ability to write ergonomic proofs in place of many tests, and so on. Or even the futuristic fantasy one-FFI-to-rule-them-all, so I can mix and match pieces super smoothly.
Every time I see an interesting new language catching on, I can't help but engage in optimistic flights of fancy about the future of programming.
Julia discourages Linux distros to package it. They include modified and unmodified versions of all libraries they depend on within the Julia source repository.
I am not quite sure how they are planning to grow within the ecosystem that matters most for many developers.
307 comments
[ 2.7 ms ] story [ 264 ms ] thread> Furthermore, we don't really know yet how to leverage a macro system in order to give us extensibility on the type system level, so Nim's core needed generics and constraints for generics.
I'm curious to dig into Nim and it's type system. I'm not familiar with Pascal style typing, I wonder how it compares with Rusts type system?
Worth noting that C++ is going the opposite way with concepts. The compiler still won't enforce that `template<typename T> void foo(T t) { t++; }` needs a `requires Incrementable T` (like Rust would require with trait bounds). But if `foo` does use the concept `template<Incrementable T>`, then a call like `foo(S{})` will raise an error at the callsite, not at the `t++` line.
EDIT: actually, Go's generics proposal probably doesn't have that issue, since the contracts are restricted enough to derive type declarations from them.
Looking into it now, Nim apparently has experimental support for the same feature: https://nim-lang.org/docs/manual_experimental.html#concepts
Just wanted to add that my initial memory was apparently of the earlier proposal for generics in Go, as reflected here: https://dev.to/deanveloper/go-2-draft-generics-3333 (in this earlier proposal, contracts simply specify code that is expected to compile, in such a way that it would be difficult/impossible to derive types for symbols introduced by the contract).
I guess the golang people figured out why that was not an optimal system and changed it ... wonder if the same will be true of Nim.
I've been following (and evangelizing) Nim for a while, this will make it easier to do so.
If your filesystem suddenly starts returning the contents of notepad.exe when asked for user32.dll and vice versa, is that not filesystem corruption?
If an admin user object can suddenly start pointing to the guest user object and still be considered "memory safe", that doesn't seem like a very safe definition of safety.
It's certainly a weaker definition of memory safety than you and I, and I would guess most people, would have in mind. So in that sense, I think the author is wrong to call it memory safety.
You're totally correct that a logic bug in this category could cause a credentials pointer to point to a different or higher set of credentials, and that is an implementation risk.
(i'm not convinced that's a useful thing myself)
Nitpick: UB doesn't come from reading random garbage, it's quite the opposite: UB could result in reading random garbage, but it could also result in many worse things.
I don't get why some languages adopt the 'PascalCase for types' approach (which is fine), but then a bunch of the built-in types such as 'string', 'set', 'int64', etc. are lowercase... it's annoyingly inconsistent.
[1] https://nim-lang.org/docs/nep1.html#introduction-naming-conv...
In C++ it can matter for correctness because primitives are uninitialized by default. But other types might be too and the standard library uses under_scores for things that are initialized on construction, so it's not a great example of this distinction.
Why do you care in other languages? In Rust for example I'm a little fuzzy on why I care if something is considered a primitive.
However I'm not super familiar with Rust, so I couldn't speak to that why.
I've had Nim installed on my laptop for a long time and I've always enjoyed tinkering around with it over the years. Maybe now it's time to find a bigger project to try it out on.
This is a tiny thing, but just to highlight something unique I like about Nim, using `func` to declare pure functions (and `proc` for others) has been a small, but really nice quality of life improvement. It's something I've been wanting in other languages since Nim added it.
It seems like the 2010s have been a pretty amazing time for new programming languages. The ones that I can think of that I've at least tried are Rust, Go, Nim, Crystal, Zig, Pony, Fennel, Janet, and Carp (I know, some of these are pre-2010, but I think they've all either 1.0'd or had a first public release post-2010), and every single one has made me really excited about some aspect of it. I hope this experimentation continues into the 2020s!
On the list of languages I only know the first few up to Zig, will need to check out the others. There is also one noticeable missing and that is Elixir.
[1] https://crystal-lang.org/2019/09/23/crystal-0.31.0-released....
Not to prevent you from trying it, of course - to each and everyone their own...
I use both Python and Elixir. Python for web scraping and Elixir for my side project website.
I can see if people want to move web dev from Python to Elixir but yeah not entirely bailing out for Elixir. BEAM VM in general is terrible for numerical stuff. Elixir is pretty niche, it solve one thing concurrency problems. Python is a much more general language.
And I'm sure Fortran was cool back in the day, I'm sure it's due a comeback any day now.
The combined result may not be nearly as principled as the Haskell way of doing controlled mutability with double-checking from the compiler that you aren't breaking your own rules, but it's a nice pragmatic compromise that's easy to understand without having to rewire the way you think about programming.
[0]: https://dlang.org/spec/function.html#pure-functions
I'm using a weak-CPU machine these days, and it turns out that everything is slow and cpu-hungry except native code and Lua. Lua blows even JS out. Specifically, my scripts seem to be done faster than Node.js spins up.
https://vlang.io/
They don’t break the mould quite like the ones you’ve mentioned, but they’re still a big improvement for day to day stuff!
FORTRAN has this distinction since the beginning.
(Modern Fortran does have a pure keyword meaning "no side effects", but that wasn't there "since the beginning".)
[EDITED to add:] I checked in the Fortran 77 standard. The difference between a FUNCTION and a SUBROUTINE is just that the former returns a value and the latter doesn't; in the code for a FUNCTION you are absolutely allowed to do I/O, modify global variables, etc. Functions (and subroutines) can change the values of the variables passed to them. There are also things called "statement functions" which have to have single-line definitions along the lines of "square(x) = x*x"; these don't have to be pure either because the defining expression may call functions that have side-effects.
Despite working in Fortran every day, I never knew about statement functions before. Thanks.
What's the limit used by Nim in its definition of a “pure function”? Is function that allocate memory considered a impure one? (technically it is, but it really reduces the usefulness of such keyword if it's too restrictive, that why Rust don't have it for instance).
Edit: Yes, those are very valid and reasonable questions. Clarifying that it's not meant as trolling is also valid and reasonable, because writing is easily misunderstood in exactly that way - which is the reason smileys were invented. (And, to be clear, I'm not accusing anyone of missing smileys or of trolling. I am trying to express my agreement with both parent and grandparent.)
(I'm not accusing the granparent post)
So, in order to avoid bias on the reader part, I preferred to explicitly tell it was not trolling.
I used it where I would use python - backend of web apps. But now instead running a cluster of servers I can just run 1 because nim is fast.
I also used to write frontend in CoffeeScript, but switched to nim because I can share code between backend and frontend. I don't have typos. I don't inherit any JS or OOP legacy like TypeScript.
This was sort of my use-case and experience as well. I also find it can do what I needed JavaScript-based CLI tools to do with less dependencies/ecosystem bloat, and the resulting code is a lot nicer to work with. People have told me that's because I was using JS wrong, but I felt like Nim was such a huge step up for my use cases.
It's also just a pleasure to learn something new occasionally.
You could also describe it as being competitive with Rust, but with more compromises for the sake of developer ergonomics. Garbage collection, for example.
For my part, I'm finding it attractive as a potential Java-killer. It isn't write-once-run-everywhere, but, now that x86 and Linux have eaten the world, that's not quite such a compelling feature anymore. And Nim smooths things over a bit by making cross compiling dead easy. In return, I get better type safety, better performance, a much better C FFI, and less verbose, easier-to-understand code.
I think there's not much merit in discussing "C-flavored Python" as a description of nim, as that description seems just wrong.
Aside from significant whitespace, I don't find that many similarities with Python syntax.
Describing Nim as non-functional is misleading. Nim does have functional constructs and is a mixed-paradigm language involving both procedural and functional elements, just like Python.
"Firmly statically typed" is misleading. It's actually strongly-typed with great capabilities around type-inference so that, at times, you start to forget that it's typed in the first place and gives you a similar feel to a dynamically-typed language like Python.
Nim can run with garbage collection disabled. As a matter of fact, I seem to recall that the authors postulated that as a basic requirement that the language should be able to run in a low-level systems programming mode with garbage collection disabled (where it would be able to compete with Rust), and in a more high-level mode where it would rather compete on developer ergonomics/productivity.
I find Java-killer a potentially misleading analogy. I do think that it captures the kind of platform-independence that matters nowadays. And that is no longer Intel vs Sparc and Windows versus Linux, but rather the native ecosystem versus the JavaScript ecosystem.
Nims GC is able to either be controlled in terms of when and how long it runs, and it can be completely disabled in favour of manual memory management. In fact people have gotten it to run on really low-powered microcontrollers like the Attiny85, as well of course as various Arduino boards. The benefit of Nim in these systems is that since it compiles and has such a rich macro system your are able to write abstractions that the compiler will turn into highly efficient code. So you can still write business logic level readable and maintainable code, while the compiler spits out super-optimised versions. This of course requires you to first write these macros, but often times a little goes a long way.
Well: Nim is similar to Python in many respects, it's just not "C-flavored Python".
It has significant whitespace like Python. But since it has a lot of language constructs that are different from Python, it's a bit tedious to try to otherwise compare the syntax a great deal, and it has many elements to its syntax that are quite unique.
Saying that Nim is statically typed whereas Python is dynamically typed is exactly a feature that's a slightly unfortunate pick for trying to contrast the two, because type inference is trying to bridge the gap and give you something that's a bit in-between in terms of how it feels to the programmer.
Nim is similar to Python in that (a) It's very cleaned-up and allows you to do a lot of stuff and complex stuff with little code, without sacrificing clarity and readability. (b) It puts the programmer in a cognitive mode where he can think first and foremost about the problem at hand and not have to concentrate on the programming language so much. (c) It gently guides the programmer towards good programming practice without being patronizing. (d) It has a fast learning curve,...
Essentially all the things that make Python great are found here as well. But nim gets there on its own, not by replicating elements found in Python a lot. It's very unique in a way that makes nim a great choice of language in situations where Python isn't (like systems programming or writing code for the Browser ecosystem).
</subjective>
It seems like you're hyper-focused on a rather skewed interpretation of my first sentence, to the point that you largely ignore the second sentence. Or at least you seem to ignore everything after the word "but", which, given what the word "but" is often used for, is a rhetorical move that has a way of enabling interpretations that tend to be close to the opposite of whatever was originally intended.
Parent poster has it right. I picked that initial comparison to Python by way of introducing one of the more popular summarizations of Nim, so that I could say why I don't think it's a good summary. If I didn't put it emphatically enough to satisfy you, I apologize. I apparently don't have anywhere near as strong of feelings on the subject; Nim's just a language I like to program in sometimes.
Probably because most people are more familiar with Python than Ada and Modula (combined) ;)
I guess it depends on your previous experience. Some people will only see Python, others might think of Nim and its syntax as "Pascal for 21st century" (fun fact: the original Nim compiler was written in Pascal).
But, being a JVM language, it's still stuck with all of the Java shortcomings that I had listed before: Achieving a decent level of type safety is impossible, the FFI is still a pain to use, and you've got to go through contortions to get really good numeric performance. Because all of those problems are characteristics of the JVM's run-time environment, not the language you're using to target it.
The only KVM in town is Android.
I mean, it actually is C, since the code is transpiled to C.
Or consider: Every native-compiled language ends up as machine code, which is equivalent to assembly language, but for most (perhaps all) it would be grossly misleading to say "as fast as assembler".
Your comparison to machine code (or human readable assembly code) is less useful in that such a statement means very little until one knows how said machine code is being produced (e.g., manually, from a IR, etc.).
That a language is compiled to C does not mean that its compiler is going to be able to produce a C program that's as good as a that well-written C equivalent. (A relatively obvious example would be a compiler that introduces a heavy runtime, and doesn't give the C compiler enough information for it to get rid of the runtime)
It's the same with assembly code: that a compiler produces assembly does not mean the resulting program is fast.
That’s your interpretation, which is fine, but the objective meaning stands. Even the idea of “well-written C” is, in my experience, fairly subjective amongst C programmers.
Where do you see me claiming otherwise?
> At the simplest level, the compiled code could add a bunch of unnecessary function calls and pointers and other forms of indirection that wouldn't be present in hand-written C.
Again, why are you telling me this? Please quote where I claimed otherwise.
> But for a more extreme example, you could also compile an interpreter or VM to C, and it would still be much slower than the equivalent hand-written C code.
The more that I read your response, the more that it seems that you’re debating yourself, because I’m not sure why you’re telling me this. You started your response by telling me that I’m “missing the point” when, in reality, you seem to have not even read my point. My main point was the following:
> If the code from which the resulting machine code is compiled is C, then it’s objectively “as fast as C” […] your resulting program will perform as fast as a C compiler [worth its salt] can get you.
This is true. I made no claims re efficiency; “as fast as C” and “as fast as efficient hand-written C” aren’t interchangeable claims. Forgive me for not assuming efficiency, because I’ve seen a good amount of inefficient hand-written C code in my years.
> This is why "as fast as C" typically refers to normal, hand-written C code—even though there is no formal definition for what "normal C" looks like, it's still a useful description.
Says who though? I’m professionally experienced in C, and as is very clear by this discussion, it’s down to individual interpretations.
That some particular C program exists that is at least as slow as a program in some other language is always true, trivially, and so is not a good interpretation of "as fast as C" regardless of its objectivity.
Being as fast as C is not about using C as an intermediate language but having data structures and control flow that resemble what C compiler have been optimized for.
Case in point, Haskell GHC is capable of outputting C code but the algorithm will not get C performance (or Haskell performance without this intermediate C representation).
But that doesn't at all follow from compiling to C. I gave one example above; here's another. Perhaps my programming language has arbitrary-length integers and the C code it produces for a simple loop looks something like this:
Corresponding code in "normal" C would use machine integers and the compiler might well be able to understand the loop well enough to eliminate it altogether. Code like the above would run much, much slower, despite being technically in C.(A neat tool in one's toolbox, of course. But just transpiling to C does not get one as fast as C.)
I've been trying to find out if I can take the generated C code that nim produces and, for example, compile it on some exotic architecture (say an ancient solaris/sparc system or some aix/power thing, or some mips microcontroller with linux) however I can't find any examples of people doing this...
Is it possible? Or should I abandon hope and continue writing C for these platforms? :}
Give it a try :)
[0]https://stackoverflow.com/questions/29956898/how-do-i-get-th...
And for CPUs - https://github.com/nim-lang/csources/blob/master/build.sh#L1...
For a side project of mine, I recently re-wrote the same code in a dozen or so languages. The application reads input data from text file and does a bunch of conversions to integers and floats (atoi and atof). It then runs through an algorithm that does calculations and identifies proper actions. Finally, it writes the output data as formatted text file. Regardless of implementation, it runs quick. Sorry I can't provide more details on nature of the code (it has IP that belongs to another person).
Here are the top 10 best execution times (all run on same hardware). Times obtained by 'time' utility (e.g., "time ./run.sh"). Some of these were run on Ubuntu 16.04 and a few were run on FreeBSD 11.2. Where the compiler has optimization flags, I used it.
1. C++ 0.04 (gcc version 5.4.0) 2. Rust 0.11 (version 1.37.0) 3. Go 0.13 (version 1.12.7) 4. D 0.16 (tied with Pascal) (DMD64 D Compiler v2.073.2-devel) 5. Pascal 0.16 (tied with D) (fpc 3.0.2) 6. C# 0.25 (mono 4.8.1) 7. Nim 0.50 (1.0.0) 8. Kotlin 0.81 (Kotlin version 1.3.50-release-112, JRE 1.8.0_222) 9. Java 0.95 (openjdk version "1.8.0_131") 10. Scala 1.79 (version 2.12.2, running on 1.8 openjdk)
https://github.com/danielecook/seq-collection
And the second:
https://github.com/danielecook/tut
The second one has a really useful utility called "stack" that you can use to concatenate datasets where one might lack some columns or the columns come in a different order. It glues it all together and has an option to include the filename. It's useful for data analysis.
Both of these lack 'polish' at this point but a few of the subcommands work quite well.
Also, the organization has no desire to invest in training or experimenting. The project is funded by the "business" and they want to see a business result in return for their money ... so you basically you sneak in a bit of time as you try/test something new. Nim won out by somehow getting a team with python expertise learn and deploy their product fast enough.
Nim had the following appeal for us:
- Ethereum research is done in Python, we actually started our code with a tool called py2nim to convert a 50k lines Python codebase to Nim in less than a month (and remove cruft for 3 months but that's another story).
- Nim allows us to use a single language for research and production: the Python syntax, and the fast compilation speed are very helpful. In particular researchers found the Nim codebase easy to debug as the overhead vs the Python spec was quite low (and the Python spec is using types with mypy)
- Nim has a easy C FFI and is one of the rare languages that can directly use C++ libraries, including header-only template heavy libraries.
- Nim allows tight control over memory allocation, stack vs heap objects, has support for Android and iOS and very low-memory devices as well.
- Nim also can be very high-level
- Nim is as fast as C and can resort to inline C, inline C++ or inline assembly when needed. (inline javascript or Objective C are possible as well)
- You can produce WASM code via clang, emscripten, binaryen, there is even a Nes emulator demo from 2015 running in Nim compiled to WASM here: https://hookrace.net/nimes/
- Nim has a strong type-system, including generics and type-level integers, boolean and enums.
- Nim has probably the best compile-time capabilities of all languages. I'm writing a deep-learning compiler in Nim macros. Someone wrote a Cuda code generator in Nim macros, and the code generation is extremely nice to write a VM, an emulator or any kind of assemblers as you don't need to use an intermediate step to generate your opcode tables or generate your functions from that table.
Now on a personal note, I use Nim to write a deep learning framework similar to PyTorch or Tensorflow.
I think it's the best language to solve the 2-language problem, i.e. write research in Python, R or Matlab and production in C, C++ or Fortran.
The operator overloading or even operator creation is very useful. The macros allow me to have a slicing syntax similar to Numpy, something impossible in C++. Compilation speed is very nice as a developer, I don't know how people deal with waiting for C++ CI.
I reimplemented a matrix multiplication with performance similar to handwritten assembly BLAS from OpenBLAS and MKL in pure Nim so I'm not worried about performance as well.
Now I'm onto refactoring the backend with a proper compiler (similar to Halide but since it will be macro-based, there won't be the 2-stage compilation issue)
(C++ doesn't have a ':' operator, you'll need to use some other symbol.)
For me, Julia completely addresses the 2 language problem. In practice I think it now simply needs a stronger ecosystem, better static analysis, and bug fixes, but I am very happy with the language design.
Their goal is to get Eth2.0 (and 1.0) running on very low resource environments such as raspberry pi and turnstiles.
What this should tell you is that:
* Nim is close to the metal enough to run with high performance and low resources.
* In a cutting edge research arena, where the math is still being decided, Nim allows such rapid prototyping that the team is on par with much larger teams in much more established languages.
* All the tools required to build an ethereum platform are present and running, such as security, encryption, and networking such as devp2p. Here's their eth library docs for some of the contributions: https://nimbus-libs.status.im/lib/nim-eth/
Status is pretty dedicated to open source, and whilst they're the biggest patreon donor, the Nim team is completely autonomous.
The cons are its lack of enterprise backing, its smaller community and its syntax, if you don't like either Pascal or Python.
You can also entirely disable the GC or replace implementation.
Nim can run without OS and on microcontrollers.
- "Transpiled" to C, with some options regarding runtime library, which means you can target any uController out there
- Good metaprogramming support
- Static and _strong_ typing
- Consequently, precise type aware function dispatch
- Type inference
- Good generics
Also, more stuff like covariants and contravariants and... maybe you just have a look-see? ;-)
https://nim-lang.org/docs/manual_experimental.html#concepts
https://nim-lang.org/docs/manual.html#generics
but please, dont
Could Nim be used to generate a framework for Xcode and the the same code be used in a Windows C++ or .NET project?
I've been looking for ages for a cross platform solution that can be used to create dynamic or static libraries that isn't C++.
I hope I don't spoil the party by asking: What's the status of GUI bindings?
So all in all I'd say it's pretty decent, but I still have plans for my own toolkit that would solve my personal gripes with creating cross platform UIs.
https://github.com/dariolah/niup
https://github.com/dariolah/nim-iup-examples
[0] https://github.com/trustable-code/NiGui
It was published in 2017 but we've ensured Nim is compatible with it (all book examples are in Nim's test suite), so apart from some minor deprecation warnings all examples should continue to work.
Grab a copy here: https://manning.com/books/nim-in-action?a_aid=niminaction&a_...
The version of the book you bought (and which is still on sale) is compatible with Nim v1 and it is still relevant, no need for another version anytime soon.
version 1.0, stability, RFC process -- all are signs of maturing language and the ecosystem.
Here is a curated list of frameworks for Nim
https://github.com/VPashkov/awesome-nim
For me, personally, the interest, is its javascript-as-target capabilities.
and also https://github.com/status-im/nimbus which is a lightweight Ethereum 1.0 & 2.0 client in development. If Ethereum 2.0 is really able to scale like they plan, a project like nimbus could really enable widespread use of cryptocurrency on phones.
Is it just me?
Sidenote: not a Nim user, but this seems like it could get in the way of interoperability with C (and most other languages)?
[1]: https://svelte.dev/
[1]: https://svelte.dev/blog/virtual-dom-is-pure-overhead
Last year I wrote a book on building applications with Nim, now I think it's the time for all of the people waited for 1.0 to pick it up https://xmonader.github.io/nimdays/
It's one of my favorite things to fantasize about when I run into another python bug or a write a tedious unit test that feels like I should be able to let my tools deal with for me. Super-future-dependent-haskell's type system with python's ergonomics, and fantasy-future-python's gradual typing to go fast and loose when I feel like it, and C's ability to specify exactly what I want when I need to with rust's ability to keep me from shooting myself in the foot while doing so, and zig's ability to do dead-simple compile time programming, and super-future-idris/coq's ability to write ergonomic proofs in place of many tests, and so on. Or even the futuristic fantasy one-FFI-to-rule-them-all, so I can mix and match pieces super smoothly.
Every time I see an interesting new language catching on, I can't help but engage in optimistic flights of fancy about the future of programming.
In fact, I almost suspect you are hinting in that direction yourself ;)
I am not quite sure how they are planning to grow within the ecosystem that matters most for many developers.
Where does nim sit in regards to the future of machine learning? Can we expect clones of pytorch/tensorflow? Is it a suitable language for this?
https://github.com/fragcolor-xyz/nimtorch