Nim 2.0 thoughts

235 145 5 years ago

Jorge1o1• 5 years ago

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.

michaelsbradley8• 5 years ago

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

adenozine4• 5 years ago

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.

michaelsbradley8• 5 years ago

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.

adenozine4• 5 years ago

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.

xioren00• 5 years ago

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

sp33der894• 5 years ago

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

adsharma2• 5 years ago

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.

xigoi5• 5 years ago

https://github.com/Yardanico/nimpylib

khaledh4• 5 years ago

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.

osmarks• 5 years ago

It matches identifiers style-insensitively so you can actually use other conventions if you want. Although the online docs are still camelcased.

michaelsbradley8• 5 years ago

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 strong feelings about it, though one has to be mindful of it when searching through a codebase with e.g. the_silver_searcher.

sp33der894• 5 years ago

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!

bobbylarrybobby• 5 years ago

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.

WesolyKubeczek• 5 years ago

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.

michaelsbradley8• 5 years ago

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

Nimitz14• 5 years ago

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

mrweasel9• 5 years ago

Completely fair, syntax is something that resonate differently from person to person. I love the idea of Rust, it’s speed, capabilities, it’s politics and it’s independence, but I cannot stand it’s syntax.

That’s fine, I can use other languages and it doesn’t take anything away from Rust or the people who love the syntax.

Aardappel2• 5 years ago

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.

adenozine4• 5 years ago

You probably won't see this, but in fact I've really enjoyed playing with Lobster!

Thanks for telling me about it, I hadn't taken it seriously before.

planetis12• 5 years ago

I just love the new numeric literals syntax:

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

It's so sexy!

BracketMaster4• 5 years ago

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.

thechao2• 5 years ago

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?

BracketMaster4• 5 years ago

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

BracketMaster4• 5 years ago

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.

georgelyon• 5 years ago

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

coolreader18• 5 years ago

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• 5 years ago

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?

BracketMaster4• 5 years ago

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

kaushalmodi• 5 years ago

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.

dom96• 5 years ago

Please consider creating a write up about this. As someone that had very little knowledge about the hardware design space I'd love to learn more about it and see how Nim solves some problems there :)

sergiotapia• 5 years ago

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

thinkyfish• 5 years ago

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.

Oreb• 5 years ago

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• 5 years ago

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!

open-source-ux• 5 years ago

"I think one reason is that there's no big corporation behind it"

I agree. The popularity of some programming languages is undoubtedly buoyed by corporate sponsorship or the association with a company. This is not a bad thing, but it means other languages struggle to generate as much interest.

Also, without a generous benefactor, open source languages have to scrape funding together piecemeal from different sources. For example, both Rust and Go have had (or still have) dedicated staff writing documentation for the language. This is a luxury that other languages cannot fund or afford.

I actually posted a Ask HN question of this very topic recently: Can new programming languages attract developers without funding?"

https://news.ycombinator.com/item?id=27043717

m_mueller3• 5 years ago

Didn't python start this way 25ish years ago? It then has slowly and steadily gained developers. Nim might also be there in another 15 years.

sp33der894• 5 years ago

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

serverholic• 5 years ago

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.

fastball• 5 years ago

Yes garbage-collected, with a caveat. From the website:

Nim's memory management is deterministic and customizable with destructors and move semantics, inspired by C++ and Rust. It is well-suited for embedded, hard-realtime systems.

michaelsbradley8• 5 years ago

It has a garbage collector by default, though it can be disabled (--gc:none) and then you can manage memory manually.

In the future, Nim's default memory management will use reference counting with destructors and move semantics inspired by Rust and C++.

https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...

https://nim-lang.org/docs/destructors.html

https://nim-lang.org/docs/nimc.html

ilaksh2• 5 years ago

You can avoid it if you want. That is what a lot of the recent changes are about.

one2three4• 5 years ago

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

cb3214• 5 years ago

First, I like that you said "multicores" and not "multithreads". Default-sharing of all memory is overrated. Sometimes it is useful/necessary, but people reach for threads too readily, IMO.

For multiprocessing (like Python's module of that name), you can roll your own little system in probably 100 lines of code or use something like this [1] with an example program [2]. For me, that toy program runs 1.5-2x faster than ripgrep on the same (admittedly limited) problem on Linux. { I suspect this perf diff is due to mmap IO being faster than syscall IO due to SIMD register use as discussed here [3], but this deserves deeper investigation than I have time for right now. If my hunch is right, that may constitute further argumentative support for not leaping to threads even if the programming language "makes them 'easy'", though. }

As for threads/parallelism with shared memory in Nim..Honestly, there is probably too much to recap. Weave [4] would be a good place to start reading, though, or searching the Nim Forum.

  [1] https://github.com/c-blake/cligen/blob/master/cligen/procpool.nim

  [2] https://github.com/c-blake/cligen/blob/master/examples/grl.nim

  [3] https://news.ycombinator.com/item?id=24842648

  [4] https://github.com/mratsim/weave

skynet-9000• 5 years ago

and channels... extremely useful for network servers.

eikenberry• 5 years ago

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.

TylerE2• 5 years ago

Pretty good. The actual compilation is via clang, so there's a lot of heavy lifting done by that.

So basically nim actually compiles .nim -> .c -> binary

nimmer6• 5 years ago

Nim compiles to C and then runs GCC (not LLVM) to compile the binary. Overall, it's much faster than Go and Rust.

mrweasel9• 5 years ago

For my small learning projects, on old hardware, I’d say about the same as Go.

forgotpwd16• 5 years ago

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.

nimmer6• 5 years ago

Nim is getting very close to Rust in terms of safety (but without the verbose ownership management)

https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...

https://nim-lang.org/blog/2020/12/08/introducing-orc.html

planetis12• 5 years ago

It was discussed recently: https://forum.nim-lang.org/t/7905

to Swift which can cause memory leaks

The Nim compiler can detect cycles and warn you. And --gc:orc collects them successfully at runtime. Orc is going to be the default.

ilaksh2• 5 years ago

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.

mrweasel9• 5 years ago

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.

otherme1233• 5 years ago

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

sigzero• 5 years ago

Something like:

https://nim-lang.org/docs/asynchttpserver.html

https://github.com/zendbit/nim.zfblast

ferdowsi• 5 years ago

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.

xigoi5• 5 years ago

In idiomatic Nim, you don't have inheritance. It's mostly there for the people who love their OOP.

komuher• 5 years ago

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

pindab0ter• 5 years ago

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

otherme1233• 5 years ago

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.

TylerE2• 5 years ago

When you want the performance of a low level compiled language with the ease of use and powerful constructs of a high level language - and don't want all the bondage and discipline of rust.

nicoburns• 5 years ago

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.

Nim 2.0 thoughts

Related Stories