Nim 0.20.0 (1.0 RC1) released(nim-lang.org)
nim-lang.org
Nim 0.20.0 (1.0 RC1) released
https://nim-lang.org/blog/2019/06/06/version-0200-released.html
120 comments
Nuitka (nuitka.net) does that for python, and is very robust and compatible. It works way better than py2exe, cx_freeze, etx, and is cross platform.
However, the result, even for small scripts, is not what I would qualify as "small" :)
I also like pex (https://github.com/pantsbuild/pex) which allows to bundle a whole venv as a python script. Less heavy than nuitka, doesn't make it stand alone though, but very handy for quick and dirty scripts I want to one shot on my servers.
That doesn't remove any merit to nim. Such a cool project.
However, the result, even for small scripts, is not what I would qualify as "small" :)
I also like pex (https://github.com/pantsbuild/pex) which allows to bundle a whole venv as a python script. Less heavy than nuitka, doesn't make it stand alone though, but very handy for quick and dirty scripts I want to one shot on my servers.
That doesn't remove any merit to nim. Such a cool project.
>Nuitka (nuitka.net) does that for python, and is very robust and compatible. It works way better than py2exe, cx_freeze, etx, and is cross platform.
However, the result, even for small scripts, is not what I would qualify as "small" :)
How does Nuitka compare for generated executable sizes with PyInstaller? I've used the latter. For small Python scripts, CLI or wxPython, it created EXEs (Windows) in the range of 10 MB in size - with the all-code-in-one-file option.
How does Nuitka compare for generated executable sizes with PyInstaller? I've used the latter. For small Python scripts, CLI or wxPython, it created EXEs (Windows) in the range of 10 MB in size - with the all-code-in-one-file option.
Nuitka also improves performance. It has halved the startup time for a command line tool that I wrote.
As someone who usually develops in Nim but is now stuck with delivering some Python scripts that runs embedded in a C program I feel your pain.. The first time I had to deploy some Nim code and could just copy a single binary to the target machine and run it was such a good feeling!
It does do that. The only issue you might have is library support, but I have found it to be pretty good. For example Nim has had async HTTP client for a while now, while even Rust is just now getting it.
https://nim-lang.github.io/Nim/httpclient
https://github.com/nim-lang/Nim/commit/783087fd
https://nim-lang.github.io/Nim/httpclient
https://github.com/nim-lang/Nim/commit/783087fd
The async lib doesn't supports timeout, meaning not usable in production or any serious workload.
I can see where you get that idea from, indeed the httpclient module doesn't have timeout flags for it's async recieve. But the asyncdispatch has a withTimeout procedure that should happily take the Future that you get from an async recieve and give you a timeout for it.
Neither does JavaScript fetch, I dont get your point
Go might be suited for you as well and it has a bigger ecosystem.
Nim supports dynamic libraries as well and that is very important for security.
A simple tarball would do, or a package or an installer.
I've been full steam on the Nim train for the past year. It really hits a sweet spot between semantic complexity and language power. If you've used any mainstream language and understand types, you already understand 80% of the semantics you need to be productive. But more advanced features (generics, algebraic data types, hygienic macros) are available when needed. Now that the language is approaching 1.0, the only caveat is a small ecosystem and community. Nim has completely replaced Node as my language of choice for side projects and prototyping.
WooHoo! I'm very excited about this. For me, nim has been the perfect glue language in many ways. I hope other people will give it a shot, try out the https://forum.nim-lang.org or their subreddit https://old.reddit.com/r/nim
If anyone is looking to learn Nim, Exercism.io has a Nim track with a good number of exercises.
https://exercism.io/tracks/nim
https://exercism.io/tracks/nim
Nim is a super fast python that also prevents typos.
I use nim everyday. 98% of my programming is in nim only. I highly recommend nim. During the day I work mostly on internal tools and dashboards, during the night I work on games. Nim compiles to JS and C. Its really good.
I use nim everyday. 98% of my programming is in nim only. I highly recommend nim. During the day I work mostly on internal tools and dashboards, during the night I work on games. Nim compiles to JS and C. Its really good.
Any way you could go into more detail on your work and how your apps are setup. I'm guessing your Nim code transpiles the dashboard code to JS and the backend to C?
Forgive me while I make some gross generalizations:
Objective-C -> Swift
Python -> Nim
Ruby -> Crystal
JavaScript -> Elm—or maybe TypeScript?
C/C++ -> Rust
C++ -> Rust
...is correct, but
C -> Rust
...is not IMHO. There needs to be a much smaller, simpler, "better C" language than Rust to replace C. Something like zig, or C2, even C99 almost feels like a new language.
PS: ...and I forgot the fairly obvious C -> Go :)
...is correct, but
C -> Rust
...is not IMHO. There needs to be a much smaller, simpler, "better C" language than Rust to replace C. Something like zig, or C2, even C99 almost feels like a new language.
PS: ...and I forgot the fairly obvious C -> Go :)
I'm not convinced you can be much simpler than Rust while maintaining memory safety without GC (including reference counting) while still having standard heap allocation and deallocation. If you throw out memory safety, then sure, you can be simpler.
I'm looking forward to exploring this space in the next 1-2 release cycles of Zig. I have some ideas that will make debug and release-safe builds of zig code actually safe with regards to use-after-free and related memory issues.
The programmer will still be required to adhere to C-like manual memory semantics, with the difference being the language runtime catches safety mistakes. And then of course in bottlenecks the safety checks can be omitted.
If I accomplish my goal, the difference between safety/performance trade-off of Rust and Zig will be that Rust's release mode is both safe and fast, whereas Zig code has the simplicity but the programmer has to choose between performance and safety per scope.
The programmer will still be required to adhere to C-like manual memory semantics, with the difference being the language runtime catches safety mistakes. And then of course in bottlenecks the safety checks can be omitted.
If I accomplish my goal, the difference between safety/performance trade-off of Rust and Zig will be that Rust's release mode is both safe and fast, whereas Zig code has the simplicity but the programmer has to choose between performance and safety per scope.
I'm not familiar with the C-family languages, but given that Go is GC, wouldn't Rust be a better "C 2.0"?
I would still put Go into the "better C" language group because of its elegance and simplicity, even if it can't be used for all scenarios C can be used for (because of the GC).
To me at least, Rust looks like an obvious attempt to fix C++'s problems for large scale software development, but at the cost of being a big and complex language, similar in scope to C++. "Modern C" is a much simpler and elegant language, even though there's some decades old cruft, overall it remained a lot cleaner than C++ because there hasn't been so much stuff added in the first place which would be a burden now.
To me at least, Rust looks like an obvious attempt to fix C++'s problems for large scale software development, but at the cost of being a big and complex language, similar in scope to C++. "Modern C" is a much simpler and elegant language, even though there's some decades old cruft, overall it remained a lot cleaner than C++ because there hasn't been so much stuff added in the first place which would be a burden now.
I sincerely can't fathom how Go can be considered a "better C". It's like comparing cars to sheet metal (or some better analogy).
Go is fundamentally incompatible in most contexts C would be your go-to. A moderately heavy runtime with both a scheduler and a GC unable to compile down to a ".so"? C++ and Rust can both do those things readily.
Languages aren't just syntax/semantics, they're ecosystems within ecosystems. They fill niches with particular their capabilities.
A more appropriate comparison is Go to Java. Distict approaches to "half batteries included" robust application and service development.
Go is fundamentally incompatible in most contexts C would be your go-to. A moderately heavy runtime with both a scheduler and a GC unable to compile down to a ".so"? C++ and Rust can both do those things readily.
Languages aren't just syntax/semantics, they're ecosystems within ecosystems. They fill niches with particular their capabilities.
A more appropriate comparison is Go to Java. Distict approaches to "half batteries included" robust application and service development.
> A more appropriate comparison is Go to Java.
Not even. Golang lacks the expressiveness and vast standard library in Java (e.g. nothing even close to what java.util.concurrent has), not to mention the very diverse ecosystem, tunable high performance GCs, and management capabilities of the JVM.
Not even. Golang lacks the expressiveness and vast standard library in Java (e.g. nothing even close to what java.util.concurrent has), not to mention the very diverse ecosystem, tunable high performance GCs, and management capabilities of the JVM.
But those are all great, directly relevant, appropriate points of comparison. And they work because those two language operate in a similar niche.
I'm not sure they are. golang was force fitted into writing applications it was not meant for. It was made to be a C++ replacement, but it ended up anything but (basically ended up as a Python and NodeJS replacement).
I can see golang being useful in smaller tools that have some networking capability (and with GraalVM+AOT, Java fills in that niche as well). However, with anything slightly more complex (including REST APIs), and it falls way short. So it shouldn't be compared to Java.
I can see golang being useful in smaller tools that have some networking capability (and with GraalVM+AOT, Java fills in that niche as well). However, with anything slightly more complex (including REST APIs), and it falls way short. So it shouldn't be compared to Java.
I gotta agree to disagree with you on this.
Python/NodeJS/Java/Ruby/Go all have a solid presence in the "I need to spin up a REST/SOA/gRPC/glue service wherever" niche. They each have a range of performance, expression, resource optimality, and ecosystem tradeoffs; but they're all still heavyweights in this particular domain. They each have a presence in other "types" of programming but I think it's also fair to compare them within this one.
Go has a few things which make it especially nice in this field out of the box. Goroutines + channels + select help solve the same class of problems that made reactor patterns, work stealing fork-join pools, listenable/completable futures so popular in Java-land. Go's sockets give you epolling for free where we'd use Netty in Java land.
In fact, they each if those language ecosystems struggle with that class of problem in this field: Good kernel thread utilization in the presence of very mixed cpu + network I/O load. What's why they all have a handful of the same approaches: Ruby/Python/NodeJS all do the reverse proxy on top n processes of of libuv/gevent/whatever event loops (reactor pattern). Java and Go are actually similar in that they actually try to use threads well within a single process.
I say this as an obsessive Java fanboy. I'm jealous of a few Go things I can't have: Goroutines (green threads) and flatter struct+array memory allocations. I can't wait for Loom and Valhalla.
Python/NodeJS/Java/Ruby/Go all have a solid presence in the "I need to spin up a REST/SOA/gRPC/glue service wherever" niche. They each have a range of performance, expression, resource optimality, and ecosystem tradeoffs; but they're all still heavyweights in this particular domain. They each have a presence in other "types" of programming but I think it's also fair to compare them within this one.
Go has a few things which make it especially nice in this field out of the box. Goroutines + channels + select help solve the same class of problems that made reactor patterns, work stealing fork-join pools, listenable/completable futures so popular in Java-land. Go's sockets give you epolling for free where we'd use Netty in Java land.
In fact, they each if those language ecosystems struggle with that class of problem in this field: Good kernel thread utilization in the presence of very mixed cpu + network I/O load. What's why they all have a handful of the same approaches: Ruby/Python/NodeJS all do the reverse proxy on top n processes of of libuv/gevent/whatever event loops (reactor pattern). Java and Go are actually similar in that they actually try to use threads well within a single process.
I say this as an obsessive Java fanboy. I'm jealous of a few Go things I can't have: Goroutines (green threads) and flatter struct+array memory allocations. I can't wait for Loom and Valhalla.
> I can't wait for Loom and Valhalla.
You said it yourself. Once Java gets those, there isn't really much reason left to use golang. And with probably better performance as well (I know the techempower benchmarks have their issues, but if you noticed, golang's standard lib is towards the bottom of the list).
You said it yourself. Once Java gets those, there isn't really much reason left to use golang. And with probably better performance as well (I know the techempower benchmarks have their issues, but if you noticed, golang's standard lib is towards the bottom of the list).
The creators of C/Unix are the creators of Go.
C/Unix is generally largely credited to Brian Kernighan, Dennis Ritchie, and Ken Thompson. Although Ken Thompson did contribute to Go, he appears to have retired early in the life of the project (I can't find any contributions of his that don't pre-date Go's 1.0 release in 2011), and credit for Go instead tends to lean toward Rob Pike and Robert Griesemer, the former of whom worked at Bell Labs, but appears to have joined in time to have more of an impact on Plan 9 than on Unix. In particular Go bears very striking resemblance to Pike's two earlier languages, Limbo and Newsqueak.
>In particular Go bears very striking resemblance to Pike's two earlier languages, Limbo and Newsqueak.
From the GoPL (The Go Programming Language book, by Donovan and Kernighan), page xii, part of the genealogy is:
CSP (Hoare, 1978) -> Squeak (Cardelli & Pike, 1985) -> Newsqueak (Pike, 1989) -> Alef (Winterbottom, 1992) -> Go (Griesemer, Pike and Thompson, 2009).
From the GoPL (The Go Programming Language book, by Donovan and Kernighan), page xii, part of the genealogy is:
CSP (Hoare, 1978) -> Squeak (Cardelli & Pike, 1985) -> Newsqueak (Pike, 1989) -> Alef (Winterbottom, 1992) -> Go (Griesemer, Pike and Thompson, 2009).
Not at all.
Did anyone have experiences with ATS lang [1] as C replacement?
[1] http://www.ats-lang.org/
[1] http://www.ats-lang.org/
There's always "D as better C".
Right. For anyone who wants to get a feel for D:
https://dlang.org/ is the main site.
https://tour.dlang.org/ is the D tour site, similar to the one for Go and some other languages nowadays; you can run some D example programs right from the site, without installing the language on your machine.
On my blog, I have a handful (12-13) of exploratory D programming posts, that may also be of interest. They explore various basic but interesting features of D via some simple D command-line programs:
https://jugad2.blogspot.com/search/label/DLang
https://dlang.org/ is the main site.
https://tour.dlang.org/ is the D tour site, similar to the one for Go and some other languages nowadays; you can run some D example programs right from the site, without installing the language on your machine.
On my blog, I have a handful (12-13) of exploratory D programming posts, that may also be of interest. They explore various basic but interesting features of D via some simple D command-line programs:
https://jugad2.blogspot.com/search/label/DLang
Particularly D's stripped down "better C" mode.
C -> Zig
I like Zig, but it doesnt even have a HTTP client yet:
https://github.com/ziglang/zig/issues/2007
granted neither does C, but C has cURL, and Zig doesnt (and wont) have cURL binding:
https://github.com/ziglang/zig/issues/2056
https://github.com/ziglang/zig/issues/2007
granted neither does C, but C has cURL, and Zig doesnt (and wont) have cURL binding:
https://github.com/ziglang/zig/issues/2056
This is a misrepresentation of the facts. Zig can use libcurl just as much as C can. Unlike other languages, zig does not need bindings to use C libraries. It's one of the main features.
The issue you linked is saying tht zig standard library will not introduce a dependency on libcurl.
The issue you linked is saying tht zig standard library will not introduce a dependency on libcurl.
Andy, you are a really smart and talented person
but surely you know the difference between FFI and binding?
They are not the same thing, and Zig doesnt (and wont, according to you) have cURL binding.
but surely you know the difference between FFI and binding?
They are not the same thing, and Zig doesnt (and wont, according to you) have cURL binding.
Python, Ruby -> Go. Nim and Crystal are pet project compare to other languages, no support, no community, no libraries, Crystal doesn't even supports Windows or threads. They are in pre alpha stage at best.
I found Nim to have a small but active and supportive community. The library ecosystem, while a little thin, has a lot of activity, and I was able to find what I needed or create wrappers for C libraries.
One difference between the Swift and Nim communities is that where Swift's is full of noobs answering each other's questions, Nim's is full of experts who are just as eager to help.
Nim also has pretty good, fairly complete docs and a decent book.
One difference between the Swift and Nim communities is that where Swift's is full of noobs answering each other's questions, Nim's is full of experts who are just as eager to help.
Nim also has pretty good, fairly complete docs and a decent book.
> no support, no community, no libraries
That's grossly incorrect about Nim. I'm a C/C++ noob and I've found a lot of C/C++/Nim/CS experts answering my questions and helping me out on Nim IRC/Gitter/Nim Forums.
Recent (as recent as few hours ago) proof: https://forum.nim-lang.org/t/4912
That's grossly incorrect about Nim. I'm a C/C++ noob and I've found a lot of C/C++/Nim/CS experts answering my questions and helping me out on Nim IRC/Gitter/Nim Forums.
Recent (as recent as few hours ago) proof: https://forum.nim-lang.org/t/4912
It's not like you can contact Google and get support for Go. The Nim community might be smaller but you still get help if you ask.
This precisely. Try getting help from the creator of Go, it's next to impossible unless you work at Google or are a core Google dev. The Nim author on the other hand is very active on IRC and the Nim forum.
hence why I said the word "future"
Right now Go ( among others ) is replacing a lot of Python / Ruby, there is no future for Nim / Crystal in that space anytime soon. Crystal will most likely die, same for Nim I don't have hope about language not backed/ created by large companies.
https://dev.to/nditada/comment/lnl
https://dev.to/nditada/comment/lnl
I'm a bit sick and tired of Google being everywhere and in everything so I'd rather invest my free time in learning a language created by highly motivated individuals than learn Go.
> I don't have hope about language not backed/ created by large companies.
This does not align very well with history. PHP started as Rasmus Lerdorf toy, That didn't prevent it to grow and support some of the biggest platforms on the web. Python was also a one-man band for a while before it gained traction.
The future in uncertain.
> I don't have hope about language not backed/ created by large companies.
This does not align very well with history. PHP started as Rasmus Lerdorf toy, That didn't prevent it to grow and support some of the biggest platforms on the web. Python was also a one-man band for a while before it gained traction.
The future in uncertain.
This world does not need more corporate-owned, corporate-driven "open" source.
PHP got traction after Zend was created ( private company ) and Python has the PSF. None of Crystal / Nim have such a structure.
I'm curious where your negativity is coming from, all of the comments you've written on this thread so far are negative.
Sorry I know I sound pretty negative, it's frustration about people pushing for languages that are clearly not ready and for some of them will never be.
You've got to realise that to a lot of people these languages are already ready. Nim coming closer to 1.0 is certainly evidence that it will soon be ready for a vast majority of users.
> None of Crystal / Nim have such a structure.
That's right. Not yet.
That's right. Not yet.
I have to agree on Crystal
issue for Windows support has been open for... 6 years
https://github.com/crystal-lang/crystal/issues/26
issue for Windows support has been open for... 6 years
https://github.com/crystal-lang/crystal/issues/26
This is what it is for me:
Objective-C -> Nim (can compile to ObjC, calls methods directly without overhead)
Python -> Nim (Nim is a super fast python that prevents typos)
Ruby -> Nim (Nim is better in every-way)
JavaScript -> Nim (compiles to plain JS (if you need talk to legacy JS libs like most people) or WASM (if you just want speed))
C/C++ -> Nim (Can compile to C++, calls methods directly without overhead)
Yeah, Nim has impressive coverage of targets. I dislike almost everything about Nim: the syntax, complexity, weird case insensitivity, documentation, community, package manager...Yet this trait alone makes Nim worth leaning for me.
Hmmm , cannot agree with you here:
syntax is great and easy to learn,
complexity crockable in a day or two,
documentation looks good and actively being worked on ,
community is very welcoming and knowledgeable,
package manager nimble is easy to use.
Have you actually tried yet ?
There's a huge effort on the documentation part recently, and the community is kind. Any specific pain points?
Don't forget that Nim can compile down to JavaScript as well :) So you can actually use Nim to create your JS frontend and your C-compiled back-end.
[deleted]
Java -> Kotlin (or even modern Java)
JavaScript -> Typescript
C# -> F# (or even modern C#)
JavaScript -> Typescript
C# -> F# (or even modern C#)
I would stick with the modern variants from Java, JavaScript and C# until the underlying platforms get rewritten in the guest languages.
why?
Guest languages introduce additional layers to debug, usually lack in tooling vs platform languages, require additional FFI considerations, their communities tend to create their own libraries and build tools to parallel platform libraries and tools, just to be more idiomatic.
Also they aren't guaranteed to be around forever.
Platform languages stay around while the platform is still relevant.
So, Kotlin is Android's Swift. Outside Android I bet that in 5 years it will be as relevant as Scala and clojure are today.
TypeScript is a wonderful language from Anders, but tsconfig.json allows to change the semantics in multiple ways and it is relatively hard to track down what changed in every release.
F# is only partially supported across all .NET deployment scenarios and VS Tooling. It was even left out of the new WinUI roadmap announced at BUILD 2019, even though .NET Core does support it.
Also they aren't guaranteed to be around forever.
Platform languages stay around while the platform is still relevant.
So, Kotlin is Android's Swift. Outside Android I bet that in 5 years it will be as relevant as Scala and clojure are today.
TypeScript is a wonderful language from Anders, but tsconfig.json allows to change the semantics in multiple ways and it is relatively hard to track down what changed in every release.
F# is only partially supported across all .NET deployment scenarios and VS Tooling. It was even left out of the new WinUI roadmap announced at BUILD 2019, even though .NET Core does support it.
Java -> Go?
Not so much in the language design inspired by sense, but I see a lot of Go being used in places that were previously Java.
K8s was originally written in Java.
Personally very happy to operate fewer Java services...
Not so much in the language design inspired by sense, but I see a lot of Go being used in places that were previously Java.
K8s was originally written in Java.
Personally very happy to operate fewer Java services...
That is a step backwards.
Java 12 -> Go aka Java 1.4
Java 12 -> Go aka Java 1.4
Don't forget Julia for Python and data science!
(Obviously also a huge generalization :))
(Obviously also a huge generalization :))
and obviously
haskell -> haskellAnd AFAIK: Clojure -> Clojure
I don't know if I'd compare Nim to Python precisely; aside from the significant whitespace, I'd say Nim's syntax is directly descended from Pascal, and Nim's philosophy appears to hew more towards TIMTOWTDI than TSBOAPOOOWTDI (although I suppose we could debate whether modern Python still adheres all that closely to the latter). As a result it might appeal more to Rubyists.
From the nim homepage:
> It combines successful concepts from mature languages like Python, Ada and Modula.
> It combines successful concepts from mature languages like Python, Ada and Modula.
Sure (and note that Modula is itself a Pascal descendant, from none other than the creator of Pascal), and although it seems true to say that Nim's significant whitespace was inspired by Python, I don't think there's much else that will be familiar to Python users. Other than "indentation-based syntax", the featured bullet points on the homepage don't describe Python features, and having used Nim lightly (a while ago, mind) my impression of it was very unlike Python. However, it's possible that I'm among a minority of people who think that significant whitespace is very nearly the least important feature of Python.
I've used Nim a bit and even read most of Dom's book (Nim in Action) and it felt pretty natural to me as someone who does most of their coding in Python. Sure it has some Modula inspired keywords, but it still feels Pythonic in a way I can't easily describe.
Rust on the other hand hurts my brain like Haskell as it is so foreign.
Rust on the other hand hurts my brain like Haskell as it is so foreign.
It isn't exactly accurate. Rust is more like c++ and Nim is more like python+c+pascal.
But yeah "The future looks good."
> The undocumented #? strongSpaces parsing mode has been removed.
I remember seeing lots of controversy over this feature a previous time Nim was posted here. Hopefully, its removal will stop people from dismissing the language outright (which would be a shame given all the things Nim has going for it).
(That being said, if people still want to embrace Wadler's Law [0], there's the hot-button topic of case/underscore insensitivity to talk about. [1])
[0] https://wiki.haskell.org/Wadler%27s_Law [1] https://github.com/nim-lang/Nim/wiki/Unofficial-FAQ#why-is-i...
I remember seeing lots of controversy over this feature a previous time Nim was posted here. Hopefully, its removal will stop people from dismissing the language outright (which would be a shame given all the things Nim has going for it).
(That being said, if people still want to embrace Wadler's Law [0], there's the hot-button topic of case/underscore insensitivity to talk about. [1])
[0] https://wiki.haskell.org/Wadler%27s_Law [1] https://github.com/nim-lang/Nim/wiki/Unofficial-FAQ#why-is-i...
It took me a minute to understand what strongSpaces meant [0] but yikes! That looks like a terrible thing! One question though, what is #? strongSpaces vs #! strongSpaces?
[0] https://nim-lang.org/0.11.0/manual.html#syntax-strong-spaces
[0] https://nim-lang.org/0.11.0/manual.html#syntax-strong-spaces
I believe that's the syntax for enabling a parsing mode. I think it just changed from #! to #? (to allow a nim bash shebang).
Obviously, the yikes is gone now. It was always an experimental feature, so IMO the fear of it was overblown, but it is a pretty scary idea for a feature.
Obviously, the yikes is gone now. It was always an experimental feature, so IMO the fear of it was overblown, but it is a pretty scary idea for a feature.
well, these two things (strongSpaces couldn't have been "undocumented": i knew about it from a cursory glance at the language a few years ago, never wrote more than a hello world in it) made me shy away from the language. i mean, it's niche and all, that does not help, but those two things did decide which way the scales went.
re [0]: whether FUBAR and f_u_b_a_r mean the same thing or not is a matter of semantics, not syntax (it's in the name: "meaning").
re [1]: i use zsh where setopt errexit and setopt e_rR_EX_it mean the same thing, and it's really annoying. all it does is complicate search in man pages and code, i'd say this feature has negative value. e_rR_EX_it is extreme, but consider that zshoptions(1) documents ERR_EXIT while bash(1) lists errexit. i never know which to search for, and i end up mixing various spellings in zsh code. now shell options are a tiny slice of my shell scripts, but doing this for all identifiers? ugh!
i think the arguments in [1] are weak, unsubstantiated, and admissions of negative value.
re [0]: whether FUBAR and f_u_b_a_r mean the same thing or not is a matter of semantics, not syntax (it's in the name: "meaning").
re [1]: i use zsh where setopt errexit and setopt e_rR_EX_it mean the same thing, and it's really annoying. all it does is complicate search in man pages and code, i'd say this feature has negative value. e_rR_EX_it is extreme, but consider that zshoptions(1) documents ERR_EXIT while bash(1) lists errexit. i never know which to search for, and i end up mixing various spellings in zsh code. now shell options are a tiny slice of my shell scripts, but doing this for all identifiers? ugh!
i think the arguments in [1] are weak, unsubstantiated, and admissions of negative value.
Haven't tried it myself, but have read about nimgrep in previous HN nim threads. Just checked:
https://nim-lang.org/docs/nimgrep.html
Excerpt:
Nimgrep is a command line tool for search&replace tasks. It can search for regex or peg patterns and can search whole directories at once. User confirmation for every single replace operation can be requested. Nimgrep has particularly good support for Nim's eccentric style insensitivity. Apart from that it is a generic text manipulation tool.
https://nim-lang.org/docs/nimgrep.html
Excerpt:
Nimgrep is a command line tool for search&replace tasks. It can search for regex or peg patterns and can search whole directories at once. User confirmation for every single replace operation can be requested. Nimgrep has particularly good support for Nim's eccentric style insensitivity. Apart from that it is a generic text manipulation tool.
> but consider that zshoptions(1) documents ERR_EXIT while bash(1) lists errexit. i never know which to search for, and i end up mixing various spellings in zsh code. now shell options are a tiny slice of my shell scripts, but doing this for all identifiers? ugh!
It sounds to me like this is a problem with your search tool, if it would search in a style insensitive manner then this wouldn't be a problem, you'd find both.
It sounds to me like this is a problem with your search tool, if it would search in a style insensitive manner then this wouldn't be a problem, you'd find both.
it would have to ignore underscores as well. does your grep have that functionality bundled under a convenient flag? does your browser's ctrl-f have it for eg. github?
It doesn't. But it should, just because the limitation is the tooling doesn't mean we should give up on this. Instead we should assume that the tooling will evolve. Even if the language is not style insensitive, this kind of search is still useful since you often are not sure what convention was used.
I'm excited/hopeful about Nim's prospects. The list of "high level languages with garbage collection and exceptions that compile down to an efficient native binary" is very small.
OT: I am huge fan of whitespace-sensitive languages.[0] This is alone a reason why I wish nim all the best for its future!
[0] If a language is not whitespace-sensitive I prefer curly brackets as block markers.
[0] If a language is not whitespace-sensitive I prefer curly brackets as block markers.
Shields up!
It's impressive. 1000 commits! Great job Nim team!
Last I heard, nim was planning on removing the garbage collector and replacing it with a lifetime system, but I don't see anything about that in the release notes. Does that mean that 1.0 of nim will include a garbage collector?
Links for anybody who doesn't know what is being talked about here, https://github.com/nim-lang/Nim/wiki/Destructors,-2nd-editio... and https://github.com/nim-lang/RFCs/issues/144 describes the specification for those changes.
The plan AFAIK is to ship it with v1 but it would not be default and you would need to do `--newruntime` for using these features. As they stabilize over time and things get ported to this new runtime, it would be made the default.
The plan AFAIK is to ship it with v1 but it would not be default and you would need to do `--newruntime` for using these features. As they stabilize over time and things get ported to this new runtime, it would be made the default.
I usually use lua to script my C apps (games, embedded projects), but I might give nim a go for my next project.
What's the current async/await story on Nim? I'm considering it for a new project.
The story is that it's used in production and works quite well (but I am pretty biased as I developed most of it). If you want some examples take a look at my book[1] which includes a whole chapter where you build a chat app using Nim's async/await. The code for this is freely available[2].
1 - https://book.picheta.me/
2 - https://github.com/dom96/nim-in-action-code
1 - https://book.picheta.me/
2 - https://github.com/dom96/nim-in-action-code
https://github.com/dom96/nim-in-action-code/blob/master/Chap...
Does the linked line imply that a slow client will block the rest of the clients from receiving new messages?
Does the linked line imply that a slow client will block the rest of the clients from receiving new messages?
Yes. Ideally this should have a time out on it, but this is an edge case :)
Great! Congratulations!
I’ve been bitten by Python in this area a few times and I was looking for a statically typed alternative for a while. Nim seems to fit the bill.
The obvious choice would be Go, but the learning curve for my mostly Python-based shop seems higher and Nim looks cooler :)
I’ve been bitten by Python in this area a few times and I was looking for a statically typed alternative for a while. Nim seems to fit the bill.
The obvious choice would be Go, but the learning curve for my mostly Python-based shop seems higher and Nim looks cooler :)
Thanks! Be sure to get in touch if you run into any trouble[1] :)
1 - https://nim-lang.org/community.html
1 - https://nim-lang.org/community.html
Kinda exciting and sad. We don't know now what we'll later regret having committed to.
Once NIM is stable it will be superior to Python in every measurable way. Is there any reason to stay with Python for new projects that don't depend on a particular Python library?
Availability of packages, tooling, established best practices and skilled developers is just as important as the language itself.
Unfortunately that can be somewhat of a chicken and egg problem for new languages.
Unfortunately that can be somewhat of a chicken and egg problem for new languages.
When talking about programming languages, technically superiority is not correlated with popularity. Using Python means that if in the future I need to do data analysis I can use pandas, matplotlib, etc. If I need a web framework I could use Django, Flask, etc. NIM needs more packages in order to be considered.
The main reason people prefer python is because of the vast ecosystem. Hopefully Nim will reach there someday.
Anyways for a lot of things Nim is pretty good actually and I would recommend people to atleast try it.
Anyways for a lot of things Nim is pretty good actually and I would recommend people to atleast try it.
Superior? You mean a language without community or ecosystem and pretty much not used by anyone.
It seems to me that the benefits of Nim over Python are far smaller than the benefits of Python's library ecosystem.
I'm pretty happy with Python though. It seems like Nim's benefits couldn't be that big. I consider Python "great", so the best Nim could be is "great-er", as a core language I mean. I've been rooting for Nim, but haven't actually tried it. And my use case is pretty small, I admit.
I'm pretty happy with Python though. It seems like Nim's benefits couldn't be that big. I consider Python "great", so the best Nim could be is "great-er", as a core language I mean. I've been rooting for Nim, but haven't actually tried it. And my use case is pretty small, I admit.
The benefits of Nim over Python are not at the ecosystem level yet, it is at the language level. Nim is not exactly related to Python as TypeScript is to JS.
Nim provides a lot of features like compile-time execution, macros, c/c++/js/obj-c interop, upcoming newruntime, dependency free executable, better performance and lower memory overhead in general (obviously people can write bad code), etc.
So if any of these features matter to you, you should give it a try.
Nim provides a lot of features like compile-time execution, macros, c/c++/js/obj-c interop, upcoming newruntime, dependency free executable, better performance and lower memory overhead in general (obviously people can write bad code), etc.
So if any of these features matter to you, you should give it a try.
Python has a huge ecosystem of great libraries and is stable right now, no "once" required. In Python you can also write performance critical code in C as the standard library often does.
> In Python you can also write performance critical code in C as the standard library often does.
As a sloth I can become a horse to run fast.
I like Python, but let's not take an obvious weakness and try to present it as a strength. In the modern programming language landscape where you can get expressive and fast, Python is still slow.
As a sloth I can become a horse to run fast.
I like Python, but let's not take an obvious weakness and try to present it as a strength. In the modern programming language landscape where you can get expressive and fast, Python is still slow.
Does Nim have some sort of interop that lets it call into Python packages, so it can take advantage of that huge ecosystem?
I don’t get how anybody is claiming that Nim is at all comparable to Python. A nice syntax is like.... 1/10th the battle when you’re writing big projects.
I don’t get how anybody is claiming that Nim is at all comparable to Python. A nice syntax is like.... 1/10th the battle when you’re writing big projects.
There is https://github.com/yglukhov/nimpy
There are/were others too IIRC.
You embed Python in Nim or build Nim as a Python extension.
I actually think it is a strength or really being able to use Cython to compile Python into C/C++ is the strength. There aren't too many scripting languages where I can do very little work/setup to get C-like performance, and I can still use Python and its huge ecosystem. Nim looks interesting because it provides a simple, concise scripting language like Python but makes compiling to C/C++ dead simple. Nim is just missing that ecosystem.
Huge ecosystem also have issues. Your are tempted to use a library when a simple 100 line "replacement" that just does what you want will do.
I think the biggest problem in programming we have right now is people using libraries upon libraries not knowing how they work and drowning in complexity.
Huge ecosystems are almost like bureaucracies that eat productivity in their wake. They fool you into thinking they add value when instead they take it away.
I think the biggest problem in programming we have right now is people using libraries upon libraries not knowing how they work and drowning in complexity.
Huge ecosystems are almost like bureaucracies that eat productivity in their wake. They fool you into thinking they add value when instead they take it away.
That's... awesome. I've written a handful of little tools and scripts in Python for different (often non-technical) clients to use, but I've never found an easy way to package them up as a "click this icon to run the program" type of thing. If that's a solved problem with Nim I'm pretty much already sold.