Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Dali – A pure-Nim indie assembler for Android dex and apk files (nim-lang.org)
86 points by akavel 8 days ago | hide | past | web | favorite | 23 comments

Fun off-topic fact: the Nim forum that this announcement is hosted on is written in Nim and completely open source, give it a go: https://github.com/nim-lang/nimforum

Wow, both the nim forum and the D forum are extremely slick and fast. They both deserve praise.

Interestingly the same seems to be true for D, another language in a somewhat similar space to Nim. https://forum.dlang.org has source code hosted at https://github.com/CyberShadow/DFeed

Another thing to note: you will not find any JavaScript in Nim's repo. That's because Nim compiles to JS, I'm actually using an SPA framework written in Nim for most of the forum.

Looking over Nim, it says it is a statically typed language, compiles to C/C++/JavaScript.

Is this interesting for Android developers, i.e. would I have a good reason to consider this over Kotlin or Java?

When I see things like Phoenix/Elixir the language makes me consider evaluating it for usage instead of React/JavaScript. But, I don't immediately see the reason I would invest in this language. What am I not seeing?

I think the following kind of sums up its appeal to me:

* Compiled language, sits in a similar kind of language category to Go where it compiles to a native binary but also has a GC, so it sits in that kind of performance ballpark

* But has generics

* A powerful AST based macro system, which gives it a kind of lisp-like meta-programmability. This means you can create DSLs and other tools which compile down to native code.

* Python-like syntax

But yeah, this is like one of the first steps that you really need to do effective development on Android. It's an impressive project, but it's not going to bring Android developers flocking from Java/Kotlin. However, it is quite cool for existing Nim developers who'd like to try targetting Android.

> but also has a GC, so it sits in that kind of performance ballpark

No, Nim is way much faster. Also the GC is optional and in-line in each thread.

Go has certain things out of the box that I think attributed to it's success:

Built-In libraries out of the box for web and other things which are useful. The out of the box web server isn't Django, but it works, and it's clear what it's doing under the hood. Also all the code is documented as well. I think if Nim could have a usable web server in the std lib (same with Rust and D) it would be a game changer. It doesn't have to be ultra fast, just good enough to be production ready (SSL and other secure things, and make setting up a static directory easy, numerous static directories).

The first thing I test when I try any language is the web frameworks, it tells me how expressive / powerful the language can be. This is why I always loved CherryPy from Python, because I can mentally map classes, objects, and methods to http routes without too much mental overhead. If I need to get crazier I can pull in a routing library as well.

> Go has certain things out of the box that I think attributed to it's success:

Yes, Google's backing. :)

> I think if Nim could have a usable web server in the std lib (same with Rust and D) it would be a game changer.

Nim does have an HTTP server in its stdlib[1], but I wouldn't go as far as to say that this is a game changer.

> The first thing I test when I try any language is the web frameworks

You should give my web framework, Jester[2], a try :)

1 - https://nim-lang.org/docs/asynchttpserver.html

2 - https://github.com/dom96/jester

I may have to, now that I'm at a new job where I only do Java, I feel like I can experiment with other languages more since I dont have to keep juggling between front-end and back-end code. Does it handle sessions and such? Also not familiar with database driver support for Nim.

