12 ms·

I missed Nim (2014)

143 points by mapleoin 11y ago

cookiecaper 11y ago
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 11y 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 https://github.com/Jach/dodgeball_nim_pygame_comparison I'm glad I did.
  - dom96 11y 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 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.
jfb 11y ago
"I ended up sifting out the 5 most interesting in my not so humble opinion - Go, Rust, Dart and Julia." Five?
- Swizec 11y ago
  There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors.
  - jfb 11y ago
    Or else there's some new language called ''.
    - hugs 11y ago
      An excellent April Fool's Day project idea. Wait, nevermind... https://en.wikipedia.org/wiki/Whitespace_(programming_language) https://en.wikipedia.org/wiki/Whitespace_(programming_langua...
      - nickpsecurity 11y ago
        Or intellectual property protection. Their whole concept is hiding the message in the noise. (paranoid voice) "Don't read the April-related stuff! Highlight the page to see the hidden comments! The real reason they created it!"
  - david-given 11y 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 http://thecodelesscode.com/case/220
    - darkmighty 11y ago
      This is absolutely fantastic. http://thecodelesscode.com/case/128 http://thecodelesscode.com/case/128
- pluma 11y ago
  You haven't heard of and?
- gokr 11y ago
  Ha! That's funny, noone has noticed that before you :) I wonder if I was thinking of a fifth or not...
3pt14159 11y 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 11y 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".
matt_wulfeck 11y 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 11y 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 11y 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 11y 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).
bluejekyll 11y 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 11y 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.
  - pcwalton 11y 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.
jerf 11y 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 11y 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.
  - jerf 11y 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.
jswrenn 11y 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 11y 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.
  - gokr 11y 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__ 11y ago
Rust with Nim syntax and I'm sold!
- steveklabnik 11y ago
  https://github.com/mystor/slag 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__ 11y ago
    This looks awesome.
- Symmetry 11y 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.
  - dom96 11y 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?
    - Symmetry 11y ago
      It's been a while since I've used Go but I seem to recall that you can say foo.baz instead of foo.bar.baz if baz is a unique name in that struct hierarchy. Which makes choosing composition over inheritance nicer. For the structural typing thing that just means that you declare interfaces that functions can accept and any struct that can fulfill that interface does. Sort of like static duck typing but all the used methods are checked at compile time. But more generally I'm not a fan of using inheritance as a way of achieving polymorphism and I like Go's approach here more than Nim's. No, I hadn't seen the 'a[x .. ^1]' syntax. Does that mean 'The items of a from x to the second from the last'? If so I'm glad that the semantics are there but Python's syntax is still nicer.
aikah 11y 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 11y 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.)
  - steveklabnik 11y ago
    > Those requirements contradict themselves in numerous ways I'd be interested in hearing more about how.
  - Gankro 11y ago
    There isn't any definition of memory safe, nor any published version of C++, for which this is a true claim.
  - pjc50 11y 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 11y ago
systems 11y ago
my list of 5 most interesting languages would be * Rust * Perl6 * Clojure * F#
z3t4 11y ago
I seem to disregard languages that imports to global name-space by default, because such programs tend do create spaghetti nightmare inception.
kiliancs 11y ago
It's interesting to see how some URLs are already invalid. For example the ones pointing to nimrod-lang.org
- gokr 11y ago
  I will fix it, Nimrod was renamed.
robohamburger 11y 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.
- dom96 11y 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.
  - robohamburger 11y 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.
- gokr 11y 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!
  - robohamburger 11y 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.
Manishearth 11y 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-governance.md 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 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.

I missed Nim (2014)

143 points by mapleoin 11y ago

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 11y 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 https://github.com/Jach/dodgeball_nim_pygame_comparison I'm glad I did.
- dom96 11y 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 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.

jfb 11y ago

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

Swizec 11y ago
There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors.
- jfb 11y ago
  Or else there's some new language called ''.
  - hugs 11y ago
    An excellent April Fool's Day project idea. Wait, nevermind... https://en.wikipedia.org/wiki/Whitespace_(programming_language) https://en.wikipedia.org/wiki/Whitespace_(programming_langua...
    - nickpsecurity 11y ago
      Or intellectual property protection. Their whole concept is hiding the message in the noise. (paranoid voice) "Don't read the April-related stuff! Highlight the page to see the hidden comments! The real reason they created it!"
- david-given 11y 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 http://thecodelesscode.com/case/220
  - darkmighty 11y ago
    This is absolutely fantastic. http://thecodelesscode.com/case/128 http://thecodelesscode.com/case/128
pluma 11y ago
You haven't heard of and?
gokr 11y ago
Ha! That's funny, noone has noticed that before you :) I wonder if I was thinking of a fifth or not...

3pt14159 11y 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 11y 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".

matt_wulfeck 11y 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 11y 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 11y 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 11y 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).

bluejekyll 11y 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 11y 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.
- pcwalton 11y 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.

jerf 11y 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 11y 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.
- jerf 11y 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.

jswrenn 11y 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 11y 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.
- gokr 11y 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__ 11y ago

Rust with Nim syntax and I'm sold!

steveklabnik 11y ago
https://github.com/mystor/slag 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__ 11y ago
  This looks awesome.
Symmetry 11y 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.
- dom96 11y 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?
  - Symmetry 11y ago
    It's been a while since I've used Go but I seem to recall that you can say foo.baz instead of foo.bar.baz if baz is a unique name in that struct hierarchy. Which makes choosing composition over inheritance nicer. For the structural typing thing that just means that you declare interfaces that functions can accept and any struct that can fulfill that interface does. Sort of like static duck typing but all the used methods are checked at compile time. But more generally I'm not a fan of using inheritance as a way of achieving polymorphism and I like Go's approach here more than Nim's. No, I hadn't seen the 'a[x .. ^1]' syntax. Does that mean 'The items of a from x to the second from the last'? If so I'm glad that the semantics are there but Python's syntax is still nicer.

aikah 11y 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 11y 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.)
- steveklabnik 11y ago
  > Those requirements contradict themselves in numerous ways I'd be interested in hearing more about how.
- Gankro 11y ago
  There isn't any definition of memory safe, nor any published version of C++, for which this is a true claim.
- pjc50 11y 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 11y ago

systems 11y ago

my list of 5 most interesting languages would be * Rust * Perl6 * Clojure * F#

z3t4 11y ago

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

kiliancs 11y ago

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

gokr 11y ago
I will fix it, Nimrod was renamed.

robohamburger 11y 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.

dom96 11y 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.
- robohamburger 11y 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.
gokr 11y 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!
- robohamburger 11y 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.

Manishearth 11y 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-governance.md 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 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.