We’re incredibly excited to announce the new partnership between Status and Nim. Status is developing an open source mobile DApp browser and messenger for Ethereum.
— https://nim-lang.org/blog/2018/08/07/nim-partners-with-status.html
To bolster research efforts for Nimbus – a sharding client for Ethereum – status.im have partnered with the core team developing the Nim programming language.
— https://our.status.im/status-partners-with-the-team-behind-the-programming-language-nim
This is the biggest announcement in Nim's history so if there are any questions, please feel free to ask them here.
🎉
This is amazing. I love how Nim is finally getting some support financially! Congrats! :D
Any ideas on who the 2 new full time developers will be?
Absolutely fantastic - I can only imagine how validating and exciting this must be after all of the hard work Nim must have required to get where it is today.
Well done, all of you (whoever 'all of you' is :-).
Onwards and upwards!
P.S. Er, um, v1.0?, um, yeah :-).
This news has been picked up by two websites, their write ups are worth a read.
The Register: https://www.theregister.co.uk/2018/08/07/nim_funding_ethereum_cryptocurrency/
EthNews: https://www.ethnews.com/ethereums-status-partners-with-nim
I'm blown away by this!
Silly and hostile comments under Reg text show that popularity is hard.
Yeah, perhaps I'm crazy but the people in those comments don't seem inclined to have a rational discussion about style insensitivity.
Maybe it is time to create well exposed "Common misconceptions" at the nim-lang.org.
I would love to see articles discussing these issues, but at the same time I wonder if it's a good idea to bring more spotlight to style insensitivity.
I would love to see articles discussing these issues, but at the same time, I wonder if it's a good idea to bring more spotlight to style insensitivity.
Sorry, it has been a looong time since I posted here as I do no longer use Nim, but… I always felt a bit "weak" to sell Nim's style insensitivity with the argument that it is nice to pick the style you prefer. I consider the inability to mix styles to be a far greater advantage; consider the following C code:
int Result = 0;
for (int i = 0; i < 100; i++) {
int result = f(x);
if (result < 0) {
result += g(x);
}
Result += result;
}
This is an abridged version of some code I had to work on several years ago. Such a mixture of styles would immediately trigger an error in Nim, as Result and result are the same variable. (This is the same reason why I am a fan of case insensitivity in variable names, like in good old Pascal.) The same would apply if somebody tried to declare two variables myAccum and my_accum in the same context.
When encouraging my colleagues to try Nim, I often found that this argument was quite effective.
Such a mixture of styles would immediately trigger an error in Nim, as Result and result are the same variable.
No. No, it wouldn't. Nim is neither case sensitive nor case insensitive, but rather it goes for Partial Case Insensitivity. Specifically, the first letter of an identifier is case sensitive, while the rest is not. This means that your example is wrong because in Nim:
var Result: int = 0
for i in 0..<100:
var result: int = f(x)
if result < 0: result += g(x)
Result += result
compiles just fine and works as expected (Result != result).
You're technically right about your second example (myAccum == my_accum), but this is very bad coding. It's not Nim's fault if you named different variables so similarly.
This is ultimately a design decision. There are languages that try to babysit the programmer, thinking that they're smarter than them. One big example of this is Rust.
Nim is on the complete opposite of the spectrum. Nim rightly asserts that not every problem should be solved by means of language design. Most things are better relegated to coding practices, IDEs, syntax highlighters, autocompletion, etc. Naming variables is one of these things. If you write code like the above, then no language feature will be enough to protect you from yourself.
No. No, it wouldn't. Nim is neither case sensitive nor case insensitive, but rather it goes for Partial Case Insensitivity. Specifically, the first letter of an identifier is case sensitive, while the rest is not.
Wow. This means that Nim's rules changed after the last time I used it.
You're technically right about your second example (myAccum == my_accum), but this is very bad coding. It's not Nim's fault if you named different variables so similarly.
You're entirely missing my point. I find that refusing to compile this code is one of Nim's greatest strengths, exactly because it helps in preventing variable name clashes.
You're entirely missing my point. I find that refusing to compile this code is one of Nim's greatest strengths, exactly because it helps in preventing variable name clashes.
Huh, I misread your post. I thought you were complaining about Nim not being able to compile the code.