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

81–90 of 150 posts

Re: Nim 2.0 thoughts

#81

Post by DangitBobby »

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.

Me too. I do a lot of grepping on codebases and this seems like it could bite me at some point. But it is a very interesting approach to solving the naming convention problem.

Re: Nim 2.0 thoughts

#82

Post by otherme123 »

mrweasel wrote: post #69
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?

What made me pick Go over Nim is a bigger standard library. For my use Nim is missing a good http server package/module and templating. If those two things had been present I would pick Nim over Go, it’s just a nice language for some like me, who have mostly done Python. I’m not sure if this was a bug in a third party module, but I also struggled a little with unicode support.

Templating as in Jinja? I'm using Karax (https://github.com/karaxnim/karax#server-side-html-rendering) and it's awesome.

Re: Nim 2.0 thoughts

#83

Post by BracketMaster »

thechao wrote: post #33
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?

Not yet - but keep an eye out here: https://github.com/chipeleven

Re: Nim 2.0 thoughts

#84

Post by BracketMaster »

Siira wrote: post #80
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…

Isn’t the bottleneck there the core software being proprietary? I think even verilog (which is quite old) doesn’t have a mature FOSS compiler+IDE. There are also probably not that many hardware designers in the world?

Yosys is a very capable FOSS synthesizer and Verilator is a FOSS simulator actually used in production at ARM.

Re: Nim 2.0 thoughts

#85

Post by BracketMaster »

thechao wrote: post #33
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?

Simulator is written internally in Nim. There isn't really a good FOSS IR for RTL sims on the market currently. I absolutely refuse to use MLIR or anything based on LLVM for that matter. LLVM takes up to 40 minutes to rebuild on my Apple silicon. This is completely unacceptable in terms of rapid iteration.

Re: Nim 2.0 thoughts

#86

Post by nicoburns »

> The bundler takes specific commits of Nimble packages and makes it part of the official Nim distribution (that is, the zips and tarballs you can download from our website). Documentation of these modules is included, there is CI integration and to bring a new commit into the distribution, the changes need to have been reviewed, exactly like stdlib PRs are handled. I hope this will keep the benefits of today's monorepo but with more flexibility -- we can then more easily place modules

I wish more languages would take this approach. Modules that are officially endorsed and shipped with the compiler, but versioned rather than perma-stable like the standard library.

It would work fantastically for lots of Rust's defacto standard crates.

Re: Nim 2.0 thoughts

#87

Post by xigoi »

memco wrote: post #53
xigoi wrote: post #20

Earlier quoted context omitted.

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…

Does Nim have comprehensions? Even if you're striving for equivalent signatures the inner body of the function can be expressed as a comprehension in Python: T = TypeVar("T") def odd_numbers(a: Iterable[T]) -> Iterator[T]: yield from (n for n in a if n % 2 == 1)

Unfortunately, Nim doesn't have `yield from`, which would make a comprehension useless here. That's one of the things I'm missing in the language.

Re: Nim 2.0 thoughts

#88

Post by V1ndaar »

otherme123 wrote: post #56
pindab0ter wrote: post #44

Earlier quoted context omitted.

What's the main use case of Nim, would you say? Is it good for personal project/automation, for desktop or web apps? Etc.

I started using it for parsing heavy files, just for the speed. Slowly I replaced Python with Nim for almost everything, even when it doesn't make much sense (e.g. for controlling Selenium), and only use Python when I need graphics (Matplotlib) or some other libraries that I cannot replace. IMO the main case is when you need C speed but you don't want to code in C.

> use Python when I need graphics (Matplotlib)

I'm always open to suggestions etc. as to what's missing in ggplotnim [0]. I'd hope that by now the majority of use cases are covered.

[0]: https://github.com/Vindaar/ggplotnim

Re: Nim 2.0 thoughts

#89

Post by thechao »

BracketMaster wrote: post #85
thechao wrote: post #33

Earlier quoted context omitted.

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?

Simulator is written internally in Nim. There isn't really a good FOSS IR for RTL sims on the market currently. I absolutely refuse to use MLIR or anything based on LLVM for that matter. LLVM takes up to 40 minutes to rebuild on my Apple silicon. This is completely unacceptable in terms of rapid iteration.

LLHD is greenfield code, so it’s not based on LLVM. I’m familiar with the authors both academically (15 years ago), and on an engineering level (now). I think it is definitely worth reviewing what they’re bringing to the table.

Anyways, I think the RTL market is ripe for disruption. There was a lot of great language work done by, for instance, Ronald Garcia, directly aimed at fixing pain points in HDLs, like parsmetrization.

Re: Nim 2.0 thoughts

#90

Post by bobbylarrybobby »

khaledh wrote: post #10
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 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.

One thing that’s always bugged me about snake case is that people are so averse to the additional length of strings that they just omit the underscores. So you end up with methods like array.tolist() and itertools.ziplongest(*lists, fill_value=None) — that last one isn’t even internally consistent. In an ideal world I would find snake case more readable, but people actually adhere to camel case, which makes it more readable than snake case overall.
Post reply on HN