

The Nit Programming Language - colund
http://nitlanguage.org/

======
caissy
A few of the main contributors are good friends of mine, so this post might be
biased.

One of the nicest part of Nit in my opinion is their foreign function
interface (FFI). It currently supports C and Java out of the box, and
Objective-C and C++ are being worked on. I had the chance to work with the FFI
a few years ago when it was still a student's master project, and I really had
a blast with it. Some librairies such as libcurl[1], curses[2] and sdl[3] were
implemented with this FFI.

Another great part of this language is a project being worked on by the same
guy that built the FFI, and it's a cross-compiler for mobile applications
called Gammit[4]. You write your app in Nit and compile to Java and
Objective-C natively for Android and iOS application. The iOS part isn't ready
yet, but the Android one is quite advanced with a few great examples such as a
small Minecraft clone working with Google Cardboard and having multiplayer
functionality.

[1]
[https://github.com/privat/nit/tree/master/lib/curl](https://github.com/privat/nit/tree/master/lib/curl)

[2]
[https://github.com/privat/nit/tree/master/lib/curses](https://github.com/privat/nit/tree/master/lib/curses)

[3]
[https://github.com/privat/nit/tree/master/lib/sdl2](https://github.com/privat/nit/tree/master/lib/sdl2)

[4]
[https://github.com/xymus/nit/tree/gammit](https://github.com/xymus/nit/tree/gammit)

~~~
xymus
Our Curl module is due for an overhaul. A recent example of the FFI would be
the bindings of OpenGL ES 2.0 at
[https://github.com/privat/nit/blob/master/lib/glesv2/glesv2....](https://github.com/privat/nit/blob/master/lib/glesv2/glesv2.nit)

The partial bindings to the Google Cardboard Java API may also be of interest:
[https://github.com/privat/nit/blob/master/lib/android/cardbo...](https://github.com/privat/nit/blob/master/lib/android/cardboard.nit)

------
Profpatsch
Here are my thoughts after quickly glancing over the „features“:

1\. No formatting rules and verbose „end“

I thought that by now it was universally accepted that having clear rules is a
good idea, see Python and golang)

2\. OO with inheritance

3\. multiple at that

4\. Dynamic classes/objects

5\. Methods _inside_ the classes

All of these make reasoning about effects very hard/impossible; Interfaces in
golang, Multimethods in Clojure, Typeclasses in Haskell, CLOS in CL all
provide a better solution to that.

6\. Imperative

7\. No functional elements (no functions, only methods)

Both mean inherently stateful, which in turn complicates reasoning

8\. redef & super

It’s dangerous to have behaviour of single methods spread all over your
codebase.

9\. nullable

Looks like an interesting idea to eliminate the class of NPE runtime errors,
yet it’s a special language (and syntax!) construct. It therefore does not
arise out of the type system, but is explicitely built into the type system,
so it doesn’t scale. See Haskell’s Maybe type on how to eleminate NPE’s with a
small, trivial type that is no more special than any other.

Take it or leave it, these are the things I learned in my study of programming
languages. I might be wrong, I might be right, but these are the things that
came up as bad design most often in different languages. /me out

~~~
ajuc
> I thought that by now it was universally accepted that having clear rules is
> a good idea, see Python and golang)

It is far from being generaly accepted, see Clojure, Scala, Rust, Ruby, ...
I'd say more new languages don't follow this than do. And despite general love
for Python its most controversial feature is exactly this.

~~~
_pmf_
> It is far from being generaly accepted, see Clojure, Scala, Rust, Ruby, ...
> I'd say more new languages don't follow this than do. And despite general
> love for Python its most controversial feature is exactly this.

Maybe, but the question is whether they are better off or worse off for it.

~~~
kbenson
No, actually the question was whether it's universally accepted as a good
idea. Obviously it isn't (universally accepted). No need to turn this into a
discussion of the merits, that's been done here many, _many_ times before.

~~~
Profpatsch
lel, of course everyone is going to discuss about the smallest critique I
stated. Bikeshedding at its best.

~~~
ribs
You did lead with that one.

------
kailuowang
I would appreciate if the home page provides the real incentive behind
inventing this language. "a robust statically typed programming language where
structure is not a pain" is a bit vague and not a unique thing that hasn't
been achieved by other existing languages.

My current hunch is something like "let's have a static typed language with
Ruby syntax," but I am really not sure.

~~~
infraruby
> let's have a static typed language with Ruby syntax

InfraRuby (at [http://infraruby.com/live](http://infraruby.com/live)) is a
statically typed Ruby compiler: valid InfraRuby programs are valid Ruby
programs.

~~~
Gurkenmaster
The page only mentions JVM does it also compile to native binaries?

~~~
infraruby
No. You could use a bytecode compiler (Excelsior JET or RoboVM, for example).

------
drhodes
Examples? Found some.

[https://github.com/privat/nit/tree/master/examples](https://github.com/privat/nit/tree/master/examples)

------
Tobu
[http://nitlanguage.org/manual/genericity/](http://nitlanguage.org/manual/genericity/)

> Unlike many object-oriented languages, generic classes in Nit yield a kind
> of sub-typing. For example, Pair[Int] is a subtype of Pair[Object].

Sounds completely broken. What if Pair[E] is contravariant on E?

    
    
      class Pair[E]
          fun contains(E): Bool
          fun clamp(E): Bool
      end
    

> [http://nitlanguage.org/refinement/](http://nitlanguage.org/refinement/)
> (redefining any method)

That's spooky action at a distance. It breaks modularity, could cause
packaging hell.

~~~
klibertp
Variance: I suspect it's a subject to similar restrictions as in Haxe:
[http://haxe.org/manual/type-system-
variance.html](http://haxe.org/manual/type-system-variance.html)

> That's spooky action at a distance. It breaks modularity, could cause
> packaging hell.

Swift, Ruby, Nimrod and Smalltalk are a few languages - out of many, many more
- which disagree with you here.

~~~
Tobu
Nope. In is_subtype:

> # If `sub` is a formal type, then it is accepted if its bound is accepted
> [https://github.com/privat/nit/blob/2323b17d46c873e8c6c41b75d...](https://github.com/privat/nit/blob/2323b17d46c873e8c6c41b75d0d9ad0d29b51337/src/model/model.nit#L695)

Ruby is dynamic and the interpreter is feature-rich. People are just
exercising self-discipline. Nit intends to be “a robust statically typed
programming language” which is very different.

Also, could you point me to the Nim feature? All I see is overloading.

~~~
klibertp
> Nope. In is_subtype [...]

Oh, ok. So it does look a bit broken then :)

> Also, could you point me to the Nim feature?

That follows from the fact that `something.method()` is just a syntactic sugar
for `method(something)` and that you can write methods for any type anywhere.
The example I specifically had in mind was strutils module, which extends a
string type with many useful methods.

Now that I think about it I'm not sure how Nim would handle two methods of the
same name for the same type defined in different places. I think it would
refuse to compile such code? But that's a guess only, I'd need to check.

EDIT: oh, and I see you complained about redefinition specifically, not about
the ability to extend classes in general. Sorry, I somehow missed it.

------
yoanizer
It is going to take a lot to convince me that the world needs yet another
statically typed OO programming language that looks just like any other.

------
shinta42
too many languages to learn...

elixir, nim, golang, clojure, haskell, elm, rust......there is no end...

~~~
pestaa
Do you happen to speak German, Japanese, Mandarin, Spanish and French?

You don't need to learn all the programming languages, either.

Get a glimpse of a few to discover new ways of thinking, but specialize in a
handful only.

~~~
klibertp
That's utterly wrong comparison! Overall complexity of natural languages is
probably HUNDREDS times the one of programming languages. Excluding C++,
maybe. And also, with time you begin to be much more efficient in learning
languages (that's true for natural languages too!), when it makes no sense
really _not to_ learn new languages.

That being said you don't really need more than a handful languages (selected
for their adherence to various paradigms, as my sibling suggest) if you're not
interested in inventing your own language.

------
asterite
Looks nice. Some ideas are very similar to those of Crystal ( [http://crystal-
lang.org](http://crystal-lang.org) ) like the automatic type flow. But it
seems not to support union types and types are required everywhere (which some
might like).

~~~
tachyonbeam
I tried Crystal a while back, found it quite addictive.

 _chuckles_

------
dogpa
I like that I can start hacking right away after reading the 'not a manual'
once.

I don't like the 'do' \- it's either redundant or inconsistent. Why does
'while' get a 'do' but 'if' doesn't?

Or the 'end', especially as it could be a 'while-end' or an 'if-end'.

And 'isa' (what was wrong with 'is')? Blech!

I like that 'var' is an attribute and the 'fun' is a method.

Android support is intriguing.

Maybe this seems like small things and I don't know about what the rest of you
are talking about. 'contravariant'? huh?

But it looks cool to me and I don't think you can ever have too many cool
things.

~~~
klibertp
[http://en.wikipedia.org/wiki/Covariance_and_contravariance_(...](http://en.wikipedia.org/wiki/Covariance_and_contravariance_\(computer_science\))

------
rurban

        for i in [0..width[ do
            for j in [0..height[ do
                if foo(i, j) then break label outer_loop
                # The 'break' breaks the 'for i' loop
            end
        end label outer_loop
    

ouch. I see why mathematicians would like that, but programmers are surely
annoyed by the open range "[". And if the target are mathematicians, they
surely dont like the verbose do end blocks, instead of {}.

the for loop could be then

    
    
        ∀ x in [0..height[:
            if foo(i, j): break outer_loop.
    

just odd syntax choices.

------
nickknw
Glad to see another language that has chosen to avoid NullPointerExceptions.
Some of you might take issue with the way it is implemented (special syntax vs
general type), but IMO it is still much better than having NPEs.

------
gnuvince
I was in a class last year, and one of the grad students was working on Nit
and gave us a presentation of the language. It was extremely interesting and
seemed quite well designed.

~~~
jp-m
As Ph.D student I have had the fortune to work with people who participated in
seminal research on elements of the language, and also have met the author in
person. These people are truly brilliant and the learning experience has been
great.

------
zak_mc_kracken
The documentation in one big PDF:

[http://nitlanguage.org/manual/nitreference.pdf](http://nitlanguage.org/manual/nitreference.pdf)

------
kornakiewicz
Altough I like the idea of writing yourself own language for learning purposes
and fun, I don't think it's anyhow better than available toolbox.

------
msravi
Anyone knows what the language's performance is like? I couldn't find any
benchmarks...

~~~
jwaldrip
Ditto, I would love to know as well.

------
VMG
seeing &lt; and &gt; html escapes here:
[http://nitlanguage.org/refinement/](http://nitlanguage.org/refinement/)

------
pekk
The sales pitch makes it sound like I can have the Java experience without the
JVM, with junk like multiple inheritance, using syntax from ALGOL.

Where is the "fun" and "painless" and "bug-free" going to come from?

------
amelius
I stopped reading at "object oriented".

~~~
klibertp
And how is this interesting to anyone other than you?

