Hacker News Reader

Comment by sephware | Hacker News Reader

Nim is fantastic, I especially like that it takes a pragmatic approach to all its features, so that it doesn't get bogged down in theory but lets you get productive with it right away. One example is that even though it says it's a systems (and application) language, it has GC (ref counting + cycle detection), which means you don't have to worry about memory management and can focus on the core of your application. Honestly I think Nim is comparable to Go, so if you're thinking of adopting Go, look into Nim, you might like what you find.

View on HN

I too was enthusiastic about using Nim, as it is clearly a much superior language to go. However, the ecosystems are not at all comparable. Even without considering the huge amount of 3rd party packages for go, the go stdlib itself is too good and has almost all batteries included. For Nim, if you are going to develop any non trivial program, it is going to be really difficult to find the relevant libraries.

I thought so too about Nim, but then I realized how easy it is to call c libs from nim. There is infinate amount of c and c++ libs out there.

Does calling C++ libs work in the latest version of Nim though? I mean real C++ interfaces, not C ones that just happen to use C++ in their implementation.

Works for me:

Wrapping a C++ header-only template library: https://github.com/status-im/nim-ttmath

Generating Cuda C++ Functor: https://github.com/mratsim/Arraymancer/blob/master/src/tenso...

Yes, and as far as I'm concerned Nim has one of the best C++ interop capabilities out of any language bar C++ itself.

I disagree. Nim is very much a batteries included language and has a very healthy range of libraries available in the set of standard libraries. The lack of of 3rd party modules is a little problematic, but the large number of standard libraries and good C FFI can help mitigate this. Go is definitely the more supported and mature language, but Nim still has a lot going for it.

i don't understand why people make these kinds of criticisms. everyone already understand that the assumption for a new language that the ecosystem won't be as rich. you're basically saying something akin to "x high school football player is much worse than y professional football player in a professional game". of course. judge them in context.

If we're using that logic, then nim is only ready for high school level applications?

>If we're using that logic, then nim is only ready for high school level applications?

i see no problem with this but i think JS is only ready for high school level applications too.

Objectively, it's very hard to say. But practically, yes. Smart people building critical systems do not run to relatively untested languages, no matter how good they may look.

But... there's a loooooot of "high school level" applications out there in the world. And the way a language graduates up to the higher classes is getting tried out in the "lower criticality" systems, and getting experience.

I wouldn't try to build an S3 competitor in Nim right now, no matter how good it may look. But even a company building an S3 competitor in some other language could still have tons of other places Nim would be a fit.

Nim generates C and compiles it using GCC. It does not inject a runtime that runs its own threads or any other magic.

All the usual static analysis tools, debuggers and even formal methods can be used on the generated C code.

> Smart people building critical systems do not run to relatively untested languages, no matter how good they may look.

Except they do, if the new untested language is qualitatively better than the old one. For example, a critical crypto algorithm in Firefox is written in F* and compiled to C: https://blog.mozilla.org/security/2017/09/13/verified-crypto... . The new implementation is formally verified free of certain classes of bugs (like buffer overflows), and significantly faster than the hand-written C implementation.

>i don't understand why people make these kinds of criticisms.

Because language age doesn't make a difference. People have to actually use the language, and this is a practical concern.

If you were choosing to put a high school football player or an NFL player on your team right now it'd be an easy choice, wouldn't it?

>People have to actually use the language, and this is a practical concern.

do they? is it in the rules of building languages and ecosystems that every new language has to be production ready from day 1? it is also possible that you can use it for hobby projects and that that's sufficient merit to talk about it and have posts about it too.

What on earth are we comparing when discussing Nim vs. other languages, if not the language itself, in practice? Are we just discussing how good you feel about it?

My point is, this is an actual deficiency that you need to consider when evaluating Nim, that isn't just a function of the language being new. For example, Zig is another option which puts any C libraries at your fingertips, without requiring bindings. If Nim had better interop (not just relatively good, but zero effort) this would no longer be a concern and you wouldn't need all of your libraries to be in Nim.

>if not the language itself, in practice?

...

>However, the ecosystems are not at all comparable.

......?

Not sure what you're getting at. People in this thread are discussing what it's like to use Nim, including its ecosystem, vs. other languages and ecosystems. You don't seem to have anything substantive to add to that other than that Nim is "new" which as I mentioned isn't relevant to the experience of actually using it.

you asked about merits of the language itself. what does the ecosystem have to do with the language /itself/

Go has a wealthy patron and a "rockstar" principal dev so it wins the popularity contest. Vue has also been playing third fiddle to the big boys for some time but people are coming around. There is no reason why Nim can't have its moment in the sun too.

Nim has been around since 2008, Go since 2009.

Go has had Google's money behind it since 2009, Nim was developed fully by volunteers since 2008.

For a while (before I found zig) I was looking for a language to do my hobby development in. Most newer languages lack a comprehensive library ecosystem, but I'm not a fan of having a giant web of dependencies anyway so one of my criteria was "how much would I dread writing my own X?". You always take a productivity hit when starting out in a language anyway, and making your own libs that interact with real code and data gives you a much better feel for how a language is going to work in the real world than more common "hello world"-like exercises do in my opinion.

> However, the ecosystems are not at all comparable.

Really?

https://github.com/VPashkov/awesome-nim

You can install Nim packages easily with nimble.

https://github.com/nim-lang/nimble

