Re: Any possibility of a Rust backend for Nim?
The reason you're "hearing so much about Rust" is that they are less shy about hype marketing [(ex)](http://forum.nim-lang.org///www.redox-os.org/fr/news/rust-is-softwares-salvation-17/) (and, ironically, they go irate when they come across evangelists for a competing language [(ex)](http://forum.nim-lang.org///forum.nim-lang.org/t/2687)). Yes, many people are very religious about their choice of programming language - including myself. ;) I don't see how Nim would benefit from a Rust _backend_. The C backend serves almost the entirely of Nim's purpose. From what I understand, the C++ backend makes it a bit easier to build wrappers around C++ libraries, but isn't really a necessity. When it comes to good libraries, I'd guesstimate that C probably has about 85% market share, with 14% of good libraries being C++ only (rather than OO wrappers around C), and 1% "other" (with Fortran still being ahead of Rust). IPFS's libp2p being implemented in Go is a strange exception, but they [will eventually write an implementation in C/C++](https://github.com/ipfs/ipfs/issues/164). (One exception is the JS backend, which is categorically different. It still needs a lot of work to reach its potential (with more libraries that work in both in-browser and outside-the-browser contexts, leveraging things like [BrowserFS](https://github.com/jvilk/BrowserFS), etc), and it may not be a good choice for most people anymore if/when [wasm](https://en.wikipedia.org/wiki/WebAssembly) matures.) Back when Rust's Mid-level Intermediate Representation (MIR) [was announced](https://blog.rust-lang.org/2016/04/19/MIR.html), I've inquired on IRC [(log)](http://forum.nim-lang.org///irclogs.nim-lang.org/27-04-2016.html) about the possibility of a unified library ecosystem between Nim and other similar languages - that is a very interesting discussion IMHO, but a very different idea from a "backend".
Re: Any possibility of a Rust backend for Nim?
Hmm, double-posting forum bug - [https://archive.is/H6iJw](https://archive.is/H6iJw) (I self-deleted the dupe.)
Re: Nim Wrapper for ArrayFire
I'm really excited to see this! I'm using Nim for data science and I would love more wrappers and libraries :) There's also: [https://github.com/stavenko/nim-glm](https://github.com/stavenko/nim-glm) [https://github.com/unicredit/linear-algebra](https://github.com/unicredit/linear-algebra) if looking for other libraries with similar aims. I've used andreaferreti's linear-algebra library for a project, and it's been great. The one thing I really would like is higher-dimensional matrices (which it looks like this provides). Awesome!
Re: Nim concurrency
New location of the asyncdispatch documentation: [http://nim-lang.org/docs/asyncdispatch.html](http://forum.nim-lang.org///nim-lang.org/docs/asyncdispatch.html)
Re: Nim in Action is 50% off over the weekend
How much is it then?
Re: Nim Wrapper for ArrayFire
Hi - I think the reason for Julia being so fast in the matmul benchmark is that it uses many high performance c/c++ libraries in the background, I am not sure what they use for matrices but the julia result is probably just what you would get with c/c++ and blas or atlas. My guess is that with the CPU backend the results for ArrayFire would be very similar - I did not do any optimization yet but I would assume that the Nim wrapper does not slow down things too much - the results would be quite similar to the Julia results. For me Julia is a good example how clever integration of existing libraries can make a language interesting for scientific applications. After ArrayFire I am planning to make Nim wrapper for some more libraries - c2nim is a very fine tool although the documentation for it and Nim in general has the density of a neutron star ;) Best Regards
Nim in Action is 50% off over the weekend
I know there are still people hunting for a discount code so I figured it would be a good idea to create a new thread for this. Manning is celebrating the new year with a 50% off discount (`dotd123016`) on all their books over this weekend: [https://manning.com/dotd](https://manning.com/dotd). So grab [Nim in Action](https://manning.com/books/nim-in-action?a_aid=niminaction&a_bid=78a27e81) while you can :)
Re: Parallel loop iterator
I wouldn't use it. I would maybe play with it, try how it works and when it fails, and then stay tuned how that thing evolves in the future. I can even imagine that it could disapper to shift focus on more important features, or change the way how parallel loops work entirely (personal opinion).
Re: Type inference side effects
I am sorry to say this, but your comment seems a lot to be a troll post. To me you just want as many people as possible in a discussion with the least amount of effort, and then lean back and enjoy. Every programming language has type inference except dynamically typed languages and Java. And even that one has a very weak form of type inference with the diamond operator. I honestly doubt that you really don't know the benefits of type inference.
Re: Any possibility of a Rust backend for Nim?
As far as I know, you can always disable the safety belt of Rust when you need to. It is already required to interface C from rust. I personally am not the fan of the feature that Nim can compile to any language in the world. I think that a lot of work to implement, and even more work to maintain. The C backend is a very common way to implement a new language, and reusing a lot of knowledge about the language C. C++ backend is just because it is easy to support. EcmaScript is important, because WebAssembly is simply not there yet, and it could take a while before it really is suitable. All other backends are in my opinion a distraction from getting the important stuff fixed to get Nim to a stable version 1. Every backend that is not one of the mentioned backends should get lowest priority.
Re: How to check the backend at compile time?
`defined(cpp)` C++ target `defined(objc)` Objective C target `defined(js)` JavaScript target I don't think there is a define for the "C target", but you can use `not defined(cpp) and not defined(objc) and not defined(js)` for this.
Re: How to check the backend at compile time?
[You can do this](https://github.com/nim-lang/Nim/blob/5f685bb0e6b2d68b9796e6a7d29469ce3f3b38ec/lib/system/atomics.nim#L13): const someGcc = defined(gcc) or defined(llvm_gcc) or defined(clang)
Re: Any possibility of a Rust backend for Nim?
What is the point? You can't use the tools that rust provides to handle memory with safety, arguably the only reason to use rust over nim.
How to check the backend at compile time?
Is there some way to check what backend was used at compile time? I don't mean a specific feature of the backend (some can be found in system module), but e.g. the name of backend as string.
Any possibility of a Rust backend for Nim?
I have a feeling it is actually not possible because of the borrowing stuff somehow. But I keep hearing so much about Rust.. it seems so many C or C++ programmers are becoming Rust evangelicals. It also seems like they are still either deliberately making it difficult to handle normal tasks in Rust or they just don't know how to make a clean syntax or streamlined system. So I have finally accepted that I will have to learn Rust eventually. But just in case there could be hope down the line I am asking this question. Thanks.
Re: lib\wrappers\\pdcurses.nim(43, 10) error : cannot open windows
* nimble install ncurses e:\work\nim> nim c curses01.nim Hint: used config file 'd:\nim0150\config\nim.cfg'[Conf] Hint: system [Processing] Hint: curses01 [Processing] Hint: ncurses [Processing] CC: curses02 CC: stdlib_system CC: ncurses_nucrses Hint: [Link] Hint: operation successful(10823 lines compiled; 5.761 sec total; 16.004Mib; Debug Build)[SuccessX]
Re: Type inference side effects
application of floor As our country natural forest commerce stands the policy such as cut down policy carry out, and the control that country of main lumber exit exports to log, industry of floor of our country wood will be faced with raw material the condition that in short supply, cost rises, still must face http://compositematerialsupplier.com/wpc-product/1999.html](http://forum.nim-lang.org///compositematerialsupplier.com/wpc-product/1999.html) ">anti-corrosive wood composite floor russia wooden floor to export trade technology camp of the country at the same time, strengthen a technology innovation, carrying high yield to taste additional cost will be seek of enterprise of floor of our country wood of long-term development surely the road of classics. Lv Bin thinks, from 2015 the case of patent application of floor of our country wood looks, technical innovation already got the attention of entire industry, manufacturing company already made the principal part that the technology innovates, this progresses the http://compositematerialsupplier.com/eco-product/5349.html](http://forum.nim-lang.org///compositematerialsupplier.com/eco-product/5349.html) ">purchase gothic stockade wood fence panels technology that is helpful for whole industry, promote industry of floor of our country wood the significant position in industry of floor of alive bound wood then. Nearly 60 people joined company of record of delegate of exporter of adviser of lawyer of forest products association, whole nation, experience the conference.http://compositematerialsupplier.com](http://forum.nim-lang.org///compositematerialsupplier.com) ">composite material supplier Association of trade of Linyi city timber on invitation by Sun Yubin of chairman Song Gang, vice-chairman, vice-chairman team of Gao Enjiang rate attended the meeting. The conference is chaired by secretary-general of peak of stone of association of industry of Chinese forest products.
Re: Incredible Nim vs lame rust censorship
In general, if you want to constructively engage in language advocacy, one of the best ways is to do something neat in your favorite language. It doesn't have to be a big project, just something that makes other people think: "hey, this is cool". It's also something that people will read; generic putdowns of other languages is something that will be skipped over (at least that's what I do) and strong language makes me even less likely to take an argument seriously (if you have a good point to make, it can stand on its own without being derogatory).
Re: Incredible Nim vs lame rust censorship
Sometimes profanity is a good way to accentuate your arguments. I can appreciate that. Your post doesn't use much of it, but it's still not something that I can reasonably allow on this forum. With this in mind, I will politely ask you to remove the profanity. All you need to do is remove the two offending words: "retarded" and "sucking". I believe that removing these words or replacing them with something less offensive won't change the meaning of your message. I am of course willing to hear any arguments for why you (or anyone else) thinks these words should remain. Unlike the Reddit community I despise shadow bans and prefer not to remove posts when possible, that said I must admit that being able to discuss issues such as this with the offender is a luxury that doesn't scale well. I'm afraid that if you don't comply, I will perform this edit myself. It's nice to see that @libman has already engaged you in a discussion. I would like to continue that. As a side note, it would be helpful if you could also edit the formatting of your post. Use the `>` to create quoted text, this will word wrap and be easier to read.
Re: Incredible Nim vs lame rust censorship
This is a borderline post and I decided to not moderate it this time. But the next time please be friendlier, I'm sure you can express your dislikes more politely.
Re: lib\wrappers\\pdcurses.nim(43, 10) error : cannot open windows
* i delete lib/wrappers/windows.nim * nimble install oldwinapi ( installed into C:/Users/ $USERNAME /.nimble/pkgs/oldwinapi-1.0.0 ) but the error present just the same. e:\work\nim> nim c curses01.nim Hint: used config file 'd:\nim0150\config\nim.cfg'[Conf] Hint: system [Processing] Hint: curses01 [Processing] Hint: pdcurses [Processing] Hint: windows [Processing] lib\wrappers\pdcurses.nim(565, 66) Error : undeclared indentifier: 'MOUSE_STATUS'
Re: Incredible Nim vs lame rust censorship
> I cannot corroborate Nim benchmarking faster than Rust I didn't expect that either, hence the enthusiasm :) The results were obtained on Linux, ARM and ARM64 (the new platform I'd mentioned), benchmarking the latest rust nightly vs latest Nim, gcc 4.9/5/6 and clang 3.6 (armv7). Probably more proof rust is basically an x86_64 language. Personally, to give rust another chance, 3 things would have to happen: * rust gets a dedicated gcc backend * already compiled binary crates can be reused between the 6-week release periods (instead lots of effort has been wasted on crap like that alternative bootstrap system) * rustbuild gets deleted in February :) (instead of the Makefiles bootstrap) The last point definitely means it's goodbye rust.
Re: Nim Wrapper for ArrayFire
Excellent! :D I wonder how this would affect Nim's standing in the [kostya/benchmarks](https://github.com/kostya/benchmarks) (which were [just recently mentioned](http://forum.nim-lang.org///forum.nim-lang.org/t/2687) here), namely [matrix multiplication](https://github.com/kostya/benchmarks/tree/master/matmul)...
Re: Parallel loop iterator
As [say the docs](http://forum.nim-lang.org///nim-lang.org/docs/system.html#||.i,S,T,string): > "Note that the compiler maps that to the `#pragma omp parallel for` construct > of OpenMP **and as such isn't aware of the parallelism in your code! Be > careful! Later versions of || will get proper support by Nim's code generator > and GC.**" It's inevitable for a very young programming language to have placeholders for features before they are fully baked. (And Nim indeed is still "a very young programming language" in many ways, given its breadth and how few programmers had been involved in the beginning, despite the chronological starting point being 2005.) Maybe the docs just need more emphasis: **_"HERE BE DRAGONS"_** ;)
Re: Incredible Nim vs lame rust censorship
Naughty Naughty... ;) * * * A few random thoughts: * I do not condone being rude on other languages' forums, but I do sympathize with the anti-CoC sentiment. The Nim community deserves major kudos for tolerating me and my libertarian ways. ;) * Take snapshots of all your public message forum comments (ex. [archive.is](https://archive.is/oycSD), [archive.org](http://forum.nim-lang.org///web.archive.org/web/*/http://forum.nim-lang.org/t/2687), [peeep.us](http://forum.nim-lang.org///www.peeep.us/de1833c9)) to preserve evidence of censorship. Don't post in walled gardens where those archivers cannot access. * I **cannot corroborate Nim benchmarking faster than Rust** \- please post details (hardware, versions, OS, etc). Also note that Nim would score _a lot_ better with the right scientific computation library wrappers (which is how some languages, especially Julia and even NumPy, beat it at matrix multiplication). But I think Nim's biggest "killer app" opportunities would best correlate with high-level Web framework / network server performance (ex. [TechEmpower](https://www.techempower.com/benchmarks/), [nanoant](https://github.com/nanoant/WebFrameworkBenchmark)) rather than number crunching, and if anyone is expending effort on performance optimization then that should be the first priority. * IMHO, Nim's top selling point is NOT being the fastest language (ex. C) or the most productive language (ex. Python, Ruby). I think **Nim's top selling point is offering the longest bridge in the middle, the most performance per productivity**. Rust may benchmark _a bit_ closer to C/C++, but its syntax verbosity comes _much_ closer to C/C++ as well. This is like paying twice as much in purchase and fuel costs for a car that gets 10% better acceleration, which you almost never notice because of traffic congestion anyway. * The performance / productivity dichotomy is the most prominent trade-off, but there are of course other virtues people look for in a programming language. Businesses like what I call "programmer interchangeability" — which is something that most popular languages (ex. Java, C#) are good at, and Golang seems to take to the next level — while Nim, IMHO to its credit, seems to largely disregard. And some programmers, especially in academia, value some strange virtues that I just can't seem to relate to (ex. the finer points of Haskell). * And so, due to these differing values, **one cannot always say that language X is universally better than language Y**. What I can say is that Nim's virtues align most closer to my own priorities than any other programming language. A big part of my reasons is that I want my future projects and their dependencies to have a high level of license freedom purity (see [copyfree.org](http://forum.nim-lang.org///copyfree.org/)).
