111–120 of 308 posts
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.
Earlier quoted context omitted.
How good is nim performance with sequencing-data in comparision with other programming languages you used for it before?
Nim performance is really really good. Like, maybe C - 5%. Comparable with stuff like Rust or D... way way faster than Go or anything interpreted.
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)
Is it just me?
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. 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)?
Great! I love this language, so simple and powerful, so fast executables! I hope I don't spoil the party by asking: What's the status of GUI bindings?
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…
[1]: https://svelte.dev/
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. Is it just me?
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/
Congratulations Nim team! :D 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 s…
Fortran has had pure functions and subroutines since well before any of the cool languages. Not that I recommend it in particular.
Earlier quoted context omitted.
> "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 eq…
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.