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

31–40 of 150 posts

Re: Nim 2.0 thoughts

#31

Post by sp33der89 »

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 get what you're at with the multiple ways to do stuff, but in Nim it actually makes it more consistent (imo).

If my codebase enforces camelCase and a library uses snake_case, then I can still use that library using camelCase, and Nim has nimgrep to make this easier all the way.

Re: Nim 2.0 thoughts

#32

Post by thinkyfish »

The biggest thing that nim needs isn't a language change, it is to make it easy (or more expected) to put .dll's in nimble libraries. Wheels in python is one of the major reasons i'm using it. Who needs to figure out how to compile qt? I can just pip install PySide6, why can't I do that with nim? Yes, it's a lot more work vetting licenses and testing/patching things to make them work on various platforms (about the same amount of work as a linux distro), but thats the best road I can see for adoption.

Re: Nim 2.0 thoughts

#33

Post by thechao »

BracketMaster wrote: post #22

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 ins…

Do you have anything public? I’ve been following LLHD for a while; I like the idea of a shared middle end. LLHD’s front end is Verilog/VHDL which are … not great.

Are you translating, or building your own sim runtime?

Re: Nim 2.0 thoughts

#34

Post by adenozine »

xigoi wrote: post #20
adenozine wrote: post #11

Earlier quoted context omitted.

Sure. I'm on phone, so hopefully this paste doesn't look awful, but it's right from the website homepage iterator oddNumbers[Idx, T](a: array[Idx, T]): T = for x in a: if x mod 2 == 1: yield x The three different sets of brackets, the mixed : and =, it just seems inelegant to me. I don't really know how I'd improve it, so it's just pointless, ignorant complaining on my part. Pay me little mind.

The equivalent in Python would be: T = TypeVar("T") def odd_numbers(a: list[T]) -> Iterator[T]: # implementation I don't really find that less verbose, in terms of brackets and symbols…

Yeah, I guess you're right.

Re: Nim 2.0 thoughts

#35

Post by Oreb »

I started using Nim recently and have been very impressed. It feels like a better Rust than Rust, and a better Go than Go. Why doesn’t Nim get more attention?

Re: Nim 2.0 thoughts

#36

Post by khaledh »

dragonwriter wrote: post #28
khaledh wrote: post #19

Earlier quoted context omitted.

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?

recursion vs. iteration, inheritance vs. composition, interfaces vs. abstract classes, etc. are design choices that depend on the problem being solved. Language syntax is different; it's an opinion of the language designer which gives the language its distinctive style, and IMO shouldn't have much leeway in expressing the same thing in multiple ways. It's what gives the language its identity.

For example, here's how you can iterate over a list in scala to print each element:

    List(1, 2, 3).foreach(element => println(element))
    List(1, 2, 3) foreach { element => println(element) }
    List(1, 2, 3).foreach(println(_))
    List(1, 2, 3).foreach { println(_) }
    List(1, 2, 3).foreach { println _ }
    List(1, 2, 3).foreach(println)
    List(1, 2, 3) foreach (println)
    List(1, 2, 3) foreach { println }
    List(1, 2, 3) foreach println

Re: Nim 2.0 thoughts

#37

Post by adsharma »

xigoi wrote: post #16
adsharma wrote: post #9

Earlier quoted context omitted.

If you prefer python syntax, you can code in python and transpile? Py2many supports nim. I wonder if there is sufficient interest in having a python stdlib compatible library for nim.

https://github.com/Yardanico/nimpylib

https://github.com/adsharma/py2many/issues/229

Re: Nim 2.0 thoughts

#38

Post by davidkunz »

Oreb wrote: post #35

I started using Nim recently and have been very impressed. It feels like a better Rust than Rust, and a better Go than Go. Why doesn’t Nim get more attention?

I think one reason is that there's no big corporation behind it, for Rust it was Mozilla and now the members of the Rust Foundation, for Go it is Google.

But I totally agree, Nim is an awesome language and definitely deserves more attention!

Re: Nim 2.0 thoughts

#39

Post by sp33der89 »

Oreb wrote: post #35

I started using Nim recently and have been very impressed. It feels like a better Rust than Rust, and a better Go than Go. Why doesn’t Nim get more attention?

"a better Go than Go", this is exactly how I use Nim currently, and I couldn't have said it better myself!

Re: Nim 2.0 thoughts

#40

Post by tubbyjr »

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.

Your bias is your own problem. There's clearly a solution that allows you to use snake_case and those that potentially import your library to seamlessly use all exports as camelCase, yet you're still bothered by that. It's nonsensical, Nim literally came up with the absolute most elegant solution to this.
Post reply on HN