Nim is interesting because it is a statically typed (with type inference) compiled language with very little "boilerplate" that compiled languages (even compiled to VM languages like Java and C#) have -- looking at Nim code you'd probably think it was an interpreted scripting language.

Project author here. I'd say on Android, AFAIK you realistically have just no other choice than Java or (very recently) Kotlin. There's also React Native, but at some point you apparently find out you still need some Java anyway. PWAs are even more limited. So, in a way, any other option is potentially interesting already just by virtue of being an alternative.

That said, as @captainbland suggested in a sibling comment, I'm not really targeting existing Android devs. If anyone, I'm targeting, basically, myself (a.k.a "scratch my itch"). Whereas this "myself" can be kinda elaborated on as a person/people who aren't Android developers, in big part because Java, and also because Android Studio. I mean, I would be OK with working in Java & Android Studio. But in my spare time, for hobby projects, I just viscerally can't bear the weight and slowness. They insta-cut my wings whenever I think of them in context of free-time hacking on some personal-use app. I explored many other weird avenues, including Yeti language, and Elm + React Native. Recently, I kinda discovered Nim, and found it an unspeakably great language for prototyping for me (in shortest words, kinda "Python + static types" extramarital love affair offspring). So, I finally thought, what the heck, let's close my eyes, and just see how far I can get (with the idea of emitting Dalvik bytecode by hand; at least a thinnest possible shim/wrapper, with some "real language" behind, either as in React Native, or via JNI). Surprisingly, it was much easier than I would hope to wish if I didn't explicitly fend off and box away any serious thought. So, that's the story :) Having achieved this, I found it a good moment for a first presentation to the world, maybe someone else would be interested too :) I would be sure interested if it were someone else who did it :)

edit: As to Nim itself, I can't put it very well in words yet. It definitely and resoundingly hits the sweet spot for prototyping for me, as of today. It's concise, Python-like readable (in my opinion), somewhat whimsical and not Go-grade serious, super close to C for FFI/wrapping (that's where I feel somewhat betrayed by Go), has static-typing without too much ceremony (Go-like, i.e. `var` instead of `Foo foo = new Foo()`), has templates and macros in case I need to up the game and reach for higher-level abstractions, compiles to small binaries (again, feel betrayed by Go). It has exceptions, which is not a net benefit in my book (I generally prefer Go's error handling robustness here), but is absolutely beneficial for prototyping (I can just focus on prototyping the happy path, and mostly ignore errors, just letting it crash). The third-party library ecosystem is kinda surprisingly not bad for a somewhat fringe (or at least non-mainstream) language. That's probably in huge part thanks to the ease of interfacing with C, and also in part because the language is actually already quite some time on the market (Wikipedia says 2008, which makes it ~1 year older than the public announcement of Go, ~2 years than rust). I personally can't say anything about how well it works for later phase/bigger projects, having zero such experience with it. You could maybe try looking at the Nim compiler sources and getting a feel of how it looks to you.

edit 2: Also, by having C & JS compilation targets, it hits two huge niches at once (and the standard library has full support for Windows, Linux & macOS). Improving the Android support feels kinda... fitting... :)

Thank you for this response, it's extremely illuminating and exactly what I was hoping for. I'm now going to spend some time playing with it; I feel the exact same way about the rough edges of Go but until now didn't have a way to put it into words.

Thanks for making this project.

Some posts on HN are meant for people who actually like to build the tools upon which future app or backend dev will build end-user software. I think this is this kind of post.

Totally fair point.

But, not at all an answer to my question. To you, does my question about Nim seem out of line?

If you're asking why you got downvoted (i didn't downvote you), i think it's because of the weird phoenix/elixir vs react/js comparison, together with wondering what nim brings to the table. It all seemed very confused, a bit like comparing apples to oranges. But that's just my opinion.

That makes sense.

I wasn't attempting to compare these technologies at all. I was suggesting that when I look at a new technology, I like to think of what's there currently and then ask what this new stack brings that I can't already do with the existing stacks. Phoenix/Elixir seems like it permits solutions that might be 10x better than the existing solutions in that space. Agree 100% that this space I'm referring to is NOT Android. I was just attempting to explain how I make a decision to spend the time to understand a new stack and why I do or don't.

Am I totally off base stating that Phoenix/Elixir is used in the same places React is?

thoughbot wrote a piece about that:


But, I'm curious why you think this is weird? Care to elaborate?

"Am I totally off base stating that Phoenix/Elixir is used in the same places React is?"

There are so many things to consider when deciding upon an architecture that the choice of going SPA + "regular" backend tech (js, php, whatever) vs something as specific as phoenix + elixir + server side rendering is really not a matter of "react" or something else.

A few questions you'll have to ask : what if you want to add a mobile GUI, will you want to keep rendering everything on the server ? How will you fetch the data ? Should the GUI (either mobile or web) work offline ? If you go mobile will you want to benefit from reusing react patterns ?

Now purely on the server side, erlang VM is highly optimized for concurrency (and not so much at pure cpu), but elixir is also a very peculiar language. How will you recruit people ? Is your team used to functional programming ? Do you have the skills to go to C programming in case you need performance ?

Then comes deployment. Will you plan on using OTP and actor-based architecture, for maximum availability ? Do you want to deploy on google cloud using kubernetes ? Heroku ? App-engine ? Each of these options have implications on your stack.

etc, etc. I could go on forever. The post you mentionned only talked about the most basic thing every single tech has been able to do for the last 30 years, aka : render a web page from a template. But that's a very very narrow consideration for picking a tech stack.

I think when they compare phoenix/elixir to react/js maybe they are incorporating LiveView into the equation, as it allows SPA like ability through a backend LiveView template.

> Is this interesting for Android developers

Yes, but AFAIK it's likely more appropriate for devs who already had considered NDK.

(Blank page with JS disabled.)


(Really, just a <noscript> saying "Hey, turn on JS for us." would be more than enough to make me happy, FWIW.)

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact