Live data from Hacker News

A Programming Language Underdog

totallywearingpants.com

201–210 of 238 posts

Re: A Programming Language Underdog

#201

I really like Nim, but one thing that's stopped me from using it for any recent project is the lack of Protobuf and gRPC support, which we use extensively. There are some Protobuf libraries, but they're all incomplete and unmaintained. Being able to generate code from gRPC proto files (either compile-time or runtime generation) is a must.

Sounds like a perfect Nim project for you ;)

In all seriousness, I would love to write this myself... but I physically cannot pour my heart into any more Nim projects. We need more people to help us out!

Re: A Programming Language Underdog

#203
post #47

Interesting! Minus: yet another proprietary package manager, bypassing the operating system's software management subsystem (operational maintainability) Plus: finally a language which compiles to binary executable machine code. Plus: transpiles to multiple "backend" languages (but transpilers incur a performance penalty). Plus: can link with shared object libraries, thus having instantaneous integration choices with…

> Minus: yet another proprietary package manager, bypassing the operating system's software management subsystem (operational maintainability) False. Nimble installs packages only in the current user's home. It's one of the few package managers that does not encourage the dreadful "sudo pip/npm/... install"

oh, guess I shouldn't implement that[1] then :)

To be honest, now that I'm thinking about it again, I think you're totally right.

1 - https://github.com/nim-lang/nimble/issues/80

Re: A Programming Language Underdog

#204
post #16

Another interesting upcoming language ist JAI: https://inductive.no/jai/ Its purpose is to become a better C++ for game development (high performance, simplicity).

Jai is a perfect example of how fashion dictates programming language popularity. The language isn't even released yet and people are mentioning it as the next great thing. If it wasn't for Jonathan Blow's successful indie games nobody would bat an eye.

That being said, I've got huge respect for the guy. I asked him about Nim in one of his streams and his reply was very courteous and reasonable.

Re: A Programming Language Underdog

#205
post #201

I really like Nim, but one thing that's stopped me from using it for any recent project is the lack of Protobuf and gRPC support, which we use extensively. There are some Protobuf libraries, but they're all incomplete and unmaintained. Being able to generate code from gRPC proto files (either compile-time or runtime generation) is a must.

Sounds like a perfect Nim project for you ;) In all seriousness, I would love to write this myself... but I physically cannot pour my heart into any more Nim projects. We need more people to help us out!

Definitely a chicken/egg problem for nascent languages like Nim -- someone has to furnish the house before people can properly move in.

The only way I could solve this and make Nim a viable language for these projects is to spend my spare time tinkering, and that's unlikely to happen.

The situation is particularly problematic for something like gRPC where you really have to know Nim well to create a good tool.

As cool as Nim is, I've gotten to a stage in my career where I just want tools that work. That's the attraction of Go these days (though Rust is looking nearly as good now) -- most libraries already exist, and you can focus on the task at hand, instead of being forced to invent a bunch of wheels first.

Re: A Programming Language Underdog

#206

How does Nim stack up against Go? I got the impression that Nim was very performant in the concurrency/parallelism space, but I'm wondering whether the switch is worth making.

Nim has a level of richness you won't find in Go. Optional GC, unions, enums, macros, compile-time function evaluation (so code generation and other compile-time magic can happen in Nim code instead of via reflection or the rather poor "go generate"), generics, async/await, real threads... Nim has much of Go's simplicity while managing to be a lot richer. But it's also less mature and has almost zero mindshare.

Re: A Programming Language Underdog

#207
post #43

By removing the C standard lib and using a custom linker you can get the Hello World down to 150 bytes. Here is a fun read: https://hookrace.net/blog/nim-binary-size/ .

Incidentally, in Rust this kind of thing could get you 151 bytes out of Rust: http://mainisusuallyafunction.blogspot.com/2015/01/151-byte-... (linked in that post) But that was before 1.0. Updating the example and applying some more tweaks, it’s down to 145: https://github.com/tormol/tiny-rust-executable

Rust is also terribly overcomplicated and a mishmash salad of different languages, so much so that in the end, it's just simpler to call ld(1) on a .o file directly.

Re: A Programming Language Underdog

#208
post #47

Interesting! Minus: yet another proprietary package manager, bypassing the operating system's software management subsystem (operational maintainability) Plus: finally a language which compiles to binary executable machine code. Plus: transpiles to multiple "backend" languages (but transpilers incur a performance penalty). Plus: can link with shared object libraries, thus having instantaneous integration choices with…

> Minus: yet another proprietary package manager, bypassing the operating system's software management subsystem (operational maintainability) False. Nimble installs packages only in the current user's home. It's one of the few package managers that does not encourage the dreadful "sudo pip/npm/... install"

It's not false: installing any kind of software without using OS packaging, even in one's home directory makes it a hack. It's working for you in your home directory; what if it now needs to work for everyone, or if it needs to be deployed without any human interaction whatsoever?

Re: A Programming Language Underdog

#209
post #203

Earlier quoted context omitted.

> Minus: yet another proprietary package manager, bypassing the operating system's software management subsystem (operational maintainability) False. Nimble installs packages only in the current user's home. It's one of the few package managers that does not encourage the dreadful "sudo pip/npm/... install"

oh, guess I shouldn't implement that[1] then :) To be honest, now that I'm thinking about it again, I think you're totally right. 1 - https://github.com/nim-lang/nimble/issues/80

If you implement that, you instantaneously take away the ability to deploy applications through OS's automated deployment (like Kickstart, Jumpstart, or AutoYaST) and you create more work for every system engineer in existence because they have to finish your work for you, namely integration of your software (nim language) into the OS.

For every platform nim supports, native operating system package(s), delivering into /opt/nim (and system-wide configuration into /etc/opt/nim) should be provided. This is not some whim, it's a formal system engineering specification. See LSB FHS, /opt, /etc/opt and /var/opt sections, or the illumos filesystem(5) manual page for the same. (Why aren't you as a third party supposed to deliver software into /usr as you intend in that Github issue?)

If you do not do it this way, it will impede adoption because it's one thing for a developer to play around in a language and another for a system engineer to make it operational: system engineers' time is usually in extremely short supply, and if they have to package your language for you, they could easily just move on to writing software in a different language that they can mass-provision natively, and nim will stay an underdog. Operational maintainability is the end goal, means mass deployment without extra code or software like Docker, only using native subsystems. Sooner or later things must go into production.

Never bypass OS packaging. Unless you are an OS vendor, never deliver anywhere into /usr, not even /usr/local.

Re: A Programming Language Underdog

#210

Earlier quoted context omitted.

What about run-time safety? e.g. are the pointers? does it have builtin in array bounds checking? (Heck, does it even have arrays?)

yes to all of these -- Nim also has those intrinsic benefits that statically checked and compiled languages bring. Arrays? As pleasantly nimble as Python arrays to say the least. Pointers are lengthy discussion, but suffice to say that pointers are smartly handled to avoid their pitfalls at runtime (while integrating with external C if you really need to) Time time and again as I went through using Nim, what really s…

Thanks. That's very interesting. I don't suppose you're going to tell me that it has Clojure's amazing data structures too. :-)
Post reply on HN