36 ms·
Nim 2.0 thoughts
- Jorge1o1 5y agoI 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 5y agoI included it in the title as originally submitted and seen in the new page, must have been edited out.
- adenozine 5y agoPotentially 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.
- michaelsbradley 5y agoCan 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.
- adenozine 5y agoSure. 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.
- xigoi 5y agoThe 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…
- adenozine 5y agoYeah, I guess you're right.
- memco 5y agoDoes 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)
- michaelsbradley 5y agoSee collect: https://nim-lang.org/docs/sugar.html#collect.m%2Cuntyped%2Cuntyped https://nim-lang.org/docs/sugar.html#collect.m%2Cuntyped%2Cu...
- xigoi 5y agoUnfortunately, 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.
- planetis 5y agoThat's an obscure/not optimal way to write this code though. I mean why would you use LIST comprehension if you are going to yield each element.
- nerdponx 5y agoIt's not list comprehension, it's generator comprehension, which is lazily computed. However it's still an unnecessary layer of iteration, when you could just return the comprehension instead.
- xioren00 5y agoStatic typing aside, I don't find it any more verbose (noisy) than Python. In fact I find it strikes a perfect balance.
- sp33der89 5y agoDo 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 5y agoIf 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.
- khaledh 5y agoI 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 5y agoIt matches identifiers style-insensitively so you can actually use other conventions if you want. Although the online docs are still camelcased.
- michaelsbradley 5y agoNim is partially case-insensitive: https://nim-lang.github.io/Nim/manual.html#lexical-analysis-identifier-equality 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.
- khaledh 5y agoGood 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.
- planetis 5y ago--styleCheck:on to enforce the style every identifier is declared in your code base.
- 5y ago
- WesolyKubeczek 5y agoI 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.
- michaelsbradley 5y 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#import-export https://status-im.github.io/nim-style-guide/03_language.html...
- Nimitz14 5y agoI agree. The syntax is the main reason I don't use it.
- mrweasel 5y agoCompletely 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.
- Aardappel 5y agoIf you want a statically typed language with Python-alike syntax but Nim is too "noisy" for you, then Lobster (http://strlen.com/lobster/ http://strlen.com/lobster/) is likely spot-on.
- deleted 5y ago[deleted]
- planetis 5y agoI just love the new numeric literals syntax: proc `'i128`(n: string): Int128 = parseDecimalInt128(n) assert fib(184) == 127127879743834334146972278486287885163'i128 It's so sexy!
- shomyo 5y ago'/tmp/hc.nim(5, 1) Error: tabs are not allowed, use spaces instead' Fundamentally broken.
- BracketMaster 5y agoOne 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.
- thechao 5y agoDo 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?
- BracketMaster 5y agoNot yet - but keep an eye out here: https://github.com/chipeleven https://github.com/chipeleven
- BracketMaster 5y agoSimulator 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.
- thechao 5y agoLLHD 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.
- sergiotapia 5y agoThe 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 https://github.com/sergiotapia/nimlings
- thinkyfish 5y agoThe 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 5y agoI 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 5y agoI 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 5y 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 https://news.ycombinator.com/item?id=27043717
- darthrupert 5y ago> For example, both Rust and Go have had (or still have) dedicated staff writing documentation for the language. And PR most importantly.
- m_mueller 5y agoDidn'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.
- 5y ago
- komuher 5y agoMan nim is such a cool language it just need some more community and better docs to get some hype.
- pindab0ter 5y agoWhat's the main use case of Nim, would you say? Is it good for personal project/automation, for desktop or web apps? Etc.
- otherme123 5y agoI 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.
- mrweasel 5y agoNim as a replacement for Python makes sense to me. We often hear that many Python developers went on to choose Go when needing more performance, but Nim feels like an easier move.
- cb321 5y agoNim code also tends to run faster than Go code (in my experience).
- mrweasel 5y agoI didn’t meassure, but I also don’t have any experience saying otherwise. Both are great languages and depending on the problem I’d be happy to use either.
- QQ00 5y agoNim not only faster than Go but have a very similar syntax to python. It make more sense for Python developers to use Nim when need more speed instead of Go.
- nicoburns 5y 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.