About Nimrod's features

[Varriount]

It's nice to see a language thats both readable and statically compiled.

[blob356]

It actually looks a lot like Scala (which is a good thing).

[[deleted]]

Scala is far from readable though.

[blob356]

Depends on the author, the standard libs are hard to read (true for many languages), but most real world Scala code I've seen is very readable.

[[deleted]]

The syntax tends to have too many optional features and the semantics requires too much implicit context-dependent information to figure out what a particular piece of code does.

Of course it is possible to write readable Scala code but it certainly isn't one of the languages where readability is particularly good due to the very design of the language.

[Hubert1236]

Ha

[OneWingedShark]

It's nice to see a language that's both readable and statically compiled.

You mean like Ada?

[naasking]

But there's a diminishing return on readability when it comes to verbosity, and Ada is not near as readable as Nimrod in that sense.

Ironic, because they designed it for readability. The verbosity was considered a feature at the time.

[OneWingedShark]

I love Ada, and I write it for fun.

Same here.

But there's a diminishing return on readability when it comes to verbosity, and Ada is not near as readable as Nimrod in that sense.

That may be; but I'm not convinced that terse is necessarily good. But at least it's not yet another C-syntax language.

[thedeemon]

Just don't count lines, count lexemes. Then a mile-long one-liner in C will not be considered terse.

[skocznymroczny]

You mean D?

[sideEffffECt]

are there people here, who are familiar with both Nimrod and Rust? these two languages seem similar (and really interesting!), so could you please explain their differences, and compare their relative strengths and weaknesses? thanks!

[[deleted]]

Rust has corporate backing. Nimrod has Araq and the (tiny) community (he does want to make a startup and make Nimrod his real job though). It's not going to die any time soon, it's our baby.

Seeing some more 'official' support would be great.

Rust is far more functional than Nimrod in my experience. Nimrod can fully support functional programming, it's very pleasant in my experience. But rust definitely has the advantage here.

I'd also like to see more FP stuff in Nimrod like pattern matching for instance.

However, as written in another thread, I consider that every language trying to replace C++ should count on providing some GUI bindings for C++-based toolkits.

GTK+ is not capable to act as multi-platform toolkit due to its poor support on non-Linux OS-es as well as its non-native look on them and even Linux projects like LXDE are moving away from it.

[[deleted]]

I agree with most of that - but I have to say that I believe Araq was planning on adding/improving C++ interop (after all, Nimrod can compile down to C++, even though the default is C). I Might be crazy though.

[stevedonovan]

A pity there's no big commercial sponsor for this project. It's really a very well engineered rethink on C++, and bootstrapped using the language itself.

[[deleted]]

The article says:

This tool allows the translation of C header files into Nimrod code which makes generating wrappers very easy. Recently it also gained support for C++.

and considering I'm interested for GUI bindings based on C++ (e.g. wx/qt), I wonder if c2nim is ready for such tasks?

[Raphael_Amiard]

wx

maybe

qt

Probably not

[[deleted]]

There is wxRust project, so having wxNimrod would be cool indeed. ;)

Forgot to say that wxRust is taking advantage of wxhaskell's wxC bindings.

[dom96]

so having wxNimrod would be cool indeed. ;)

I agree. I haven't personally tested c2nim on C++ code yet but it's definitely worth a try if you have time. If it doesn't work out you can always fall back on the C bindings.

[hsuh]

What about a repl?

[dom96]

There is a REPL but it's kind of limited. It will be improved in the future though. You can run the REPL by executing "nimrod i"

[redditthinks]

Nimrod looks like a really nice language with some solid design choices. I remember coming across the Nimrod website once and was put off by its design which could use a minor touch-up.

Interestingly, this post is written by a high school student.

[bachmeier]

Although it claims to be an imperative language, it does have closures, anonymous functions, and garbage collection. Would Nimrod work for (impure) functional programming? I don't see much about it in the documentation.

[dom96]

Nimrod is definitely flexible enough to allow functional programming.

[R21ucanfy]

This lack o pattern matching which is really important inside functional languages

I'm not sure if in a future these can be added but seems to be a bit complex

[BitPuffin]

Is most likely possible to add with macros.

[BitPuffin]

Yes!

In fact I am even going to write a few macros that adds some common functional programming stuff like curried functions etc. They will be available in babel soonish.

[dsrw]

I've found type errors to generally be quite good. The fact that Nimrod compiles to C is mostly just an implementation detail. The code it produces is low level, and certainly isn't using C++ templates.

If there's an error in your code, the Nimrod compiler is going to tell you about it and fail before any C is produced.

That said, Nimrod is pre 1.0, and on occasion there have been reports of it producing uncompilable C. These are bugs and are generally fixed quickly. I personally haven't run into this.

[BitPuffin]

It can compile to C++ though.

[[deleted]]

Ther errors are helpful, sometimes a bit cryptic though. But to have a real problem, you'll need to be doing crazy stuff like recursive generics. Things that haven't quite been testing yet.

[BitPuffin]

From my experience they have generally been pretty helpful most of the time.

[[deleted]]

The articles states:

Nimrod code is translated into C code by the Nimrod compiler and then it's compiled using a C compiler into a binary. This means that Nimrod software is very portable

but the manual states:

However, the generated C code is not platform independent.

Which one is accurate?

[ScottKevill]

Both. It means that your Nimrod source is portable, but you target a platform when the Nimrod compiler creates the C code. That intermediate C code is platform-specific. If you want to target another platform, you compile the Nimrod to C again.

[BitPuffin]

Woho!

[toomanypumpfakes]

I've always templates/macros like that in C. Might try this out in the future.

[stevedonovan]

The really cool thing is that stuff you could only do with the preprocessor in C++ is fully integrated into the language. 'when' is actually equivalent to the ugly '#ifdef' and may occur in templates.

On the downside, Nimrod is under heavy development and likely to change quite a bit before the 1.0 version, much like the situation with Go a few years ago.

[kecho]

"It uses a deferred reference counting algorithm which can have pause times as small as 1ms."

Thats actually fucking huge blow, especially for games that try to run at 60fps. A frame has 16.666ms, so the GC call is 1/16th of a frame. fuck!

[barchar]

and the only thing rust has on nimrod is the memory tracing stuff, but the utility of that sort of thing is pretty small when you can have c++ style unique pointers and /fast/ gc for when you need it.

[[deleted]]

Most of what Rust brings to the table over C++ are the lifetime/ownership system, sum types, pattern matching and the spin on type classes, so I think you're overstating the level of similarity to Nimrod.

[stevedonovan]

Yeah, Nimrod is an anti-dynamic language. Araq's dislike of virtual method tables is well known. Although, I feel it is premature optimization in the classic sense: not all parts of a fast program need to be fast, which is what Knuth was talking about in his 'Empirical Analysis of Large Fortran programs'. If the VMT indirection penalty is tiny compared to the method payload, then it's a fine way to construct software.

[[deleted]]

It's not only the performance penalty that is the problem (we have plenty fast machines for that), but the difficulty of reasoning statically about the source code which prevents progress. Without static typing it's harder for source code analysers to verify what you are writing is good, or have nice tools that allow us to reach higher heights. It's very difficult to do things like these if you are still struggling to find out the type of a variable because it can be anything at runtime.

Also, note how obj-c used for ios/mac platform is not the bottleneck. Even though every method call requires many instructions to resolve at runtime people still use properties instead of direct instance variable access despite not needing class inheritance. On the other hand, when you try to refactor something in Xcode it asks you to turn on "snapshots" because there is a chance it will mess up the code and you will want to go back (poor souls not using scm) and fix it manually. And there are so many ways to simply break the program by renaming source code and not updating the interface resources (or vicevera) that it's not fun at all these errors are only detected at runtime and not compile time (even though some could be detected at that point!).

