I missed Nim (2014)

http://goran.krampe.se/2014/10/20/i-missed-nim/

by mapleoin • 11 years ago

143 128 11 years ago

goran.krampe.se

I'm really excited to try Nim out in a project. It's been at the top of my list for a while, despite the evident rise of Elixir as the next hot new thing. Really love the Pythonish syntax and the ability to compile down to C and run as a native program.

Edit: just noticed this was posted on Oct 20th, 2014. Nim has been evolving a lot over its short lifetime and it's possible that some statements in this article are no longer pertinent.

Jach• 11 years ago

Give it a shot! I finally sat down and did it recently, porting an old simple pygame: https://github.com/Jach/dodgeball_nim_pygame_comparison I'm glad I did.

dom968• 11 years ago

Nice! I really like your analysis of Nim in the readme too. As somebody coming from Python, a REPL has been on my wishlist for Nim for a while now :)

One suggestion: you can get rid of the makefile and use `nimble build` to build instead. Take a look here for info on how to create Nimble packages: https://github.com/nim-lang/nimble#creating-packages. You should basically be able to execute `nimble init`, then add `bin = @["dodge"]` to your .nimble file.

jfb2• 11 years ago

"I ended up sifting out the 5 most interesting in my not so humble opinion - Go, Rust, Dart and Julia."

Five?

Swizec• 11 years ago

There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors.

jfb2• 11 years ago

Or else there's some new language called ''.

david-given2• 11 years ago

Now I'm going to have to link to one of my favourite sources of engineering wisdom, The Codeless Code (which deserves to be way better known than it is).

http://thecodelesscode.com/case/220

pluma2• 11 years ago

You haven't heard of and?

gokr7• 10 years ago

Ha! That's funny, noone has noticed that before you :) I wonder if I was thinking of a fifth or not...

3pt141593• 11 years ago

Nim is great. It is fast and it works everywhere that C works or JavaScript works since it transpiles to either (and then compiles if transpiling to C). It is super fucking fast (usually faster than C) and it feels like it has none of the limitations that you normally find out there.

That being said, there are a couple of issues.

1. Like Crystal, Nim still doesn't have HTTPS for its webserver, and with both, the default instructions are insecure. (Download this thing and run it in your shell, pay no attention to any MITM that can trivially root your machine).

2. The community is really pro, but the arguments are too tiring. We had a huge argument over the equivalent of Ruby's chomp. Everyone is so afraid of bloat in the standard lib (which I don't really understand, since I've never found myself wanting less string methods).

3. While the syntax is way better than Rust, Go, et al. It borrows some annoyingness from Python where it could have looked to Ruby for better guidance. For example, sort vs sorted. Sorted is the safer operation in Python. It returns a new sorted list. Now what normally happens in the real world is that programmers make the safe version first and later make the fast version. But imagine that the first version was called "sort" and it returned a new array, how are you to transition to a fast sort and a safe sorted? Error prone patching. Ruby's array.sort vs array.sort! is much better during transition, more legible, just all around better. It means less mangling around and it means that 99.9% of the time you know the method you're calling is safe if it doesn't have the bang after it.

4. There is still some instability here and there when you try to do cute things. I can't remember exactly what it was, but something along the lines of passing channels over channels segfaulted. This leaves you a little concerned about just how much abstraction you build up.

That being said, I fucking love Nim. It's so fun to write, it's super fast, it's quite legible, and you can do literally anything. It's had shared objects (dlls) since I started using it, so Ruby <-> Nim is possible and fun. It's very debugable and once it hits 1.0 and gets more mainstream use I'm sure it's going to be a really popular language.

scardine• 11 years ago

The deal breaker for me is the variable name normalization:

userName == user_name == username == uS_eR_aN_mE

It used to be totally case insensitive now it is case sensitive for the first letter. Underscores are ignored: two identifiers are considered equal if the following algorithm returns true:

    proc sameIdentifier(a, b: string): bool =
      a[0] == b[0] and
        a.replace(re"_|–", "").toLower == b.replace(re"_|–", "").toLower