Not a fan of Go and actually like nim but https://github.com/avelino/awesome-go

Also for people actually targeting production there is hufe dif. between say DB driver that is used in literally millions of projects and has a large number of active maintainers and DB driver written by 1 dude that has not commited any fixes in 12 month

Looks impressive. However, since Nim has such an easy C/C++ FFI you have to consider also all C and C++ APIs. That looks superior even to Go, unless Go's C FFI is as easy as Nim's.

https://github.com/kozross/awesome-c

https://github.com/aleksandar-todorovic/awesome-c

https://cpp.libhunt.com/

https://github.com/fffaraz/awesome-cpp

That is true but up to a point say I want production ready async PG driver FFI does not help me much

How would you compare go and Nim? What's better and worse in each (setting aside ecosystem size)? Are there any core architectural decisions made in Nim that you would see as mistakes that will eventually drag the language down? Go and NIm kinda sorta seem to sit in a similar solution space, from the little that I've had time to really read about Nim so far. Thanks for your thoughts!

In my experience, Nim was the more enjoyable language to write.

I had initially written an application in Golang that effectively keeps our DNS records in sync with CloudFlare across ~100+ machines (A, AAAA, CNAME, etc). The application was simple enough to write in Golang but I still wasn't crazy about the error handling (if err != nil...) after every few lines, as well as the large binary size once compiled (although I understand the reason for its size).

To see if I could do better, I re-wrote the application in Nim, a language I've always had a lot of interest in. With the logic already figured out the code writing was quick and easy. I found the finished code to be cleaner and more concise and when it came time to compile I was excited to find a binary that was only 83kb in comparison to the 6mb binary of the Golang version.

Of course your miles may vary and there are many advantages/disadvantages to every language but I personally look forward to writing more Nim in the future :)

The realtime support for the GC is really fucking cool. In many game-dev situations, you would happily give up a millisecond per frame for GC deterministically instead of the GC occassionally taking 20-40 milliseconds.

Something about the phrase "it doesn't get bogged down in theory" really bothers me. What's wrong with having a good theoretical foundation?

When theoretical purity is a main goal, very often usability suffers if your problem doesn't 100% model in said theory.

[stares at haskell seductively]

In my opinion Rust suffers from this type of problem.

I actually suspect but haven't proven that I can make very memory or type 'safe' programs with Nim. I guess it goes back to practical necessity or reality for starters though. Do we need to or can we really prove that our programs are safe somehow? Is that something we generally need to the expense of everything else?

But Rust ergonomics have been getting better and in my opinion some of the Rust guarantees may put it in an elite category of languages along with Nim but for totally different reasons.

Yeah, I tried reading some code to see if I could get a grasp on Rust, but found that the language puts too much friction on the developer, when writing or reading code. The syntax ends up too dense. For gamedev particularly, I think Rust is just too much, though I can understand it's value if you're coding highly concurrent code with huge memory safety needs.

Do you have any examples?

In my experience theoretical purity is largely independent of usability, which I find is more a function of the language's expressibility and the available abstractions (and how well those abstractions play together.)

Take Elm, Haskell and Agda/Idris as examples of four programming languages with strong theoretical foundations, that also vary widely in expressibility and usability

Elm is (imho) very usable even when teaching beginners unfamiliar with the ML-style syntax. The main abstraction is parametric polymorphism (generics in oop-terms), no subtyping with inheritance and no typeclass/interface mechanism. The language has a carefully crafted culture to maintain the beginner-friendliness of the language, explicitly at the expense of expressibility (but not usability.) I personally find elm to be an incredibly usable language, specifically because it's both simple and theoretically pure. Less to understand, for more gained reliability. More practically, I often prototype completely without type signatures, relying on type inference to make sure that I'm not doing anything nonsensical. The end result (for me at least) is the speed and ease of a dynamic language, with the reliability of a statically typed language.

Haskell (without GHC extensions) offers more abstractions and is consequently "less usable" in the sense that you need to understand more theory to use things like Higher Kinded Types and whatnot. By adding GHC extensions you can gradually ramp up the expressibility (by adding abstractions,) while at the same time making the language (slightly) more difficult to use. You can get almost all the way to dependent types which brings us to..

Agda and Idris offers an incredibly powerful mechanism for abstraction called dependent types, where you essentially program your type checker as a logic. But they are (somewhat infamously) difficult to use due to having to understand the consequences of having computations at the type-level (and beyond) and consequently at compile time.

If any of those are any less pure than the other it's probably Haskell, and that's more due to the ad hoc nature of the GHC extension system, which allows you to combine extensions in problematic ways that can hide impurity.

They all compile based on some type theory as a model of computation, but those type theories can vary widely in how complex they are to understand, but the level of complexity doesn't make anything more or less pure. All of them also offers some degree of escape hatch from their "theoretical purity"-prison. Elm has its ports for js interop, Haskell has unsafeIO and friends, Agda has FFI to both js and haskell depending on backend, and I'm guessing Idris has some way of doing this as well. In this sense Elm is probably the most pure.

It's important to use a language built on strong theory, but the language shouldn't force developers to use exactly the same theory in building their own software. Developers should use the most appropriate theory for their program's problem domain; only minimal adaptations should be required for the language. Otherwise developers end up trying to work out a general theory that fits both theoretical models, which is rarely a good use of time.

Reply on news.ycombinator.com