Nim 2.0 thoughts

[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.

[georgelyon]

This sounds cool, I would be very interested if you had any public code. It’s _very_ early days but I’m working on a similar project in Swift: https://github.com/circt/Edith

[kaushalmodi]

It's great to see reference to hardware design in this thread.

Not hardware, but I have been using Nim for DPI-C interface with SystemVerilog for quite some time. Few weeks back, I started tinkering with Nim macros, and started working on a project to make the VPI interface more approachable.

This language is kind of a hidden gem that not many people are aware of in the HDL/HVL space.

[thechao]

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?

[coolreader18]

Yep, one of the main things I did with nim for the month or 2 I was really into it was write a duktape wrapper[0] (in retrospect, I should have made the name a pun related to wrapping with tape...). It was pretty interesting given the stack-based nature of almost every duktape operation.

[0]: https://github.com/coolreader18/duk

[Siira]

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?

[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?

[davidkunz]

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!

[forgotpwd16]

It may be better than Go but I don't see how it is comparable to Rust. Rust's biggest selling point is compilation-checked memory and thread safety guarantee without garbage collection. Nim instead uses a garbage collector, or a reference counter similar (but deterministic) to Swift which can cause memory leaks, or manual memory management.

[mrweasel]

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.

[sp33der89]

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

[eikenberry]

How is the compiler, speed wise? One thing I really like about Go and really don't like about Rust are their relative compiler speeds. I think it makes a big different for the language and Nim has a chance to get this right as they didn't make the mistake of using LLVM and it's bad compiler UX.

[serverholic]

Nim has a garbage-collector right? In that case I don't see how you can compare Nim and Rust. The Go comparison makes more sense.

[one2three4]

How's Nim faring with regards to easy programming for multicores? (I think that's the main selling point of Go).

[ilaksh]

It would be interesting to see a compilation of all of the times people asked that question. Like literally every time anything about Nim is posted, someone asks that.

[ferdowsi]

Including inheritance in nim was a design mistake and is enough to make me pass on it. Go and Rust were correct in avoiding inheritance in the language.

[Jorge1o1]

I think you should include “thoughts” (as it says in the forum post) in the title or in some way disclose that this is just a design/planning/brainstorming session for Nim 2.0 and not actually a major new release.

[michaelsbradley]

I included it in the title as originally submitted and seen in the new page, must have been edited out.

[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

[adenozine]

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.

[xioren00]

Static typing aside, I don't find it any more verbose (noisy) than Python. In fact I find it strikes a perfect balance.

[michaelsbradley]

Can you give an example of noisy syntax? Is it in relation to the type system?

I'm writing Nim every day recently; I haven't experienced it being noisy, but I also don't have extensive or recent experience with Python.

[WesolyKubeczek]

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 sweet syntactic sugar to disambiguate things (two unrelated modules defining methods on a single type, with the same signature but different behaviors, and you need both modules imported for some reason?), but this is, again, something one would have to get used to. It's not a different world like Rust or Prolog.

It's not a complete showstopper, just something I keep bumping my head into now and then.

[khaledh]

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.

[Aardappel]

If you want a statically typed language with Python-alike syntax but Nim is too "noisy" for you, then Lobster (http://strlen.com/lobster/) is likely spot-on.

[sp33der89]

Do you have examples of what you mean with unnecessarily noise? For me it's the JSON operators. `@[]` for sequences could also be a thing, but it's really minor(for me).

[adsharma]

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.

[Nimitz14]

I agree. The syntax is the main reason I don't use it.

[planetis]

I just love the new numeric literals syntax:

  proc `'i128`(n: string): Int128 = parseDecimalInt128(n)
  assert fib(184) == 127127879743834334146972278486287885163'i128

It's so sexy!

[komuher]

Man nim is such a cool language it just need some more community and better docs to get some hype.

[pindab0ter]

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

[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.

[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.