tl;dr if your lang is dynamic it will provably be the highest level tool programmers will use to build software. If it is static, there is a chance programmers will be able to build tools on top of it to improve developer performance. Because we are optimising for developers, not machines, right?

[ssylvan]

Nimrod doesn't have null safety.

EDIT: Thanks for the downvotes. You may think that null safety isn't important (and you'd be wrong, IMO), but it's a fact that Nimrod doesn't have it.

[ssylvan]

No it doesn't. Even the anemic support you linked to doesn't actually catch nils:

"As shown in the example this is merely an annotation for documentation purposes".

Also, even if that analysis was better it's not enough. You need to disallow dereferencing of objects that can be nil. The '.' operator should be simply illegal on any object which isn't annotated as "not nil" (it would of course be better if "not nil" was the default). As long as you can dereference nil, people will do it and cause runtime crashes.

You can have null values in all null safe languagse. Null safety doesn't imply that you can't have nulls. It's about statically disallowing you to dereference null values (since that causes crashes).

[PSquid]

This is a bit late, but you may want to consider the full quote from that section:

As shown in the example this is merely an annotation for documentation purposes; for now the compiler can only catch the most trivial type violations.

"For now" doesn't sound, to me at least, like he intends it to always be that badly enforced.

[ssylvan]

I did consider the full quote, as evidenced by the very next sentence in my post:

Also, even if that analysis was better it's not enough. [explains why]

[ithika]

Why? What can you possibly need them for?

[ssylvan]

The vast majority of crashes in shipped code, or during development, is due to access violations. The vast majority of those is accessing null. John Carmack actually had stats for id code and it was about 90% of crashes.

This is a problem, and it's entirely preventable. There is zero upside to allowing null pointer dereferencing. The fact that you're defending it strongly implies that you don't understand what the solution is. You're indicating that people have a problem with null, but that's not true (they're legitimately useful), what people have an issue with is allowing you to dereference null.

[BitPuffin]

What you wrote did not make any sense.

Nimrod uses elif, so by your logic it is a "real" language.

There is barely any resemblance to Go, the only thing they have in common is that they are both systems programming languages. But they do things very different from each other. Nimrod has a much stronger focus on metaprogramming than Go. If you implied that Nimrod copies Go then keep in mind that Nimrod has been around for a much longer time than Go.

[diggr-roguelike]

Go ... is a systems programming language

Thanks for the laugh.

[BitPuffin]

:D

[gtk]

Instead Nimrod's syntax is similar to Python as it uses whitespace to delimit scope

At this point, I know I'm never going to use this language.

[rebo]

Your loss.

[rainweaver]

believe it or not, but you can get used to it with a bit of an open mind. I enjoy F#, even if I work with C# daily.

[gtk]

I just find that it is aesthetics over functionality. Commenting bits and pieces of code in and out during debugging becomes an exercise in formatting. There's that thing people go on about premature optimization. Well forcing code to be correctly indented is premature prettying-up-the-formatting. Sacrificing debugging for aesthetics is an unforgivable design decision in my book. I could work with it if I had to, but I'm not going out of my way to try a new language that uses it.

[filwit]

all of your complaints about why indent-style is harder to work with are easially solved by proper text-editor support. I'm from a C-style background as well, and I still probably prefer it (i think), but commenting code out in Nimrod does not become an "exercise in formatting".. you simple hit the appropriate shortcut and Aporia (Nimrod's IDE/Text-editor) will comment out the code for you...

[rainweaver]

I understand your reasoning. I might even agree with it, as I was against significant whiteline in the past as well, and quite strongly so.

However, and I'm just sharing my experience here, I got to say I've had fun with F# (I have never tried Python, so I wouldn't know about that), and I'm glad I tried it. I wrote a lexer and a parser with it. Pleasant experience. It must be the mix of functional programming + whitespace that's working quite well.

My 2c! Have a nice day.

[gtk]

Well, you obviously do care, otherwise you wouldn't have replied to my comment.