Re: 1.0.0 is here

2019-09-23 Thread aviator
Very cool, congrats to the Nim team!

Re: 1.0.0 is here

2019-09-23 Thread ffred60
great news, thanks.. !!

Re: Tried to learn NIM some feedback

2019-09-23 Thread ffred60
> A third-party threadpool like > [https://github.com/yglukhov/threadpools](https://github.com/yglukhov/threadpools) do you really think that newcomers on Nim will be using a package with not even a simple readme file ? when I find something like that on Github, I don't even look at the code or

Re: Error by duplicated file names (redefinition of 'types'; previous declaration here...)

2019-09-23 Thread leorize
Hmm, @Araq should have already fixed this. Can you test this with Nim 1.0 and raise an issue on github should there still be errors?

Re: 1.0.0 is here

2019-09-23 Thread Hideki
Congratulations! Awesome!

Re: 1.0.0 is here

2019-09-23 Thread rockcavera
Congratulations to all Nim's team.

Re: 1.0.0 is here

2019-09-23 Thread bevo009
Awesome news, thanks Araq & dev team!

Re: 1.0.0 is here

2019-09-23 Thread pianopia
Congratulations to all Nim developers and supporters ! This is Extremely Awesome ! I wrote japanese post about this fantastic release in my joy :) [https://qiita.com/pianopia/items/dcc70f02293e55969e3d](https://qiita.com/pianopia/items/dcc70f02293e55969e3d)

Re: 1.0.0 is here

2019-09-23 Thread amalek
Congratulations to Araq and the team for this epic achievement. Posting in this thread for posterity's sake. ;-)

Re: 1.0.0 is here

2019-09-23 Thread avandy
Thanks

Re: Tried to learn NIM some feedback

2019-09-23 Thread mratsim
> Ha-ha, you caught me. I don't care about best possible performance, it's ok > to be 3-5 times slower than C. But multicore is kinda must nowadays. Nim is as fast as C, this post has plenty of examples from scientific computing, raytracing and multithreaded runtime: [https://forum.nim-lang.org

Re: 1.0.0 is here

2019-09-23 Thread mitai
Congratulations to the devel team!

Re: 1.0.0 is here

2019-09-23 Thread vitreo12
This is fantastic news, congratulations to the dev team. You guys are amazing.

Re: Tried to learn NIM some feedback

2019-09-23 Thread alexeypetrushin
By the way, congratulations with the v1 release! Huge work!

Re: 1.0.0 is here

2019-09-23 Thread lscrd
This is a great day for Nim. Many thanks to the development team.

Re: nim users in San Francisco / bay area?

2019-09-23 Thread cabhishek
Yeah, I am up for it. And I live in SF.

Re: 1.0.0 is here

2019-09-23 Thread cabhishek
Congratulations to all Nim developers on 1.0 release. This is simply amazing.

Re: 1.0.0 is here

2019-09-23 Thread lqdev
Congratulations to all Nim developers! So happy that 1.0 is finally here. I'd also like to thank the community for being such a warm welcoming group. You're all awesome :)

Re: 1.0.0 is here

2019-09-23 Thread hugogranstrom
Congrats and thanks to all who has contributed to Nim to make this a reality!

Re: 1.0.0 is here

2019-09-23 Thread treeform
Thank you everyone for Nim 1.0. This is great! Awesome! Fantastic!

Re: Tried to learn NIM some feedback

2019-09-23 Thread juancarlospaco
You are not _forced_ to use all the things you mention, for the use case you mention. ...at least initially :)

1.0.0 is here

2019-09-23 Thread Araq
[https://nim-lang.org/blog/2019/09/23/version-100-released.html](https://nim-lang.org/blog/2019/09/23/version-100-released.html) [https://nim-lang.org/araq/v1.html](https://nim-lang.org/araq/v1.html) Many thanks to all our contributors and supporters!

Re: Tried to learn NIM some feedback

2019-09-23 Thread alexeypetrushin
Thanks for the reply. I guessed that most of Nim decisions are probably have good reasons behind. > Static binding should be the default and many modern languages actually agree > on this, see C#, Rust, etc. There are system languages and application languages. Rust is a system language and pe

Re: Error by duplicated file names (redefinition of 'types'; previous declaration here...)

2019-09-23 Thread LeuGim
That doesn't work, if modules contain some executable code. Simple test: # test.nim import cirruParser / types as cpTypes import anotherModule / types as otherTypes p1() p2() Run # cirruParser/types.nim proc p1* = echo "cirruParser"

Re: Tried to learn NIM some feedback

2019-09-23 Thread Araq
Thanks for this feedback. However, the issues that you bring up cannot be changed much. > Proc are not dynamically dispatched. Static binding should be the default and many modern languages actually agree on this, see C#, Rust, etc. > No clean docs about null-safety I don't know if Nim support

Tried to learn NIM some feedback

2019-09-23 Thread alexeypetrushin
I'm looking for a language that I can use on both server and client, it should be simple, productive and robust (help me with catching errors). I'm currently using TypeScript mostly. Also in past used Ruby (Ruby on Rails) and Java. Pluses: * Types, even requiring to explicitly dismiss fn() if

Re: Nim git branch model

2019-09-23 Thread jxy
Contrary to what has been said here, version-1-0 branched off devel, and version-0-20 looks dead to me. Congratulations anyway!

Re: Error by duplicated file names (redefinition of 'types'; previous declaration here...)

2019-09-23 Thread leorize
Quick fix: import cirruParser / types as cpTypes Run This is because the actual module name is `types`, not `cirruParser/types`, so it will conflict when you import yet another `types` elsewhere. In such case, the `import as` statement becomes handy.

Re: Error by duplicated file names (redefinition of 'types'; previous declaration here...)

2019-09-23 Thread LeuGim
If I understood you right, that may be undesirable: first, for big packages, you may need a small part of their functionality and not want to compile all of it; second, by avoiding name clash for modules, that should increase name clash for what's defined in them (procedures, types, etc.) (becau