Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim 2.0 thoughts

forum.nim-lang.org

Post reply on HN
Print view View original

21–30 of 150 posts

Re: Nim 2.0 thoughts

#21

Post by khaledh »

sp33der89 wrote: post #18
khaledh wrote: post #10

Earlier quoted context omitted.

I love python as well, and I literally just started exploring Nim yesterday, so this is very timely. The one thing that stuck out to me like a sore thumb is the camelCase convention. I know it's a minor thing (and a personal preference), but I'm a bit biased against languages that use camelCase (Java, JavaScript, etc). There's something uneasy about it IMHO.

Even though it's not according to the styleguide, you can just use snake_case whenever and wherever you want, consumers of your libraries or other way around will never notice!

Then you end up with an ecosystem with mixed conventions. Not good IMO.

Re: Nim 2.0 thoughts

#22

Post by BracketMaster »

One thing people don't often bring up is how great nim is for writing DSLs.

DSLs really matter in the hardware and digital design space - a space that seems to be completely devoid of innovation when it comes to tooling.

A couple languages that try to bring RTL into the 21st century are nMigen-Python and Chisel-Scala.

I'm currently writing an RTL in Nim.

Nim's macro system allows you to do really cool things like instantiate named RTL wires and create custom operators like `:=` for Signal assignment. Really excited about tier 1 BigNum support coming soon - which will make it easier to simulate arbitrary width integer signal arithmetic.

Re: Nim 2.0 thoughts

#23

Post by jb1991 »

michaelsbradley wrote: post #15
khaledh wrote: post #10

Earlier quoted context omitted.

I love python as well, and I literally just started exploring Nim yesterday, so this is very timely. The one thing that stuck out to me like a sore thumb is the camelCase convention. I know it's a minor thing (and a personal preference), but I'm a bit biased against languages that use camelCase (Java, JavaScript, etc). There's something uneasy about it IMHO.

Nim is partially case-insensitive: https://nim-lang.github.io/Nim/manual.html#lexical-analysis-... my_foo, myfoo, and myFoo are interchangeable. MyFoo is different because the first letter is capitalized. If it's not clear, what I mean is that if you've imported a module that exports myFoo, you can refer to it in your code as my_foo, if you prefer. Some people love this aspect of Nim, others loathe it. I don't have s…

>my_foo, myFoo, and myFoo are interchangeable.

I'm confused, two of those are myFoo, so I hope they are interchangeable!

Re: Nim 2.0 thoughts

#24

Post by michaelsbradley »

WesolyKubeczek wrote: post #12
adenozine wrote: post #4

Potentially unpopular opinion, please go easy on me, I'm a python lover: I find a lot of Nim syntax just unnecessarily noisy. I wish that it had stuck much closer to Python syntax. I'm really excited about Nim, don't get me wrong. I like Araq, he's got a real hacker spirit not oft found at the head of big projects. Anyhow. I'm sure the experts in that topic will sort it all out. ORC is wildly impressive all around.

I can't get used to the fact that for builtin types grow methods, you need to import corresponding modules everywhere. You import module X, which gets you objects as defined in the module Y. To use methods defined for that type, you need to import Y yourself. Python, of course, by virtue of binding objects to methods, doesn't need it. There are some more namespacing quirks that may require one to give up on that swee…

> you need to import corresponding modules everywhere

It's a good practice to re-export "all modules whose types appear in public symbols of the current module".

For that and other good advice, see The Status Nim style guide:

https://status-im.github.io/nim-style-guide/03_language.html...

Re: Nim 2.0 thoughts

#25

Post by planetis »

khaledh wrote: post #19
michaelsbradley wrote: post #15

Earlier quoted context omitted.

Nim is partially case-insensitive: https://nim-lang.github.io/Nim/manual.html#lexical-analysis-... my_foo, myfoo, and myFoo are interchangeable. MyFoo is different because the first letter is capitalized. If it's not clear, what I mean is that if you've imported a module that exports myFoo, you can refer to it in your code as my_foo, if you prefer. Some people love this aspect of Nim, others loathe it. I don't have s…

