Is this interesting for Android developers, i.e. would I have a good reason to consider this over Kotlin or Java?
* 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.
No, Nim is way much faster. Also the GC is optional and in-line in each thread.
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.
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, 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, a try :)
1 - https://nim-lang.org/docs/asynchttpserver.html
2 - https://github.com/dom96/jester
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... :)
Thanks for making this project.
But, not at all an answer to my question. To you, does my question about Nim seem out of line?
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?
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.
Yes, but AFAIK it's likely more appropriate for devs who already had considered NDK.
(Really, just a <noscript> saying "Hey, turn on JS for us." would be more than enough to make me happy, FWIW.)