> 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.
807 karma · joined May 6, 2017
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.
From Wikipedia article of each language:
Rust: First appeared July 7, 2010; 9 years ago
Go: First appeared November 10, 2009; 9 years ago
Nim: First appeared 2008; 11 years ago> It's also slow
It looks to me like you're describing Nim. Static typing, similar syntax to Python, expressive, readable, powerful, fast; and destructors are being worked on as we speak.
You can remap it to <C-l> (L = literal), and then use <C-c> and <C-v> without shift:
inoremap <C-l> <C-v>
imap <C-v> <C-r>+
cmap <C-v> <C-r>+
xmap <C-c> "+yCroatian here.
Croatian authorities usually don't publish median wage, but the mean wage, so that the numbers can look less bad compared to the rest of EU.
When talking about wages, Croatians are usually using monthly net wage (after the taxes). The mean net wage for Zagreb (country capital) is around €1000, and in the rest of the country around €800.
For this net salary of €800, there is around €700 of taxes on the top of it, so the mean monthly brutto/gross salary is around €1500, so that's €18,000 yearly (around $20,000 yearly), where €8000 goes to taxes and €10,000 is the money that is left for you to spend.
Median wages would be lower than that.
How about not reading messages while you're driving? And why do you have to write messages while in traffic? Can't this wait?
This is provably false, as I can witness from my recent experience where Arch has 14 month old, long superseded, version of a package, while other Linux distros (including Manjaro, but also Fedora, Debian, Ubuntu, openSuse, etc.) use the most/more recent version.
----
> AFAIK, Manjaro is behind by like a month? In which case, why even bother with rolling release?
Even if this were true (and it isn't, see the sibling comment), I've seen responses like yours and I don't understand them.
Where would you draw the line when it comes to rolling? You say that one month behind is too long. Is 2 weeks ok? One week? 3 days? 1 day? 12 hours? Why does it even matter?
To answer you from my perspective:
I "bother" with Manjaro because I like the rolling distro philosophy, but I also value stability. If those two weeks of delay will bring me packages which are better tested and more stability overall - I'm all for it.
Oh and I don't even update as soon as an update hits the stable channel, I regularly decide to wait at least a day or two to see if others have any problems with the update.
For other people, who are more impatient (and more adventurous), Manjaro offers two other channels: testing and unstable.
* vs many languages: https://github.com/frol/completely-unscientific-benchmarks
* vs Julia and Python: https://github.com/SimonDanisch/julia-challenge/issues/1
* web frameworks vs many: https://github.com/the-benchmarker/web-frameworks
It has been merged to devel branch: https://github.com/nim-lang/Nim/pull/10729
Just to clarify for the general public (because this is often a source of confusion and misunderstandings): first letters are case-sensitive in Nim, so you can do `var car: Car` (where `car` is a name of the variable, and `Car` is a type).
When it comes to style-insensitivity, I also thought this would be a problem when I discovered Nim, but now—2 years later—there was not even one situation where that would cause a problem. (And if you use different styles of the same name to mean different things in other languages: this will bite you sooner or later)
Nim's standard library is written uniformly in camelCase style, which is what I also accepted for my code (even though I come from snake_cased Python).
So why this even exists? To make easier to use libraries written (in another language, e.g. C) in another style, while keeping the uniform style in your code. Basically, this feature makes it easier to use just one style consistently.
To conclude:
If this is the only (or just a major) thing that keeps you from using Nim: I would suggest you to reconsider and give it a chance.
1. to put Ctrl on CapsLock:
setxkbmap -option caps:ctrl_modifier
xcape -e 'Caps_Lock=Escape'¿Why not both?
I have (on Linux, not on Mac, but it shouldn't matter):
* "caps lock" + key = Ctrl+key
* "caps lock" (release) = Esc
It works like charm and I can definitely recommend it.
Hehe, I thought somebody might ask that.
Yes, I have astigmatism and I wear my glasses when working on a computer.
> I generally use my browser’s reader mode
Reader mode is great but it can't be used on all pages. Also, it cures the symptom, not the cause.
I'm really puzzled why improved readability is not a concern for content creators and it basically boils down (based on the answers I received so far) to: "well, you can zoom in or use reader mode, websites are ok the way they are currently".
This I can understand and support.
----
Intermezzo:
First off, if you're having your browser take your whole screen, "you're doing it wrong", aka here is my tip: Assuming 1920x1080px screen resolution, using 2/3 of its width (~1260px) should be enough for the most of the pages, and the remaining 1/3 of your screen you can use for other stuff you need (IRC, chat window, music player, etc.).
----
Back to the original point:
The reason why this "small width" is happening is because of readability: extra long lines (anything over 100 characters) are hard to read.
But larger font-sizes would please both general-you (people who want larger width) and general-me (people who want larger font-sizes): I would be able to read the text without zooming in, and the same amount of characters per line would now make lines wider.
Yes, my browser allows zoomin in and out at will, but that's not the point.
My question was: why in the large majority of the cases I have to do that, why isn't "zoomed in" (by using larger font-size) by default?
Also, some sites don't change the width when I zoom in, so that basically means I can have either unreadable text or readable poetry (4-5 words per line).
Easily done even with a tiling WM. E.g. I have a keybinding which allows me switching between tiling and floating of a window.
Recently I've been using Nim at my work as a Python+Numpy replacement for a numerical simulation of multi-body contacts.
That's exactly my experience with F# (not surprising, knowing how similar OCaml and F# are), but until I read your comment I didn't know how to explain this joy of reading and writing code in it.
I'm just guessing here, but did you compile Nim in debug mode? (nim c filename.nim)
From my experience, compiling files in release mode (nim c -d:release filename.nim) makes similar tasks run 10-100x faster than Python (usually around 30x for my use cases), and it doesn't require "highly skilled Nim developer" as you mention in your reply.
Please notice that the first letter in Nim is case-sensitive, so `I` != `i`, and you can continue use your conventions.
And before some new comment starts bashing that, I think this is a must so you can differentiate your types, written in PascalCase, from your variables, written in camelCase.
Yes, it means the fastest player on Nim leaderboard, i.e. the one who will on the top of the leaderbord on December 25th.
I guess the fastest program(s) could fall under "the solutions which best showcase the power and capabilities of Nim language".
I feel like this is mentioned (by the people who just glance over Nim) every time there is some discussion about Nim, and IMO it is blown way out of proportion.
In my cca year and half of using Nim, I not even once had a problem with the style insensitivity.
IMO, you (general you) shouldn't use `my_foo` and `myFoo` for different things, regardless if a language allows for it or not.
I've started using Nim couple of months before last year's Advent of Code, after I've been reading about Nim both here and on Reddit.
As a Python user, I was immediately drawn to Nim's elegant syntax, which looked to me like "ok, just copy-paste my Python code, and declare some variables, and voila: 10-100x faster Python!", which is 80% true. The remaining 20% were "this works in Python, why doesn't work in Nim?" questions, which were promptly answered by the great Nim IRC community. I soon realized that those differences are what makes Nim great, and I began to really like the language.
I decided to solve AoC 2017 in both Python and Nim [0] so I could directly compare my solutions. This was a great experience for me, and I've learnt a lot.
In the past year I started using/liking Nim more and more (I have used Nim even at my work (numerical calculations, before done in Numpy)). This year I'm gonna solve AoC solely in Nim.
From my experience, your hunch is right.
If you have any Nim questions, let me know.
But you have stopped working on it when you were 80% done? :)
https://github.com/yglukhov/nimpy
A library which allows you to connect Python and Nim so you could, for example, use Nim (instead of Cython) for speeding up some parts of your code, compile it, and call it from your Python program.
Recently I've been using Nim at my work as a Python+Numpy replacement for a numerical simulation of multi-body contacts. (Just two hours ago I had a small talk at a conference where I showed the results of it)
I'm sure there are lots of opportunities to 'throw in some Nim' wherever you work ;)