Nim – version 1.2.6 and 1.0.8 released | Hacker News Reader

Nim – version 1.2.6 and 1.0.8 released

nim-lang.org

82 pointsdragonsh45 comments

Note: This is a month old, not sure why it was posted today - and both versions are minor bugfix versions.

The next series, Nim 1.4, is going to bring speed, size and predictability improvements as well as FFI that better matches e.g. Python's object life cycl. This is done by moving from the existing soft-real-time thread local mark-and-sweep collector (which works extremely well, but does impose some constraints) to a much smarter reference counting with optional cycle collector.

Nim is the only language I'm aware of with different yet practically replaceable garbage collection: RC, Mark & Sweep, Boehm, None, and a couple of deprecated ones. They all have pros/cons, but they all work well.

> different yet practically replaceable garbage collection: RC, Mark & Sweep, Boehm, None, and a couple of deprecated ones

The new ARC (automatic reference counting) and ORC are the most promising.

No runtime, no pauses, thread-safe, verified at compile-time.

As the OP said, these releases were put out a bit ago. The Nim team has been working hard on squashing the bugs with the new ARC/ORC garbage collector. There's still bugs with ARC/ORC particularly with async. The main reason there's a lot of bugs with ARC is that it also makes heavy usage of move semantics similar to the new C++ `std::move` which can significantly improve GC performance vs traditional reference counting alone, but takes some tuning of the standard library to work properly.

I've been eagerly following it as my company is using Nim embedded on the ESP32 -- primarily since, well, I don't care much for programming C/C++. With Nim I was able to write a JSON-RPC server in a few dozen lines and it compiles with only a few hundred kB for everything including nice error handling. My PR merged to bring experimental support for FreeRTOS/LwIP to Nim got merged into the devel branch today! If anyone wants to help out, check the Nim forums.

There are pauses indeed, hence why most RC in high performance contexts rely on background cleaning threads to avoid stop the world with deletion cascades.

I like Nim. Quickest possible description - it sits between Go and Rust. If you find Go boring or missing features, but Rust has too steep a learning curve - Nim. I found it strangely intuitive to get going with - easier than Go. With a smaller community still, there's plenty of room to contribute too.

I can second this. I was planning on making a library that wraps a few C libraries with seamless async and wanted a language that would work well in that context. Tried out Rust and really struggled to get something going, switched to Nim and had something up and running within minutes. So much easier.

But as my work continued I ran into other roadblocks: bad documentation, small community. I went back to Rust, stuck with it, and now I'm very happy using Rust. But if you're looking for something low-level that you can pick up super-quickly, Nim is awesome. And the executables are crazy small, even compared to Rust.

In my experience every language sits between Go and Rust, apart from C++.

Python is to on the other side of Go.

And C++ isn't alone: None of Lisp, APL, Forth or Prolog, to name a few, sit anywhere near the Go<->Rust spectrum.

Forth is more like the raw VM that runs your favorite interpreted high level language. Lisp is the AST that powers your favorite high level language or low level language. ;-)

No, I would say that most languages sit above Go - i.e., most languages are higher-level and have lower performance (in the general case) than Go.

Nim almost always produces faster running executables than Go in my experience, but is also higher level/more featureful. It also compiles very quickly if you use the TinyCC/tcc backend C compiler.

I never said anything about Nim. My reply was saying this:

  [ Most languages ] - [ Go ] - [ Some languages ] - [ Rust ] - [ Way fewer languages ]

In the above, languages are lower-level and higher performance (in general) as you move to the right.

That seems to capture the essence of Nim. The main goal appears to be to "seem high level" but, compile to C in way that makes it low level when you want it to be. Like the optional garbage collection, pretty simple ffi, etc. They seem to be pitching a middle ground.

I think the significant thing about putting Nim on the Go/Rust spectrum is that all 3 languages are statically typed languages, that advocate performance and compile to a single binary. So there is more to gain from comparing the 3, than say comparing Go and Rust to Ruby.

Off Topic a little, I think

Do you guys think there is in theory, the best programming language, or will this always be subjective

I started learning Julia recently, and my first impression was , scoping rules are a mess, I like Julia a lot and I think its probably one of the better languages and better communities that exist today (but oh my, scoping, what a gafe (in my opinion))

Is scoping really still a subjective issue, do we not know yet the best approach to scope variables for example?