For me it is a capital violation of the "principle of least astonishment".

Mikeb85• 11 years ago

Because it's such a deal breaker that you can't have "userName" and "user_name" in the same scope. This was brought up in the other thread, and it's just as silly now. Rejecting an absurd naming scheme is a feature.

3pt141593• 11 years ago

I actually love this. It makes it easy to write code in either a JS context (where you want camel case) or Ruby(ish) context. I really don't see how this is a deal breaker. It's one of the first things you learn when you start with Nim and I've never had a problem with it.

To me this is kinda akin to the people that complain about the magic in Rails or that Ruby includes so many things by default (like rand or sleep) without working on a couple of projects first. Those really aren't the problems that slow you down in Ruby and this isn't really something that is an issue in practice.

david-given2• 11 years ago

Urgh. I wish languages wouldn't do this. Things which look different should be different.

At least it's case sensitive for the first letter, which means that the traditional lowercase-for-identifiers, capitalised-for-types naming scheme works.

I've tried programming in Ada, which has case insensitive identifiers; it was deeply painful.

Edit: Plus, of course, case sensitivity is locale dependent. Are I and i the same letter? Not if you're Turkish. (Upper case i is İ; lower case I is ı.)

Yes, this matters. http://www.theinquirer.net/inquirer/news/1017243/cellphone-l...

krupan• 11 years ago

How does the garbage collection work when transpiling to c?

PeCaN• 11 years ago

Probably just has a conservative Boehm-ish GC. Their website is a bit sparse on the GC details from what I can tell, but anything else would be rather surprising.

matt_wulfeck3• 11 years ago

In my opinion, if a language really wants to compete with Go in my space (devops/infrastructure), then it absolutely _must_ have static-linked binaries. This feature has been such a huge win, and I continue to appreciate it every time I go back to something else.

As far as I can tell Nim doesn't have statically-linked and compiled binaries out-of-the-box. Even if it wins in other language-specific features, Go will continue charging on in the infra space.

kej• 11 years ago

Nim uses your C compiler to produce the final binary, so it can produce statically linked standalone programs everywhere a C compiler can (which is pretty much everywhere).

davexunit• 11 years ago

Static linking is one of the worst possible things you can do in terms of system security. When you run N applications that are all statically linked against library Foo and a 0-day drops for Foo, how does a systems administrator identify the applications that statically link against a vulnerable version of Foo and then patch it? Suddenly that sysadmin is dependent upon N upstreams to provide security fixes for a library they don't even maintain! Static linking is only feasible in the "app" world of proprietary software that gets shipped to customers without any concern for their safety.

Go is a bold step backwards in so many other ways, but this is one of the most egregious, especially since support for dynamic linking appears to be only an experimental feature.

bkeroack• 11 years ago

If you have a good CI pipeline, "patching" is all automatic.

A security bugfix just got pushed for Go 1.5. Since all my apps are dockerized based on the official golang image and are built by CI, as soon as the fix was published it was included in the next commit and pushed as part of that build. No intervention required. Similarly all dependent packages are pulled as part of the build so patches/fixes in them are automatically updated as well (note that vendoring would break this).

aidenn0• 11 years ago

I've seen security issues introduced by dynamic linking too, so I don't think this is so cut-and-dry. The huge number of package updates needed when a core library has a security vulnerability is a big downside, but having programs that actually work is the upside.

Have you looked at what steam does to eliminate any system libraries from accidentally getting linked in and breaking games? This is an example of the downsides of dynamic linking.

Lofkin2• 11 years ago

What about when Julia gets those things?

commentzorro• 11 years ago

I thought Julia was interpreted and/or ran against a required pre-installed runtime?

mwcampbell• 11 years ago