Good to know. Although I'd argue that this is something that I'd count _against_ the language. I'm also biased against languages that allow you to do the same thing in multiple ways (hint: Scala). Code bases tend to vary according to the team's own conventions, so you have to keep adapting to whatever code base you happen to be reading.

--styleCheck:on to enforce the style every identifier is declared in your code base.

Re: Nim 2.0 thoughts

#26

Post by dragonwriter »

jb1991 wrote: post #23
michaelsbradley wrote: post #15

Earlier quoted context omitted.

Nim is partially case-insensitive: https://nim-lang.github.io/Nim/manual.html#lexical-analysis-... my_foo, myfoo, and myFoo are interchangeable. MyFoo is different because the first letter is capitalized. If it's not clear, what I mean is that if you've imported a module that exports myFoo, you can refer to it in your code as my_foo, if you prefer. Some people love this aspect of Nim, others loathe it. I don't have s…

>my_foo, myFoo, and myFoo are interchangeable. I'm confused, two of those are myFoo, so I hope they are interchangeable!

I think it intended my_foo, myFoo, and myfoo.

Re: Nim 2.0 thoughts

#27

Post by michaelsbradley »

jb1991 wrote: post #23
michaelsbradley wrote: post #15

Earlier quoted context omitted.

Nim is partially case-insensitive: https://nim-lang.github.io/Nim/manual.html#lexical-analysis-... my_foo, myfoo, and myFoo are interchangeable. MyFoo is different because the first letter is capitalized. If it's not clear, what I mean is that if you've imported a module that exports myFoo, you can refer to it in your code as my_foo, if you prefer. Some people love this aspect of Nim, others loathe it. I don't have s…

>my_foo, myFoo, and myFoo are interchangeable. I'm confused, two of those are myFoo, so I hope they are interchangeable!

Fixed. The second or third one should have been all lowercase.

Re: Nim 2.0 thoughts

#28

Post by dragonwriter »

khaledh wrote: post #19
michaelsbradley wrote: post #15

Earlier quoted context omitted.

Nim is partially case-insensitive: https://nim-lang.github.io/Nim/manual.html#lexical-analysis-... my_foo, myfoo, and myFoo are interchangeable. MyFoo is different because the first letter is capitalized. If it's not clear, what I mean is that if you've imported a module that exports myFoo, you can refer to it in your code as my_foo, if you prefer. Some people love this aspect of Nim, others loathe it. I don't have s…

Good to know. Although I'd argue that this is something that I'd count _against_ the language. I'm also biased against languages that allow you to do the same thing in multiple ways (hint: Scala). Code bases tend to vary according to the team's own conventions, so you have to keep adapting to whatever code base you happen to be reading.

> I'm also biased against languages that allow you to do the same thing in multiple ways

So you oppose languages supporting both recursion and iteration?

Re: Nim 2.0 thoughts

#29

Post by sergiotapia »

The restructuring of the system namespaces come as a very welcome addition. --threads:on by default is awesome too!

I love this language so much, I am so happy to see this much momentum coming from Araq and the gang. They are very kind people that help you in the Discord server.

For all the help I've been given for free time and time again by these guys, I'm working on a series of exercises to hopefully minimize the onboarding time for people looking to explore Nim. https://github.com/sergiotapia/nimlings

Re: Nim 2.0 thoughts

#30

Post by patrickmn »

khaledh wrote: post #21
sp33der89 wrote: post #18

Earlier quoted context omitted.

Even though it's not according to the styleguide, you can just use snake_case whenever and wherever you want, consumers of your libraries or other way around will never notice!

Then you end up with an ecosystem with mixed conventions. Not good IMO.

You can literally do whatever you want with any library you use in your own codebase and have a consistent convention in your own code regardless of what your dependencies' authors preferences are. In other words, if the library authors used camelCase but you want to use snake_case in your code, you just do it.

It's very strange at first, and I had the same reaction as you, but it's actually quite nice. (I say that as somebody who strongly dislikes snake_case :) )

Post reply on HN