Static typing, Dynamic Typing, Gradual typing, will this be a debate for ever

Learning languages is big investment, and having dozens of languages around is not productive, human languages are consolidating over a few, English is by far the business language of the world

Why does language design continue to be a subjective topic? its not like computers need cultures !

How is relevant to Nim, well as I said its a bit off topic, but we can always ask the question, why does Nim exist, or do we need Nim to exist

> Do you guys think there is in theory, the best programming language, or will this always be subjective

This is like asking for "what is the best music". Do you want to dance? Relax? Party? Feel Happy?

Programming languages have target audiences: people with a certain mindest and problems to solve. A Golang hacker will be disgusted by Haskell, and vice versa, yet both languages have merit and their own fan base, working in different domains.

That said, controversial opinion incoming: I think Zig is clearly better than C, but that is the only example I can think of.

> its not like computers need cultures

Languages (really all big projects) absolutely need cultures, and in practice they all have one. Cultures is how humans cooperate, as shared values, idioms and concepts make it much more effective to do so.

I think this is fairly simple answer to this question, but yes, I think it'll always be subjective.

Every language has trade offs, they prioritize certain features over others. This is naturally going to make some languages better than others for particular tasks.

Sorry, really basic answer here but I'm definitely curious what others think on this as well. Perhaps the above is my pessimist view on it :)

Use cases are different, so I don't see any way to have a general "this is best" winner.

Dynamically typed languages, for example, might always be popular with users that are highly technical, but not necessarily from a comp-sci background. Say you're a Unix admin, and have to automate a bunch of work. A strongly static typed language is going to be verbose and feel heavy to you. And you don't really care about performance, since the scripts can run in 1 second or 1 minute, and either gets the job done.

On the other side of that, if you're a developer on a largish project, a dynamically typed language might feel loose to you, complicate your unit tests, or drive hard to diagnose bugs. Or perhaps the performance trade-off isn't workable.

> Dynamically typed languages, for example, might always be popular with technical, but not comp-sci type users.

Some of the most hardcore "comp-sci" theorists I've ever encountered work only in Scheme, a dynamically typed language.

Yes, and I'm sure there are Unix admins that love statically typed languages. They were examples, and not absolutes.

> They were examples, and not absolutes.

Well, to be fair, you did use the word "always" which makes things sound... absolute.

> always be popular with users that are highly technical, but not necessarily from a comp-sci background

Always be popular. The "popular" part makes it not absolute. And I feel like the statement is true. That demographic does tend to gravitate to dynamically typed languages.

I edited the phrasing to make it more clear though. Apologies for anything that sounded overly authoritative. Just my opinion.

Sometimes they are systems problems. Static typing vs dynamic typing is a good example. The data you are dealing with may very well be dynamic in nature. You could have a strongly typed entity for dealing with it, e.g. hashset, but you really gain nothing from it being strongly typed. You still have to check for missing keys and handle the dynamic nature of it. Using a dynamically typed language where everything is a hashset saves a lot of boilerplate code and can make the code easier to read.

That's really what it's all about. Readable code. Different languages allow different levels of expression. You mention English as the business language that everyone speaks. Most programming languages can interface with C, and C has the largest ecosystem of libraries. Why don't we all just program in C? Because it's not very expressive. You used the words 'static', 'dynamic', and 'gradual' when discussing type systems. What if you couldn't use those words? What if you had to explain in painstaking detail what 'static' means because there wasn't a word for it? That's what it would be like if we all had to program in C.

Why does language design continue to be a subjective topic? its not like computers need cultures !

Computers don't use programming languages. Thats why we need interpreters and compilers.

I think programming languages will always be subjective, but I could imagine a time where programming languages are obsolete for almost all use cases.

Imagine an AI with advanced NLP, that allows you to describe to a computer what you want done in your native language. Then the "programmer" never has to worry about the implementation details, just what they want done. Basically like the audio computer interface in Star Trek TNG.

>Why does language design continue to be a subjective topic? its not like computers need cultures !

I think this is because all these 'languages' are ultimately human languages and not machine languages. What I mean to say is, at the end of the day all programming languages are abstractions of the human mind to make our life easier. Some times, a hammer makes our life easier in some situations, some times you need a fork.

A programming language is literally a tool to tell the computer to /do something/, and as the /something/ changes, so does the best tool to do that something.