Exactly how self-contained do you want your binaries to be? Binaries built with Nim will be dynamically linked against libc, as well as any other C libraries you use (e.g. OpenSSL, PCRE), unless the Nim compiler gives you a way to pass the "-static" option to the linker. But Nim modules themselves, including the Nim standard library, are statically linked. So the resulting artifact is much more self-contained than it would be for, say, Python, Ruby, Node.js, or a JVM language.

gokr7• 10 years ago

Nothing prevents you from static linking AFAIK:

https://www.schipplock.software/p/static-linking-with-nim.ht...

Googling a bit finds more on the subject, for example to go very small:

http://hookrace.net/blog/nim-binary-size/

bluejekyll• 11 years ago

So this is an old article. I wonder if his perception of Rust has changed since it's 1.0 debut.

Rust is “C syntax” and Nim is Python-ish. Nim wins this one hands down for me.

This is always going to be a really personal choice for most people. I actually prefer all the clarity I get from the curly brackets.

Nim has Exceptions with tracking (!) and Rust has explicit error handling via the return value. Personally… that feels like a big step backwards, much like error handling in Go. Again, for me, a clear win for Nim. I know others feel differently, but that is ok :)

Rust has made a plain distinction between expected error return behavior (like parse errors) that you can recover from, and panic! which is the closest thing to exceptions. If you come from languages and code bases that suffer from huge amounts of confusion b/c of things like RuntimeExceptions vs. CheckedExceptions vs. Errors (Java) it's a blessing to have strongly typed return values that require doing something with the error case.

Though, errors in rust could be easier to work with, they are a bit painful now. It looks like there is some stuff on the road map to do just this, based on a merge I saw recently.

Rust is pushed by Mozilla, Nim is a grass root “true open source” language. Having a “backer” might be good, but I like grass root efforts since they tend to be more open and easier to participate in as a “full” member.

Mozilla is a saint for backing this effort. Love them or hate them, it's like Redhat's support of Linux. It's great that there are paychecks paying for this development.

The Rust community is really strong, and doesn't (IMO) suffer from the issues related to BDFL and has open transparent discussions around requested changes.

nextos• 11 years ago

I also prefer Nim to Rust, but I haven't done anything extensively in either.

How does Nim do in the safety area? AFAIK, Rust has e.g. regions and linear types to achieve memory safety.

pcwalton8• 11 years ago

Last I looked:

- Nim had a lot of undefined behavior. Dereferencing a null pointer, for example, led to undefined behavior because of compiling to C.

