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

131–140 of 150 posts

Re: Nim 2.0 thoughts

#131

Post by dom96 »

kaushalmodi wrote: post #130
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…

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.

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

Re: Nim 2.0 thoughts

#132

Post by darthrupert »

open-source-ux wrote: post #46
davidkunz wrote: post #38

Earlier quoted context omitted.

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!

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

And PR most importantly.

Re: Nim 2.0 thoughts

#133

Post by renox »

bobbylarrybobby wrote: post #90
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.

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

Camel case consistent? You must be reading different code than me: Ue/UE, Subcell/SubCell, cellgroup, cellGroup all seen in the codebase I work..

Re: Nim 2.0 thoughts

#134

Post by throwaway894345 »

elcritch wrote: post #95
throwaway894345 wrote: post #51

Earlier quoted context omitted.

This is interesting. The hard-realtime folks are a conservative bunch (understandably so); I wonder how much traction Nim is getting in that space.

There’s a few of us working in this area, well rather Nim on embedded microcontrollers. :-) It works fantastically, though most of us aren’t traditional hard real time folks. Nevertheless Nim’s new ARC is excellent for this area. The overhead of the GC basically is just an increment/decrement on an integer (no atomic). That means it’s fast and predictable for modern MCUs and plays well with C code. If you want a tigh…

This sounds really cool. I'm glad to hear that there's something rivaling Rust.

Re: Nim 2.0 thoughts

#135

Post by Aardappel »

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.

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.

Re: Nim 2.0 thoughts

#136

Post by xigoi »

mrweasel wrote: post #109
otherme123 wrote: post #82

Earlier quoted context omitted.

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

That’s nothing like Jinja, it’s more like React. I just want text templating and not a virtual dom and I don’t want to build my HTML in Nim.

https://nimble.directory/search?query=mustache

Re: Nim 2.0 thoughts

#137

Post by xigoi »

ferdowsi wrote: post #99
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?

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.

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

Re: Nim 2.0 thoughts

#138

Post by m_mueller »

pjmlp wrote: post #113
m_mueller wrote: post #108

Earlier quoted context omitted.

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.

Python did had a couple of smallish killer applications like Zope, being used as scripting language in 3D applications, and gaining adoption among Perl users after Perl 6 never ending story. Additionally Guido has always worked in well known companies, and Microsoft and IBM have toyed with Python on their products as well.

I think that‘s a possible path for Nim to develop. Win over a trickle of python devs who‘ve learned the problems arising once you hit a certain performance ceiling / scale. This is being accentuated by hardware & cloud developments - startup time & compute efficiency becoming increasingly important (containerization/serverless driving one, I/O performance outgrowing CPU perf. driving the other). If those trends continue, Python will increasingly be ill fitted. And I‘m saying this as a Python dev.

Re: Nim 2.0 thoughts

#139

Post by pjmlp »

m_mueller wrote: post #138
pjmlp wrote: post #113

Earlier quoted context omitted.

Python did had a couple of smallish killer applications like Zope, being used as scripting language in 3D applications, and gaining adoption among Perl users after Perl 6 never ending story. Additionally Guido has always worked in well known companies, and Microsoft and IBM have toyed with Python on their products as well.

I think that‘s a possible path for Nim to develop. Win over a trickle of python devs who‘ve learned the problems arising once you hit a certain performance ceiling / scale. This is being accentuated by hardware & cloud developments - startup time & compute efficiency becoming increasingly important (containerization/serverless driving one, I/O performance outgrowing CPU perf. driving the other). If those trends conti…

Except that Guido went to Microsoft to work on their new JIT project, while Instagram is also pursuing their own, and there is Cython which follows the same compile to native code workflow (C based backed) as Nim.

The biggest problem in Python slowness isn't that solutions don't exist, rather the community at large tends not to embrace them as other ecosystems do.

Re: Nim 2.0 thoughts

#140

Post by m_mueller »

pjmlp wrote: post #139
m_mueller wrote: post #138

Earlier quoted context omitted.

I think that‘s a possible path for Nim to develop. Win over a trickle of python devs who‘ve learned the problems arising once you hit a certain performance ceiling / scale. This is being accentuated by hardware & cloud developments - startup time & compute efficiency becoming increasingly important (containerization/serverless driving one, I/O performance outgrowing CPU perf. driving the other). If those trends conti…

Except that Guido went to Microsoft to work on their new JIT project, while Instagram is also pursuing their own, and there is Cython which follows the same compile to native code workflow (C based backed) as Nim. The biggest problem in Python slowness isn't that solutions don't exist, rather the community at large tends not to embrace them as other ecosystems do.

My experience with optimizing Python code after ~10y is that after a certain point it's just not worth it and you'd be better off rewriting in a more performant runtime once you hit that. That includes experiments I did with pypy, Cython and Numba for various projects.
Post reply on HN