> Learning languages is big investment, and having dozens of languages around is not productive, human languages are consolidating over a few, English is by far the business language of the world

Human languages are easier to aggregate, I think due to context. As long as you can get somewhat close, most people will generally be able to follow along. Programming languages generally lack that context (or more likely, intentionally ignore it to prevent unpredictable behavior).

Just as an example I could say something grammatically horrible like "Julia, he went to the store." It's got gender-mismatched pronouns, and it's a weird fragment. You probably know what I mean, though. On the other hand, a computer has no idea what to do with this:

``` she = new Julia() he.went_to_store() ```

Is `he` a mistype of `she`? Did I forget to instantiate `he`?

On the topic of the "best" programming language, I don't think it exists. There are likely always going to be particular paradigms that are better suited to tackling certain problems.

If you look at typing, in particular, that varies both by problem space and person in my opinion. Some people appreciate the nudges typing gives them; other people seem to have no trouble holding type info in their head (I am not one of them). Typing also becomes less valuable the less well-defined your types become. As a rough example, something like MongoDB probably benefits from typing less than other applications because so much of the data lacks a predefined schema.

At least so far, there also seems to be a trade off between development velocity and runtime speed. Most of the languages that are fast to write are slow to run. That I think will be eventually surmountable, though.

> Do you guys think there is in theory, the best programming language, or will this always be subjective

I think there is only best for what it was design for. We should compare the language goals with other language with similar goals.

Elixir/Erlang's goal makes it quite possibly one of the best language for concurrency.

R is the best language, so far, for statistic and researcher implementing their latest paper in. It also have FFI for C++/C so if things are too slow.

Once you start to compare a general programming language such as Python it gets a bit harder to say "best" because it seems to want to do everything. It's much easier to do a few things correct/good than it is to do a lot of things good/correct.

With this mind set, we can just be more objective and choose right language for the right task, instead of picking the one language to rule them all.

edit/update: This is before we even account for the ecosystem and software around the language.

I think because there are ever expanding use case for technology in many various domains with various people that have different needs, there will be more and more languages in the future, including more and more DSLs or no-code style language.

I myself would like a language ticks these boxes: - easy to use - fast, small - safe - easy to type and read (less finger and eye fatigue) - easy to debug - need to go low level if I need to, but most of the time let me just do whatever I want high level wise - can do any environment, embedded, backend, browser, cross platform, mobile, gui

I think I'm asking too much lol

> Learning languages is big investment, and having dozens of languages around is not productive, human languages are consolidating over a few, English is by far the business language of the world

> Why does language design continue to be a subjective topic? its not like computers need cultures !

Learning languages are a big investment, that is indeed true. But the comparison with English is flawed - human languages are very ambiguous by nature and often the meaning is inferred based on the context we use words. This is often apparent when one wants to write something unambiguous in English: for example, a document that is legally binding - because you want to make things as precise as possible. Most legal documents hence define terms and then use them with meticulous detail. Indeed writing these down is such a complex task that we have an entire profession dedicated to them - lawyers. So put in another way what the lawyer is doing is defining abstractions for that document and then using them to write the binding terms and conditions in the document.

How is this related to programming languages? Well, a similar argument would be we should all use assembly for programming since that is what the CPUs use anyway. You are not wrong, but that would mean so much wasted effort by programmers to define basic abstractions for every program they will ever write. Programming languages are nothing but abstractions for the problem you are solving. And problems programmers solve vary wildly - a OS or driver developer worries about vastly different problems than a data scientists and their languages show that. This is why computer do not need "cultures", but programmers do. A kernel level programmer worries about manual memory management, and handles raw pointers on their own. A data scientist just cares about manipulating tables and training models. How the memory is managed is an extra detail that is not relevant to the problem domain and languages like Python provide an abstraction for that (a garbage collector).

This is why it is always good to experiment with languages. Probably 1 in a 100 language will become mainstream, but what these experiments give us are a medium to see what abstractions work successfully to represent programs in different domains. This is how object-oriented programming or garbage collectors are mainstream today. As far as Nim goes, I think it is a language that allows you to ship compiled native binaries without manual memory management with lots of Python like language features. So the intended audience is for people who want to ship binaries but want to use expressive features like iterators, etc like Python provides.