- Nim seemed to have less flexible data race prevention (though the abstract interpretation stuff that Nim does to determine disjointness of arrays could be more ergonomic than Rust's split_at_mut, albeit more complex). Data races were also more of a problem in Nim because the lack of a thread-safe GC meant that races could result in use-after-free.

- Nim was in the typical "memory safety requires a GC; opt out of GC and you lose memory safety" category of languages (reference counting being a form of GC). Rust, by contrast, retains safety even when GC is not used (which it rarely is).

This was many months ago, so it may well have changed.

dom968• 11 years ago

This forum thread might be of interest http://forum.nim-lang.org/t/1961

grayrest• 11 years ago

It looks like there is some stuff on the road map to do just this, based on a merge I saw recently.

The "Trait Based Exception Handling" RFC is in final comments:

https://github.com/rust-lang/rfcs/pull/243

kenko• 11 years ago

The comparison of Rust's errors-by-return-values to Go's is really off-base.

onetwotree2• 11 years ago

Exactly, between a powerful type system and macros like try!, you're basically rolling on the same level as Haskell and other advanced languages in Rust.

steveklabnik4• 11 years ago

Also

  >  I would however urge Rust people to add a section in their
  > documentation called “Error handling” or similar so that one
  > can find it without having to read the entire manual!

We have this today! http://doc.rust-lang.org/book/error-handling.html

gokr7• 10 years ago

That's great! :)

guelo• 11 years ago

The main complaint that "Rust is much more complicated to program in." Is still very valid. The learning curve for Rust's memory handling is steep. But this is to be expected when comparing any GC to a non-GC language. GC languages are always going to be easier for the programmer, that's the whole point of the GC. Rust's claim of being memory-safe without a GC is great but it's not an advantage if you can afford the GC.

pcwalton8• 11 years ago

I think that's a bit oversimplified. The same mechanisms that allow memory-safe manual memory management also eliminate data races without having to use a race detector. They also provide a very flexible form of const correctness, if that's your thing.

I think the cognitive overhead of Rust's memory model outweighs its benefits only if all of the following are true for your application:

1. Your application can afford the cost of GC and a runtime.

2. Your application does not use concurrency, or you are willing to tolerate data race errors, or you can eliminate all data races with a runtime race detector (due to extensive test coverage or similar).

3. The help that compiler-enforced immutability affords to your ability to reason about the code isn't important enough to you to justify the cost.

I think that there are a lot of apps that meet (1), (2), and (3), don't get me wrong. But I also think there are a good deal of apps that meet (1) but not (2) or (3), and they can benefit from Rust as well.

bsder• 11 years ago

The learning curve for Rust's memory handling is steep. But this is to be expected when comparing any GC to a non-GC language.

People forget that the learning curve for correct memory handling in C is steep.

jerf2• 11 years ago

It seems to me that the evidence is that in the 2010s, it is exceedingly difficult for a new language to break into what I call the "B-class language list" (they aren't in the Nobody Was Ever Fired For Choosing (Java/C#) set, but the languages you can use pretty much anywhere but Big Enterprise without anybody raising an eyebrow, like Python or Ruby) with some sort of serious corporate backing.

There hasn't even been much from the 200xs that has broken into that list. Looking at the Tiobe list for concreteness (yes, it may not be perfect but it isn't completely wrong, either, so close enough), you have to go to 14 to Swift to find something not from the 20th century. At 17 (Groovy) you debateably have something that wasn't pushed by a company (that's actually a complicated question), and all the way down to 21 to get to D to find the first thing that clearly comes from a single person anytime recently. (I won't go any farther because the list probably is getting to be just noise below that.)

I hypothesize that it is because we expect so much from our languages now. If you don't have a solution for serving web pages from your new language, don't even hope to make that list. But it could also be because developers are nervous about choosing something so obscure and having it just fade away when the competition that doesn't have that problem is already pretty good. Compared to 20 years ago we are spoiled for choice, so perhaps getting your head about the rest even in a niche is simply harder than it used to be. But I really don't know what it is.... but observationally, it seems to take a lot more than just "being a good language" nowadays to attain great success in the computer language area.

PS: This is the sort of thing that leads me to disagree strongly with the idea that the computer world moves quickly. When it requires more than half an average career for dominant language to shift, that's not "fast".

NhanH• 11 years ago

Clojure and Scala? I know they are backed by companies, but those companies were founded to support them (ie. the companis grew with the language).

Elixir would be joining the B-class language really soon.

jerf2• 11 years ago

Not in my B-list, no. Clojure and Scala are still going to get the "Never heard of it" from a lot of developers, and right now the developer who has heard of Elixir would be the exception, let alone being able to say "I wrote that in Elixir" to your boss with no eyebrow raises. YMMV depending on your boss, of course, but I think that's a fair characterization of the "average boss". I don't even put Go in list with Google's corporate support, since it still certainly produces eyebrow raises.

The B list mostly consists of the 1990s-style dynamic scripting languages right now; Python, Ruby, PHP, etc. There's a lot of up-and-coming alternatives but nothing leaps to mind that won't likely need to be defended.

There is, of course, no concrete definition of the B-list, so you are free to have your own; rather than arguing with me too much about what language falls where, if you want to propose a different definition for conversation, please do. It's a fun discussion, if ultimately pointless. I'd put what you mentioned in a separate C list, "the set of languages that are known about on HN and have been used for real projects but still generally need defending if you want to choose them". It's a much longer list. All the fun languages are on it. Erlang's still a C-list in my book, so first Elixir will have to pass Erlang before I'd even consider it in the B list.

chubot• 11 years ago

I think language adoption follows broader trends in the industry. In the early 90's, people were coding for desktops, so you could use C, C++, Pascal/Delphi, or Visual Basic. You had a lot of closed source languages.

The web brought us Perl, PHP, Python, Ruby, and JavaScript, which are all pretty darn similar if you squint. Java is sort of an outlier because it was commercial and free and had a lot of marketing.

Mobile phones lead to a resurgence in Objective C, and another big market for Java.

Since we're still making websites, we're still using the same languages for them. Languages naturally have a network effect that is hard to break. If you already have N modules, writing the N+1 module in the same language is the path of least resistance. And then module N+1 also makes the ecosystem more valuable.

C++ has an especially pernicious network effect, because it's so difficult to interface with it (in general). If languages were more interoperable, then this network effect could be broken.

But in practice it seems the main way to break the network effect is for a new generation of technology to come around. ALL languages are really domain-specific. And it is fantastically expensive to build a language ecosystem... so as long as the domain remains the same, the language will likely remain the same.

I think the hardest thing to break is going to be our foundations in C/C++. Mainly because every single other language is also written in C/C++ (Perl/PHP/Python/Ruby/JavaScript/Java).

An earlier special case of this is that it's easier to write an application in the same language that the operating system is written in, or a language written in that language -- which is of course always C or C++. The OS specifies its portable interface in C headers, and in C data types.

Possibly domains that will create new languages: AI, big data, distributed systems (Most things are built on top of existing languages, like Spark on Scala, Flume on Java, TensorFlow on Python, but there might be room for a first class language once we figure out what the heck we're doing!)

nostrademons• 11 years ago

Language adoption is pushed by platforms. New languages get adopted when there's a new platform that people wish to develop for, and existing languages aren't suitable for it.

That's behind Swift's rapid rise (it's being pushed as the "new official" language for iOS) and a lot of historically successful languages. BASIC was the language of the early microcomputer era. C was the language of the UNIX & Win32 era. PHP and Perl were languages of the Web 1.0 era, and Javascript, Ruby, and Python of the Web 2.0 era. Objective-C is for Mac and iOS development, and Swift is soon to replace it. C# is for .NET development. Java was pushed as the language for the web, but ultimately found adoption within the enterprise, and I think Go is headed toward a similar position.

The reason we've seen all the major languages of the past 10 years backed by large corporations is because all the major platforms are controlled by large corporations. The web was the last totally-open computing platform to see widespread adoption, and there was a large renaissance of single-developer programming languages for it. We've been in a similar position in the late 80s and early 90s, when C was completely dominant along with Windows & commercial UNIXes, and it turned out that pattern reversed itself in a few short years.

zzzcpan• 11 years ago

I don't think the platform thing is that big of a deal.

Programming languages are pushed and promoted just like everything else in the world. But there are more programmers than ever before, more languages than ever before, more platforms, more everything. And reaching out to most of the programmers becomes much harder and convincing them to use a new shiny language even more so.

If anything, we are likely to never see any new language become mainstream again. And likely to see most of the mainstream languages fade away.

dilap• 11 years ago

i don't buy it.

orgs coding in java or go or python or ruby on the backend can be coding in anything; it's not being pushed by a platform.

bazqux, the only good rss reader after the greader diaspora, is freakin' ur/web.

swift, while apple is trying mightily to support it like a first-class citizen, is really more like an adopted child, platform support wise. it's interesting because of the language, not the platform.

joshu• 11 years ago

Nitpick: the defining sites of Web 2.0 were PHP and Perl.

vorg• 11 years ago

Looking at the Tiobe list for concreteness [...] At 17 (Groovy)

No need to consider whether Groovy follows the trend or not. Tiobe gives a history of all Top 20 languages as a graph, just click on the language name in the top 20 chart. Groovy's ( http://www.tiobe.com/index.php/paperinfo/tpci/Groovy.html ) shows the most volatile movement in the rankings (e.g. it just rose from #82 to #17 in a mere 12 months), and Tiobe's comment "Scala might gain a permanent top 20 position soon" is probably a back-handed dig at the likely impermanence of Groovy's top 20 position. That language is being actively fiddled through the popularity rankings.

jswrenn• 11 years ago

Most advanced statically typed languages completely SUCK in the programmability department. Unless you are some genius of course.

Is this a common opinion? I've certainly heard the criticism that statically typed languages slow you down because you're fighting the compiler, but not that they're the only for exceptionally smart people. That's a troubling conclusion and potentially a self-fulfilling prophecy.

I'm curious how the author came to this opinion. Every "advanced" statically typed language I can think of isn't exclusively complicated type constructs; it's very much possible to write programs with simple type constraints. I wonder this opinion stems from a leak of Haskell's popular reputation.

adrusi• 11 years ago

I think the author was referring to programmability as in language extensibility. So the "geniuses" he references would be C++ template metaprogramming wizards. I don't think he was claiming that statically typed languages require you to be a genius to use.

gokr7• 10 years ago

Yeah, well, I actually meant both. One can't claim C++ is an "easy language" no matter what you are doing with it. And let's face it, most languages that are considered "easy to use" are dynamically typed. So yes, I do think it's a common opinion. And yes there are surely exceptions you can find :)

k__2• 11 years ago

Rust with Nim syntax and I'm sold!

steveklabnik4• 11 years ago

https://github.com/mystor/slag

(To expand on the README, this project was mostly made as part of as silly bet, you shouldn't actually use it)

k__2• 11 years ago

This looks awesome.

Symmetry3• 11 years ago

Rust with a more Nimish syntax would be good but what I really think I want for day to day use is Nim/Go

Nim's syntax regarding whitespace. It's easy const/let/var, if/when, and hopefully eventually proc/func distinctions. It's unified function call syntax. It's optional garbage collector. Sized arrays.

Go's handling of accessors for structures inside structures and structural typing.

But I would like to add Rust's use of '!' for macros and Python's slicing syntax.

dom968• 11 years ago

Go's handling of accessors for structures inside structures and structural typing.

Could you give an example of this?

But I would like to add Rust's use of '!' for macros and Python's slicing syntax.

Have you seen the Nim `a[x .. ^1]` syntax?

aikah• 11 years ago

It's crazy that in 2016, people are still seeking the holy grail of statically typed, memory safe, no VM programming languages that retains most of the advantages of dynamically typed languages. My point is it should be there already!

Well , I guess language design is just hard... Yet the demand exists, and it's huge no question.

Out of all of these, i still think D is the most interesting one (I like C#, I want generics ...).

I don't agree with some choices Nim made but it still look interesting. Go is way too rigid for my programming style. Yet Go set some expectations when it comes to developer experience, so it was a step in the right direction.

otabdeveloper• 11 years ago

statically typed, memory safe, no VM programming languages that retains most of the advantages of dynamically typed languages

Those requirements contradict themselves in numerous ways. As always, engineering tradeoffs are paramount.

As for "statically typed, memory safe, no VM" -- C++ fits all those perfectly. (Provided you put in the effort of learning C++. There's another tradeoff you'd need to keep in mind.)

steveklabnik4• 11 years ago

  > Those requirements contradict themselves in numerous ways

I'd be interested in hearing more about how.

Gankro2• 11 years ago

There isn't any definition of memory safe, nor any published version of C++, for which this is a true claim.

pjc50• 11 years ago

C++ is not memory-safe and cannot be coerced into being so.

You can write nice C++ in the C++14 style, but you can't turn off or ban the unsafe features. Until I can make my program fail to compile if there is a bare pointer in it (and how would that work with the standard library and system API?), it's not a memory-safe language.

amyjess• 11 years ago

Yes, of all the new-style AOT languages, Nim and D are by far and above my favorites.

Go and Rust just never appealed to me. Actually, I never liked Go for the same reasons as you...

xaduha• 11 years ago

It's crazy that in 2016, people are still seeking the holy grail of statically typed, memory safe, no VM programming languages that retains most of the advantages of dynamically typed languages.

I have my eye on Red and its system programming dialect Red/System

http://www.red-lang.org

http://static.red-lang.org/red-system-specs.html

systems• 11 years ago

my list of 5 most interesting languages would be

    * Rust
    * Perl6
    * Clojure
    * F#

z3t4• 11 years ago

I seem to disregard languages that imports to global name-space by default, because such programs tend do create spaghetti nightmare inception.

kiliancs• 11 years ago

It's interesting to see how some URLs are already invalid. For example the ones pointing to nimrod-lang.org

gokr7• 10 years ago

I will fix it, Nimrod was renamed.

Manishearth• 11 years ago

EDIT: I realized the post was written before Rust's governance was diversified (https://github.com/rust-lang/rfcs/blob/master/text/1068-rust...). Rust at that time was "Mozilla led", but this isn't really true now.

Rust is pushed by Mozilla, Nim is a grass root “true open source” language. Having a “backer” might be good, but I like grass root efforts since they tend to be more open and easier to participate in as a “full” member.
UPDATE 2014-11-08: I know both languages are open source and have communities. But it remains a fact that Rust is lead by Mozilla (I would be surprised if not) and Nim is lead by its community.

Whilst the majority (not all!) of the core team consists of Mozilla employees, the wider governance does not (http://rust-lang.org/team.html). Anyone can participate in RfCs, and IIRC people can also request to join subteam meetings (not exactly sure how this works), though the main _discussion_ is out in the open on the RfC anyway. Additionally subteam composition may grow or change over time.

Mozilla certainly is backing a large chunk of Rust development, but as time passes this is becoming less and less true as large features are being written by community members. As far as decision making is done it's pretty open now with a defined process and completely open.

So "Rust is led by Mozilla" isn't exactly true anymore. The core team isn't 100% Mozilla, and the overall governance is even less so.

robohamburger3• 11 years ago

I tried Nim last year after getting burnt out on rust beta. My impression is that it has a lot of the same issues Haxe has in that it seems to be a transpiler. The specific problem I hit was returning a list or vector particular way caused strange C++ code to get generated.

It would be cool if they redid the backend so it functions as a real compiler with llvm.

The transpiler issues + the smallish community pretty much scared me off. I am not sad I "missed it" even if it was a cool experiment.

dom968• 11 years ago

The C code generator is definitely much more mature than the C++ code generator. Sorry to hear that you had problems with it. Did you report it as an issue on Github? If not do you still have the code somewhere, I'd be more than happy to take a look and submit a bug report for you if you don't have the time.

robohamburger3• 10 years ago

Filed and probably fixed now (I hope). As the sibling mentions it sounds like there is llvm support coming/available?

It is probably superstition instilled from my compilers course but having a byte code producing compiler does tend to keep you honest.

gokr7• 10 years ago

I can however mention that with the Urhonimo project (currently dormant, but still quite cool) we had no issues with using the C++ backend. Although Andreas did make a bunch of improvements to c2nim and perhaps the Nim compiler too IIRC.

And oh, notice there actually is an LLVM backend brewing now!

robohamburger3• 10 years ago

Thats awesome. Sounds like it is time to take nim for another spin then if that is true.

Not knowing the syntax or semantics is a great way to fuzz a compiler so my guess is I was trying to do insane things. I had similar issues with the rust beta.

I missed Nim (2014)

Related Stories