> Do you guys think there is in theory, the best programming language

On the one hand, many languages seem to be adopting features from one another. Perhaps they will converge towards a single language?

However, I believe whatever they are converge to will never be the right language for all purposes.

> [Julia’s] scoping rules are a mess

If there ever is a single “language to rule them all”, it’ll have to get all the basics (like scoping) right. It always amazes me how many languages have such fundamental flaws.

I can't answer the question, but I find it exciting that we're in this age where we can have these discussions. Maybe in the future programming languages will consolidate, and people will fondly look back at these times of experimentation as a "golden age", as when Ritchie and Thompson were creating Linux, or Xerox PARC / Apple were inventing the computer mouse UX.

I'm not sure market forces would allow for that. Microsoft, Apple, Google, etc, have reasons to push their own languages. There are also some drivers for independent groups to push theirs. What would force the consolidation? If you compare to the death of RISC, the driver was the hugely lower cost of x86-64 combined with Linux finally maturing. Is there something similar here?

I think different languages are suitable for different contexts. I'm relatively well versed in both Rust and JavaScript/TypeScript. I'd never be able to get the performance I get with Rust in JavaScript. But I'd also never want to write some front-end code to interact with a DOM in Rust, it's just total overkill.

What purpose did you use Julia for? Julia was hyped like 2 years ago but right now i didn't see any new cool lib or even a blog posts and DL libs are lagging hard compared to python DL libs (torch, tf, jax etc.).

Julia was hyped, and now is used in production by several well known institutions.

https://juliacomputing.com/case-studies/

Most of those libraries are Python bindings to libraries written in Fortran, C, and C++, whereas on Julia's case many libraries are pure Julia code.

It was hyped and probably are used in even more places (in my previous work i even wrote a full Julia based parsers etc.) But still i didn't see much advantage of writing in Julia now 2 years and even maybe 1 year ago there were few (before numba and other JIT python stuff was working fine). Right now for me its just l'art pour l'ar you almost never get performance like in C/Nim/RUST and you don't even have much good libs in the community (compared to python thier main rival).

As someone who uses TF/PyTorch/JAX and numba for their day-to-day DL work, I've been watching Julia's post-hype developments in this area intently. Julia has probably the most vibrant ML ecosystem of all the non-Python languages (remind me when someone has implemented a transformers library for Arraymancer [1]), and absolutely smokes Python in certain niches (e.g. neural ODEs and more under the SciML [2] umbrella, I'd argue Python is "lagging hard" there). Numba can work for speeding up simple operations, but is rife with limitations that prevent optimizing more idiomatic Python code and is an absolute pain to debug. Likewise, trying to decipher or even catch errors from deep in the C++ bowels of most modern DL frameworks is an exercise of frustration.

Python may still be the best language for non-cutting edge deep learning, but we ought to consider whether we've overfit our algorithms to the limitations of the current system [3].

[1] https://github.com/mratsim/Arraymancer [2] https://sciml.ai/ [3] https://news.ycombinator.com/item?id=20301619

Torch is not Python, PyTorch is. Which also adds to your point. Remember SciLua and Torch? I far prefer Lua (moonscript) to Python, but I feel like Python will always win for DL. I guess Julia for DL will meet the same fate.

Regardless of future mainstream appeal, I don't think Julia will meet the same fate as Lua in the area simply because of how simple it is to create and maintain DL libraries compared to Python. Multiple dispatch, native matrix support and high performance out of the box (plus native and composable GPU operation libraries like CUDA.jl) means anyone can write their own DL library from scratch in a few thousand lines (and there are tons of those already, even if the community converged mostly into Flux, with Knet as a second option).

I know that the traditional C++ generics convention of <> is problematic during parsing but Nim’s choice of [] was a bridge too far for me. There was a post asking for better syntax on the official forums but it got closed.

Personally I think [] is genius. I don’t use typing in Python, but when I saw it done there I was delighted. If my_array[idx], why not list[int]? Not to mention the ease with which it can be implemented, overridden, etc

Can Flutter like framework developed on top of Nim ? It would be great.

AFAIK Nim can use C and C++ libs so yeah, in principle you should be able to produce a cross platform GUI.

There's a number of cross-platform GUI frameworks for Nim.

an excellent use of nim is https://nitter.net (browse twitter tracking free).

Reply on news.ycombinator.com