15 ms·

On Rust and Nim

133 points by _qc3o 12y ago

dodyg 12y ago
I find it amazing (for good) that Nim, a language that was made in obscurity by a handful developers managed to be compared to a high visibility language backed by many organizations and people.
- andreiursan 12y ago
  Exactly my feeling and I also feel that sometimes we underestimate the "ability and efficiency" of small teams. I start to believe that a small core team (not to read few contributors) can have a larger impact than an organization.
  - bztzt 12y ago
    certain core systems components are often developed by small teams or individuals even within large organizations. the .net GC was written/maintained by 1 dev for a long time (Patrick Dussud, later Maoni Stephens), the Windows thread scheduler was written and maintained by Dave Cutler over many releases, etc. some development efforts are just really hard to scale out.
- trwired 12y ago
  My impression is that Nim was in the right place at the right time and unintentionally piggybacked on the interest surrounding languages such as Rust and Go. This perception may be completely wrong. However, I do remember all these languages started gaining popularity within the span of several months. Before that Nim (then Nimrod) existed, but remained in obscurity.
  - vanderZwan 12y ago
    I do remember a well-timed post on reddit/r/programming about Nimrod (as it was called back then), shortly after Go's release. It contained a lot of "Go is disappointing (to put it mildly), this looks so much better"-comments about the language. The backlash against Go was pretty huge. I don't remember the guy behind Nim doing much trash-talking, which probably helped as well, especially in the long run. EDIT: fixed derailed sentence.
    - aikah 12y ago
      The problem of Go is the hypocrisy of its community when it comes to the expression problem. Obviously Go isn't expressive at all. Which make it verbose when one tries to write abstractions with it. A lot of devs just want a fast,type safe,memory safe language,that doesn't need a hungry VM to run but is expressive enough so "scripters" feel at home. Why is it so hard to get a language that does that? IDK .
      - lucian1900 12y ago
        There are actually several, of common lineage: OCaml, F#, Haskell.
        aikah 12y ago
        Doesn't F# work with .net and the CLR ?
        lucian1900 12y ago
        It does run on .NET, yes.
        mercurial 12y ago
        Yes, F# runs on the CLR.
        deleted 12y ago
        [deleted]
        kxo 12y ago
        > > expressive enough so "scripters" feel at home As much as I love all things Haskell, there is no way it fits the "scripters can use it" bill.
- logophobia 12y ago
  Rust is trying to do something far more complicated. Memory-safety enforced by the compiler is a big deal, but it remains to be seen if it's practical. I am really looking forward if rust can make it work, zero-cost memory-safety would really be something amazing to have in a language. Nim seems to be a nice, low-level, gc-ed and practical language. It doesn't do anything radical, it's pretty small and it does what's already there right. It could become big. This kinda reminds of linux vs minix. Doesn't mean it will play out the same way, but still. Rust feels a bit difficult to get into right now, but if they smooth over the impractical bits, it could become the systems language in 10 years. Nimrod feels like a faster version of python or ruby, something a lot of people would like to have.
  - moe 12y ago
    Nimrod feels like a faster version of python or ruby, something a lot of people would like to have. Hell yes! Nim really looks like it might have the potential to become the "faster Ruby" (or faster Python) that many of us are waiting for. For all the progress in academic (Rust, Haskell) and special purpose (Go, Dart) languages, a new iteration on the "general purpose workhorse" is more than overdue.
    - twic 12y ago
      I hadn't made this connection before, but now i see it put like this, i'm interested in Nim. The only language to have entered this "faster, statically typed, and generally less surprising Ruby" niche so far is Go. Other languages which are faster, safer, and saner than either Ruby or Go come with various showstopping problem: Java has too much baggage, Scala and Rust are too difficult, Clojure is too scary-looking, etc. Go, despite being fairly mediocre, it combines some concrete advantages over Ruby with a very low barrier to entry. Nim, though, looks like it should do this even better. It apparently has the same straightforwardness as Go, similar performance, but with even less verbosity, a more powerful (but not scary!) type system, and comprehensively more modern facilities. I don't know if Nim has some equivalent to Goroutines, but i think Goroutines are overblown anyway. Go isn't really all that great for concurrency, and the people i know who are using Go aren't using it for concurrency. I believe that the decisive fronts will be mindshare and tooling. I have no idea how Nim can build mindshare on the same scale as Go; i don't know if the current level of grassroots interest can grow, or if it needs a corporate backer like Google, a celebrity figurehead like Rob Pike, or some technical hook like Goroutines. Perhaps someone will build something amazing in it, and become a poster child. Tooling is clearer. Go has some simple, well-liked tooling in the box: go fmt for formatting, go vet for linting, go fix for version upgrades, and go get for dependency management. It also has a bit of a weird story around compiling and linking, but it all works in practice. For Nim to overtake Go, it will need an equally good or better story about all these things. Fortunately, this doesn't seem all that hard; the most important area is, IMHO, dependency management and building complex projects, and Go's tools are pretty poor here. go get is simple, but the lack of versioning is a huge hole. Maybe someone should just write a Gradle plugin for Nim?
- p0nce 12y ago
  Language maturity takes time. When Go and Rust went public, there were already languages in the very same niche, aiming to be a C++ replacement, and developped in the open.
  - hamstergene 12y ago
    Go and Rust had the very same self-positioning as C++ replacement, but because of different visions of what C++ is for they are now in largely unrelated niches. It is hard to imagine, for example, that someone would choose Go to rewrite Webkit, or LLVM, or any C++ math/modelling library (for other reason than proving it's possible). Just as an idea of writing website business logic in Rust would make me scratch my head.
    - steveklabnik 12y ago
      While I agree that writing backends in Rust may not be the best, Crates.io uses Rust as a backend for Ember, and it seems to be working out really well. I'm skeptical, but interested to see how it develops.
    - EugeneOZ 12y ago
      Then check out Iron.rs and Nickel.rs - web-frameworks in Rust :) Yes, Rust is more complicated language but sometimes you are ready to pay this price just to get back joy of programming. And at some point in time, bugs in runtime (because of types or memory safety or race conditions) becomes so annoying, that you are ready to be thankful to any tool which can find them on compilation, even with price of more verbose code. "Typing is not a bottleneck".
      - MetaCosm 12y ago
        "Joy" -- I feel like I spend all my time bookkeeping -- which is about the least fun thing imaginable. The guarantees keep me interested, but just barely at this point.
    - kxo 12y ago
      If Rust had asynchronous I/O this would be less of a head scratcher. Too bad that AIO and related, necessary primitives were forsaken for other priorities.
- S4M 12y ago
  I think lots of programming languages are been created, and the vast majority of them fall into obscurity, but some have nice features and grain a bit of traction, which is what is happening right now with Nim. If you forgive me the comparison, I would say that Nim is to the programming languages what Flappy Birds is to the video games: a successful product built by a talented programmer in a place where lots of people try their own - of course, the analogy is not completely right since the barrier to create a programming language is much, much higher than to create a small video game.
Fede_V 12y ago
The killer feature of Nim is its amazing syntax. If you know Python, Nim will instantly feel very, very familiar. Rust looks incredibly useful to do systems level programming, and guaranteed pointer safety without GC costs is amazing, but it takes me much longer to figure out exactly what's happening in the code.
- guelo 12y ago
  Right. Before I even read the article my thought was "Nim better be easier or what's the point of the GC".
- Tharkun 12y ago
  Surely what is or isn't amazing syntax depends entirely on your preferences and personal experiences. I can't stand the Python syntax. Significant whitespace is an instant turnoff for me. For me, figuring out Rust is a lot easier than figuring out Nim, because that's what I'm used to.
  - Ygg2 12y ago
    I second this notion. Thing I hate about Python is that it relies on invisible characters so two identically looking pieces of code aren't.
    - Demiurge 12y ago
      This is something I thought before I actually used python. In practice, two identically looking pieces of code ARE. Yes, you can mix tabs and spaces, but not in the same block. The moment there is ambiguity the interpreter errors out. So, in practice this is never a problem, your text editor should not be switching on you randomly and the official style guide strongly asks you to use 4space tabs. Simply follow the official guidelines and be able to configure your text editor, and you will never think about this again if you're actually using python.
      - Ygg2 12y ago
        > Yes, you can mix tabs and spaces, but not in the same block. Assuming of course all code contributors memorized the official style guidelines. And that they are responsive to such changes. I've had one similar change, reverted three times during my uni project, within span of days.
keyle 12y ago
I love nim. I've been using it non-stop since I've learnt the ropes. The only thing I'd wish was better results when googling for things. "nim" is just a very common word it appears. The site itself is a wealth of knowledge. I can relate to the comment of "feeling it's too big". Sadly the doco is not newbie friendly for some part (hi there, async). I've had no issues with the compiler but be sure to always use the devel branch. Things move fast in nim.
aphexairlines 12y ago
Looks like comparing apples and oranges. If Nim has a GC it would be more instructive to compare it with another garbage-collected systems language like OCaml.
- z92 12y ago
  What's wrong with comparing a GC language with non-GC language?
  - lifthrasiir 12y ago
    Wildly different goals, given that there should be some interesting reason to avoid GC nowadays.
    - twic 12y ago
      An interesting to reason to avoid GC would be a belief that you could make a usable general-purpose language without GC.
      - Ygg2 12y ago
        Or having code that's callable from another GC-ed language like Ruby/Python/etc. Two GCs dancing around each other (e.g. Python calling Nim) is a recipe ripe for problems.
    - rdtsc 12y ago
      How are they "wildly" different. I can see different but "whildly" really? GC is an implementation detail with some performance characteristics. Nim can turn its GC off. It can do a soft-realtime GC behavior where you limit its maximum time slice.
      - tomjakubowski 12y ago
        > Nim can turn its GC off. At the expense of losing memory safety.
alextgordon 12y ago
I too have suffered Rust's religiosity on the floating point issue. In Python, given an array xs = [3.1, 1.2, 4.3, 2.2], I can write xs.sort() and get [1.2, 2.2, 3.1, 4.4] In Haskell sort xs In Swift sort(&xs) In Rust you have to spew this monstrosity xs.sort_by(|a, b| a.partial_cmp(b).unwrap_or(Less)) The Rust position appears to be that sorting an array of floats is unreasonable and so you must be "punished" by not being allowed to use the built-in .sort() function.
- heinrich5991 12y ago
  What is the expected result if you have NaN in your list?
  - lclarkmichalek 12y ago
    In python at least, it's a bit funky: >>> sorted(map(float, ['1', '2', 'nan', '4', '3'])) [1.0, 2.0, nan, 3.0, 4.0] >>> sorted(map(float, ['1', '5', '2', 'nan', '4', '3'])) [1.0, 2.0, 3.0, 4.0, 5.0, nan]
    - moe 12y ago
      Ruby has it about right (imho): > [1.0,2.0,Float::NAN].sort ArgumentError: comparison of Float with Float failed
      - whyever 12y ago
        Rust's way is more flexible though: You can choose how to treat NaNs, in Ruby you have to fail.
        moe 12y ago
        in Ruby you have to fail Oh, really? ;) > [1.0,2.0,Float::NAN].sort ArgumentError: comparison of Float with Float failed > # let's make NaN sortable > Float::NAN.class.send(:define_method, '<=>') { |x| -1 } > [1.0,2.0,Float::NAN].sort => [1.0, 2.0, NaN]
shadowmint 12y ago
Pretty fair commentary. Rust certainly isn't one of those languages where you can just pick it up, play with it for a day implementing an algorithm in it to get the feel of it and learn 'the complicated stuff' later. Other languages let you get away with that quick start style; you can write a lot of python before you need to write a plugin, and a lot of c# before you start using unsafe code, etc. Rust doesn't afford you that luxury. Lifetimes, mutability and single ownership are BAM, right in your face from the start. It probably puts a few people off... but hey, you know the analogy about tools and toolboxes. Rust is for writing fast, secure, cross platform code. There's nothing else out there that offers the same; it's not a case of use Rust or Nim, or C++; rust is literally the only language that offers these features right now. You can certainly write code that happens to be secure, fast and cross platform (eg. in C++), and if you don't need those features (or dont care), you're almost certainly better off picking a different language (like Go or Nim) that are 'fast enough' and 'secure enough', and don't restrict you in the same way Rust does, or something far more productive (like python or javascript) if all you need to do is smash out a product. That's perfectly ok. We don't need a language which is everything for everyone all at the same time. Rust is very good at doing what it does; and it's the first time C++ has had a real challenger. I, for one, am really looking forward to the dynamics between the two crowds going forwards.
- pjmlp 12y ago
  > Rust is very good at doing what it does; and it's the first time C++ has had a real challenger. Ada and Modula-3 were there first, they just weren't adopted by OS vendors at large.
  - vezzy-fnord 12y ago
    Additionally, their categorizations of "fast", "secure" and "cross-platform" are far too general. I don't even think Rust officially supports that many platforms yet. It's strictly OS X/Windows/Linux, and the latter depends on glibc unless you're willing to throw away a ton of the standard library and third-party crates to start from scratch.
    - 12y ago
tmerr 12y ago
>>the whole language is verbose: compare these 10 lines (https://github.com/andreaferretti/kmeans/blob/935b8966d4fe0d4854d3d69ec0fbfb4dd69a3fd1/rust/src/point/mod.rs#L30-L39 https://github.com/andreaferretti/kmeans/blob/935b8966d4fe0d...) with this single line (https://github.com/andreaferretti/kmeans/blob/master/nim/algo.nim#L10 https://github.com/andreaferretti/kmeans/blob/master/nim/alg...) The Nim code's more concise in this case but the Rust code can be more clearly written: impl Add for Point { type Output = Point; fn add(self, other: Point) -> Point { Point(self.0 + other.0, self.1 + other.1) } } The "type Output = Point" line isn't boilerplate, it makes it possible to define the result of an addition as something other than a Point. (Off of the top of my head I can't think of any use cases, but I'm happy with the capability personally).
- Coding_Cat 12y ago
  For addition I can't either, but you could use it to overload multiplication of two (mathematical) vectors to a dot-product impl Mul for Vec2{ type Output = double; fn mul(self, other: Vec2) -> Double { self.0*other.0+self.1*other.1) } } Although I must admit I'm not (yet) sure why you need to explicitly state the output and define it for the function. But I have only just started with Rust.
  - Ygg2 12y ago
    > Although I must admit I'm not (yet) sure why you need to explicitly state the output and define it for the function. But I have only just started with Rust. I generally assume it's because it can't infer the associated type from function signature, for now.
  - sanderjd 12y ago
    A simple example for addition would be adding two u64s and getting a bignum type.
- steveklabnik 12y ago
  The last time this post appeared, I actually submitted a PR which did this, among other things: https://github.com/andreaferretti/kmeans/pull/3 https://github.com/andreaferretti/kmeans/pull/3 The post wasn't really updated.
halosghost 12y ago
Okay, so I'm having one problem with nim. Disabling all unsigned arithmetic by-default. The logic is actually fairly sound (it's probably, generally, harder to overflow a signed than an unsigned), but nim doesn't compile to object code; it transpiles to C and then C compiles to object/machine code. Edit: it's obviously much harder to overflow an unsigned than a signed; in the sentence above, I was thinking particularly of underflow (which is what the nim devs reference as their logic for disabling unsigned arithmetic by-default). The problem here is that unsigned arithmetic, though much easier to hit underflow, is fully defined in C where signed {under,over}flow is UB. As a result, if you manage to hit this case in nim, you're now going to hit UB by-default. This seems crazy to me. Am I missing something?
- def- 12y ago
  While unsigned arithmetic is not "enabled by-default", a simple `import unsigned` and you have it. If you want the language to handle overflows for you, you can enable runtime overflow checks for your whole code or any specific part of it. Otherwise, if you opt for no runtime checks and release builds with all optimizations, you indeed go into the same undefined behaviour territority as in C, so you'd have to prevent overflows before they happen.
  - halosghost 12y ago
    I understand that it is available simply; I was questioning the logic of having it disabled by-default. Having the ability to do run-time checks for {over,under}flow does seem to make this issue a little better but doesn't explain the logic of having the language prefer UB by-default. Yes, C does this too (integers are signed by-default), but if I'm shopping for a language that abstracts C, I'm probably looking for improvments over C's defaults.
arbre 12y ago
I would be curious on how Go would compare to these two on that example.
fiatjaf 12y ago
Do you create a new repository on GitHub for everything you want to write?
thechao 12y ago
> but adding a map function on Vector would have not prevented this more sophisticated use. This was questioned, long ago, by Todd Veldhuizen in his Parsimony Principle paper[1]. The long-and-short of which is: do it! [1] http://arxiv.org/abs/0707.4166 http://arxiv.org/abs/0707.4166
throawai 12y ago
Keyle [dead]: I love nim. I've been using it non-stop since I've learnt the ropes. The only thing I'd wish was better results when googling for things. "nim" is just a very common word it appears. The site itself is a wealth of knowledge. I can relate to the comment of "feeling it's too big". Sadly the doco is not newbie friendly for some part (hi there, async). I've had no issues with the compiler but be sure to always use the devel branch. Things move fast in nim. -----
- def- 12y ago
  Well, it was named "Nimrod" before, but there were other problems with that name, which prompted the rename. "Nim" was a good choice because it was the file ending already. Also, easier to google than C and Go at least. Usually "nim-lang" works fine.
- dom96 12y ago
  I'm curious why the post was deleted. Can mods shed some light on this?
  - steveklabnik 12y ago
    They are shadow banned.
    - keyle 12y ago
      What is shadow banned and why am I?
    - steveklabnik 12y ago
      keyle, you'd have to take that up with the HN adminstration, I can't help you.
- keyle 12y ago
  Why dead??
Animats 12y ago
That's a good commentary. As for Nim, do we really need another unsafe language with a part-time GC? If you can tolerate a GC, there are a lot of good language options. I have some issues with Rust's verbosity, especially in the error handling area. I recently bugged the Rust crowd into changing their overly complicated replacement for C's "argc/argv" approach to command line parameters.[1] They listened. The Rust crowd is trying hard in a difficult area and succeeding. In C and C++, lifetimes and mutability are in your face from the start. It's just that the compiler doesn't help you with them. For years, I've been saying that the three big problems with C/C++ are "How big is it? Who owns it? Who locks it?". C gives no help with any of those. C++ addresses "how big", but it's not airtight, and C++14 tries to address "Who owns it", but only for new code, and it's not airtight. Rust aggressively deals with all three problems. I can understand the unhappiness with Rust, though. It's not a comfortable language for many modern programmers, especially ones who've never done any constrained form of engineering. For them, I'd suggest Go and Python. Go can do pretty much anything you need to do on a web server, and fast. That's why Google created it. So can Python, but more slowly. Both are memory safe (well, Go isn't in multi thread mode.) Understanding the Rust mindset can be hard. That's a documentation problem. The "Rust for Dummies" book has not yet been written. The Rust tutorial glosses over the hard issues, and the Rust reference is written for people who are into language design, compiler design, and theory. Until recently the language design had so much churn that most of the Rust material on the web is out of date. In another year, there will probably be a decent Rust book. With Rust, you need a plan for who's going to own what before you start. Then you just have to explain that plan to the borrow checker. For a complex, mutable data structure, such as a DOM or a GUI's collection of interconnected widgets, this may take design work and design documents. If you plow ahead without thinking through who owns what, including in the error cases, you'll get Rust compile time errors. You would have hit trouble in C or C++ too, but it would have been in the form of a memory leak, crash, or security hole. Now you have to fix it up front. There are performance wins in this. Someone recently commented on HN that they'd discovered that typing into a dialog box produced some insane number (thousands) of allocation events per keystroke. That was partly because, at many places in the C++ code, a c_str was being copied into a fresh String object. That's a consequence of being afraid to borrow a reference to a string you don't own, for fear of creating a bug. It's safer to make a copy. In Rust, the compiler will tell you if you can do that safely. If you need to make a copy, you can, but if you just take a reference and Rust allows it, the code is good. Big step forward. [1] https://github.com/rust-lang/rust/pull/21787#issuecomment-73161760 https://github.com/rust-lang/rust/pull/21787#issuecomment-73...

133 points by _qc3o 12y ago

dodyg 12y ago

I find it amazing (for good) that Nim, a language that was made in obscurity by a handful developers managed to be compared to a high visibility language backed by many organizations and people.

andreiursan 12y ago
Exactly my feeling and I also feel that sometimes we underestimate the "ability and efficiency" of small teams. I start to believe that a small core team (not to read few contributors) can have a larger impact than an organization.
- bztzt 12y ago
  certain core systems components are often developed by small teams or individuals even within large organizations. the .net GC was written/maintained by 1 dev for a long time (Patrick Dussud, later Maoni Stephens), the Windows thread scheduler was written and maintained by Dave Cutler over many releases, etc. some development efforts are just really hard to scale out.
trwired 12y ago
My impression is that Nim was in the right place at the right time and unintentionally piggybacked on the interest surrounding languages such as Rust and Go. This perception may be completely wrong. However, I do remember all these languages started gaining popularity within the span of several months. Before that Nim (then Nimrod) existed, but remained in obscurity.
- vanderZwan 12y ago
  I do remember a well-timed post on reddit/r/programming about Nimrod (as it was called back then), shortly after Go's release. It contained a lot of "Go is disappointing (to put it mildly), this looks so much better"-comments about the language. The backlash against Go was pretty huge. I don't remember the guy behind Nim doing much trash-talking, which probably helped as well, especially in the long run. EDIT: fixed derailed sentence.
  - aikah 12y ago
    The problem of Go is the hypocrisy of its community when it comes to the expression problem. Obviously Go isn't expressive at all. Which make it verbose when one tries to write abstractions with it. A lot of devs just want a fast,type safe,memory safe language,that doesn't need a hungry VM to run but is expressive enough so "scripters" feel at home. Why is it so hard to get a language that does that? IDK .
    - lucian1900 12y ago
      There are actually several, of common lineage: OCaml, F#, Haskell.
      - aikah 12y ago
        Doesn't F# work with .net and the CLR ?
        lucian1900 12y ago
        It does run on .NET, yes.
        mercurial 12y ago
        Yes, F# runs on the CLR.
      - deleted 12y ago
        [deleted]
      - kxo 12y ago
        > > expressive enough so "scripters" feel at home As much as I love all things Haskell, there is no way it fits the "scripters can use it" bill.
logophobia 12y ago
Rust is trying to do something far more complicated. Memory-safety enforced by the compiler is a big deal, but it remains to be seen if it's practical. I am really looking forward if rust can make it work, zero-cost memory-safety would really be something amazing to have in a language. Nim seems to be a nice, low-level, gc-ed and practical language. It doesn't do anything radical, it's pretty small and it does what's already there right. It could become big. This kinda reminds of linux vs minix. Doesn't mean it will play out the same way, but still. Rust feels a bit difficult to get into right now, but if they smooth over the impractical bits, it could become the systems language in 10 years. Nimrod feels like a faster version of python or ruby, something a lot of people would like to have.
- moe 12y ago
  Nimrod feels like a faster version of python or ruby, something a lot of people would like to have. Hell yes! Nim really looks like it might have the potential to become the "faster Ruby" (or faster Python) that many of us are waiting for. For all the progress in academic (Rust, Haskell) and special purpose (Go, Dart) languages, a new iteration on the "general purpose workhorse" is more than overdue.
  - twic 12y ago
    I hadn't made this connection before, but now i see it put like this, i'm interested in Nim. The only language to have entered this "faster, statically typed, and generally less surprising Ruby" niche so far is Go. Other languages which are faster, safer, and saner than either Ruby or Go come with various showstopping problem: Java has too much baggage, Scala and Rust are too difficult, Clojure is too scary-looking, etc. Go, despite being fairly mediocre, it combines some concrete advantages over Ruby with a very low barrier to entry. Nim, though, looks like it should do this even better. It apparently has the same straightforwardness as Go, similar performance, but with even less verbosity, a more powerful (but not scary!) type system, and comprehensively more modern facilities. I don't know if Nim has some equivalent to Goroutines, but i think Goroutines are overblown anyway. Go isn't really all that great for concurrency, and the people i know who are using Go aren't using it for concurrency. I believe that the decisive fronts will be mindshare and tooling. I have no idea how Nim can build mindshare on the same scale as Go; i don't know if the current level of grassroots interest can grow, or if it needs a corporate backer like Google, a celebrity figurehead like Rob Pike, or some technical hook like Goroutines. Perhaps someone will build something amazing in it, and become a poster child. Tooling is clearer. Go has some simple, well-liked tooling in the box: go fmt for formatting, go vet for linting, go fix for version upgrades, and go get for dependency management. It also has a bit of a weird story around compiling and linking, but it all works in practice. For Nim to overtake Go, it will need an equally good or better story about all these things. Fortunately, this doesn't seem all that hard; the most important area is, IMHO, dependency management and building complex projects, and Go's tools are pretty poor here. go get is simple, but the lack of versioning is a huge hole. Maybe someone should just write a Gradle plugin for Nim?
p0nce 12y ago
Language maturity takes time. When Go and Rust went public, there were already languages in the very same niche, aiming to be a C++ replacement, and developped in the open.
- hamstergene 12y ago
  Go and Rust had the very same self-positioning as C++ replacement, but because of different visions of what C++ is for they are now in largely unrelated niches. It is hard to imagine, for example, that someone would choose Go to rewrite Webkit, or LLVM, or any C++ math/modelling library (for other reason than proving it's possible). Just as an idea of writing website business logic in Rust would make me scratch my head.
  - steveklabnik 12y ago
    While I agree that writing backends in Rust may not be the best, Crates.io uses Rust as a backend for Ember, and it seems to be working out really well. I'm skeptical, but interested to see how it develops.
  - EugeneOZ 12y ago
    Then check out Iron.rs and Nickel.rs - web-frameworks in Rust :) Yes, Rust is more complicated language but sometimes you are ready to pay this price just to get back joy of programming. And at some point in time, bugs in runtime (because of types or memory safety or race conditions) becomes so annoying, that you are ready to be thankful to any tool which can find them on compilation, even with price of more verbose code. "Typing is not a bottleneck".
    - MetaCosm 12y ago
      "Joy" -- I feel like I spend all my time bookkeeping -- which is about the least fun thing imaginable. The guarantees keep me interested, but just barely at this point.
  - kxo 12y ago
    If Rust had asynchronous I/O this would be less of a head scratcher. Too bad that AIO and related, necessary primitives were forsaken for other priorities.
S4M 12y ago
I think lots of programming languages are been created, and the vast majority of them fall into obscurity, but some have nice features and grain a bit of traction, which is what is happening right now with Nim. If you forgive me the comparison, I would say that Nim is to the programming languages what Flappy Birds is to the video games: a successful product built by a talented programmer in a place where lots of people try their own - of course, the analogy is not completely right since the barrier to create a programming language is much, much higher than to create a small video game.

Fede_V 12y ago

The killer feature of Nim is its amazing syntax. If you know Python, Nim will instantly feel very, very familiar. Rust looks incredibly useful to do systems level programming, and guaranteed pointer safety without GC costs is amazing, but it takes me much longer to figure out exactly what's happening in the code.

guelo 12y ago
Right. Before I even read the article my thought was "Nim better be easier or what's the point of the GC".
Tharkun 12y ago
Surely what is or isn't amazing syntax depends entirely on your preferences and personal experiences. I can't stand the Python syntax. Significant whitespace is an instant turnoff for me. For me, figuring out Rust is a lot easier than figuring out Nim, because that's what I'm used to.
- Ygg2 12y ago
  I second this notion. Thing I hate about Python is that it relies on invisible characters so two identically looking pieces of code aren't.
  - Demiurge 12y ago
    This is something I thought before I actually used python. In practice, two identically looking pieces of code ARE. Yes, you can mix tabs and spaces, but not in the same block. The moment there is ambiguity the interpreter errors out. So, in practice this is never a problem, your text editor should not be switching on you randomly and the official style guide strongly asks you to use 4space tabs. Simply follow the official guidelines and be able to configure your text editor, and you will never think about this again if you're actually using python.
    - Ygg2 12y ago
      > Yes, you can mix tabs and spaces, but not in the same block. Assuming of course all code contributors memorized the official style guidelines. And that they are responsive to such changes. I've had one similar change, reverted three times during my uni project, within span of days.

keyle 12y ago

I love nim. I've been using it non-stop since I've learnt the ropes. The only thing I'd wish was better results when googling for things. "nim" is just a very common word it appears. The site itself is a wealth of knowledge. I can relate to the comment of "feeling it's too big". Sadly the doco is not newbie friendly for some part (hi there, async). I've had no issues with the compiler but be sure to always use the devel branch. Things move fast in nim.

aphexairlines 12y ago

Looks like comparing apples and oranges. If Nim has a GC it would be more instructive to compare it with another garbage-collected systems language like OCaml.

z92 12y ago
What's wrong with comparing a GC language with non-GC language?
- lifthrasiir 12y ago
  Wildly different goals, given that there should be some interesting reason to avoid GC nowadays.
  - twic 12y ago
    An interesting to reason to avoid GC would be a belief that you could make a usable general-purpose language without GC.
    - Ygg2 12y ago
      Or having code that's callable from another GC-ed language like Ruby/Python/etc. Two GCs dancing around each other (e.g. Python calling Nim) is a recipe ripe for problems.
  - rdtsc 12y ago
    How are they "wildly" different. I can see different but "whildly" really? GC is an implementation detail with some performance characteristics. Nim can turn its GC off. It can do a soft-realtime GC behavior where you limit its maximum time slice.
    - tomjakubowski 12y ago
      > Nim can turn its GC off. At the expense of losing memory safety.

alextgordon 12y ago

I too have suffered Rust's religiosity on the floating point issue. In Python, given an array xs = [3.1, 1.2, 4.3, 2.2], I can write xs.sort() and get [1.2, 2.2, 3.1, 4.4] In Haskell sort xs In Swift sort(&xs) In Rust you have to spew this monstrosity xs.sort_by(|a, b| a.partial_cmp(b).unwrap_or(Less)) The Rust position appears to be that sorting an array of floats is unreasonable and so you must be "punished" by not being allowed to use the built-in .sort() function.

heinrich5991 12y ago
What is the expected result if you have NaN in your list?
- lclarkmichalek 12y ago
  In python at least, it's a bit funky: >>> sorted(map(float, ['1', '2', 'nan', '4', '3'])) [1.0, 2.0, nan, 3.0, 4.0] >>> sorted(map(float, ['1', '5', '2', 'nan', '4', '3'])) [1.0, 2.0, 3.0, 4.0, 5.0, nan]
  - moe 12y ago
    Ruby has it about right (imho): > [1.0,2.0,Float::NAN].sort ArgumentError: comparison of Float with Float failed
    - whyever 12y ago
      Rust's way is more flexible though: You can choose how to treat NaNs, in Ruby you have to fail.
      - moe 12y ago
        in Ruby you have to fail Oh, really? ;) > [1.0,2.0,Float::NAN].sort ArgumentError: comparison of Float with Float failed > # let's make NaN sortable > Float::NAN.class.send(:define_method, '<=>') { |x| -1 } > [1.0,2.0,Float::NAN].sort => [1.0, 2.0, NaN]

shadowmint 12y ago

Pretty fair commentary. Rust certainly isn't one of those languages where you can just pick it up, play with it for a day implementing an algorithm in it to get the feel of it and learn 'the complicated stuff' later. Other languages let you get away with that quick start style; you can write a lot of python before you need to write a plugin, and a lot of c# before you start using unsafe code, etc. Rust doesn't afford you that luxury. Lifetimes, mutability and single ownership are BAM, right in your face from the start. It probably puts a few people off... but hey, you know the analogy about tools and toolboxes. Rust is for writing fast, secure, cross platform code. There's nothing else out there that offers the same; it's not a case of use Rust or Nim, or C++; rust is literally the only language that offers these features right now. You can certainly write code that happens to be secure, fast and cross platform (eg. in C++), and if you don't need those features (or dont care), you're almost certainly better off picking a different language (like Go or Nim) that are 'fast enough' and 'secure enough', and don't restrict you in the same way Rust does, or something far more productive (like python or javascript) if all you need to do is smash out a product. That's perfectly ok. We don't need a language which is everything for everyone all at the same time. Rust is very good at doing what it does; and it's the first time C++ has had a real challenger. I, for one, am really looking forward to the dynamics between the two crowds going forwards.

pjmlp 12y ago
> Rust is very good at doing what it does; and it's the first time C++ has had a real challenger. Ada and Modula-3 were there first, they just weren't adopted by OS vendors at large.
- vezzy-fnord 12y ago
  Additionally, their categorizations of "fast", "secure" and "cross-platform" are far too general. I don't even think Rust officially supports that many platforms yet. It's strictly OS X/Windows/Linux, and the latter depends on glibc unless you're willing to throw away a ton of the standard library and third-party crates to start from scratch.
  - 12y ago

tmerr 12y ago

>>the whole language is verbose: compare these 10 lines (https://github.com/andreaferretti/kmeans/blob/935b8966d4fe0d4854d3d69ec0fbfb4dd69a3fd1/rust/src/point/mod.rs#L30-L39 https://github.com/andreaferretti/kmeans/blob/935b8966d4fe0d...) with this single line (https://github.com/andreaferretti/kmeans/blob/master/nim/algo.nim#L10 https://github.com/andreaferretti/kmeans/blob/master/nim/alg...) The Nim code's more concise in this case but the Rust code can be more clearly written: impl Add for Point { type Output = Point; fn add(self, other: Point) -> Point { Point(self.0 + other.0, self.1 + other.1) } } The "type Output = Point" line isn't boilerplate, it makes it possible to define the result of an addition as something other than a Point. (Off of the top of my head I can't think of any use cases, but I'm happy with the capability personally).

Coding_Cat 12y ago
For addition I can't either, but you could use it to overload multiplication of two (mathematical) vectors to a dot-product impl Mul for Vec2{ type Output = double; fn mul(self, other: Vec2) -> Double { self.0*other.0+self.1*other.1) } } Although I must admit I'm not (yet) sure why you need to explicitly state the output and define it for the function. But I have only just started with Rust.
- Ygg2 12y ago
  > Although I must admit I'm not (yet) sure why you need to explicitly state the output and define it for the function. But I have only just started with Rust. I generally assume it's because it can't infer the associated type from function signature, for now.
- sanderjd 12y ago
  A simple example for addition would be adding two u64s and getting a bignum type.
steveklabnik 12y ago
The last time this post appeared, I actually submitted a PR which did this, among other things: https://github.com/andreaferretti/kmeans/pull/3 https://github.com/andreaferretti/kmeans/pull/3 The post wasn't really updated.

halosghost 12y ago

Okay, so I'm having one problem with nim. Disabling all unsigned arithmetic by-default. The logic is actually fairly sound (it's probably, generally, harder to overflow a signed than an unsigned), but nim doesn't compile to object code; it transpiles to C and then C compiles to object/machine code. Edit: it's obviously much harder to overflow an unsigned than a signed; in the sentence above, I was thinking particularly of underflow (which is what the nim devs reference as their logic for disabling unsigned arithmetic by-default). The problem here is that unsigned arithmetic, though much easier to hit underflow, is fully defined in C where signed {under,over}flow is UB. As a result, if you manage to hit this case in nim, you're now going to hit UB by-default. This seems crazy to me. Am I missing something?

def- 12y ago
While unsigned arithmetic is not "enabled by-default", a simple `import unsigned` and you have it. If you want the language to handle overflows for you, you can enable runtime overflow checks for your whole code or any specific part of it. Otherwise, if you opt for no runtime checks and release builds with all optimizations, you indeed go into the same undefined behaviour territority as in C, so you'd have to prevent overflows before they happen.
- halosghost 12y ago
  I understand that it is available simply; I was questioning the logic of having it disabled by-default. Having the ability to do run-time checks for {over,under}flow does seem to make this issue a little better but doesn't explain the logic of having the language prefer UB by-default. Yes, C does this too (integers are signed by-default), but if I'm shopping for a language that abstracts C, I'm probably looking for improvments over C's defaults.

arbre 12y ago

I would be curious on how Go would compare to these two on that example.

fiatjaf 12y ago

Do you create a new repository on GitHub for everything you want to write?

thechao 12y ago

> but adding a map function on Vector would have not prevented this more sophisticated use. This was questioned, long ago, by Todd Veldhuizen in his Parsimony Principle paper[1]. The long-and-short of which is: do it! [1] http://arxiv.org/abs/0707.4166 http://arxiv.org/abs/0707.4166

throawai 12y ago

Keyle [dead]: I love nim. I've been using it non-stop since I've learnt the ropes. The only thing I'd wish was better results when googling for things. "nim" is just a very common word it appears. The site itself is a wealth of knowledge. I can relate to the comment of "feeling it's too big". Sadly the doco is not newbie friendly for some part (hi there, async). I've had no issues with the compiler but be sure to always use the devel branch. Things move fast in nim. -----

def- 12y ago
Well, it was named "Nimrod" before, but there were other problems with that name, which prompted the rename. "Nim" was a good choice because it was the file ending already. Also, easier to google than C and Go at least. Usually "nim-lang" works fine.
dom96 12y ago
I'm curious why the post was deleted. Can mods shed some light on this?
- steveklabnik 12y ago
  They are shadow banned.
  - keyle 12y ago
    What is shadow banned and why am I?
  - steveklabnik 12y ago
    keyle, you'd have to take that up with the HN adminstration, I can't help you.
keyle 12y ago
Why dead??

Animats 12y ago

That's a good commentary. As for Nim, do we really need another unsafe language with a part-time GC? If you can tolerate a GC, there are a lot of good language options. I have some issues with Rust's verbosity, especially in the error handling area. I recently bugged the Rust crowd into changing their overly complicated replacement for C's "argc/argv" approach to command line parameters.[1] They listened. The Rust crowd is trying hard in a difficult area and succeeding. In C and C++, lifetimes and mutability are in your face from the start. It's just that the compiler doesn't help you with them. For years, I've been saying that the three big problems with C/C++ are "How big is it? Who owns it? Who locks it?". C gives no help with any of those. C++ addresses "how big", but it's not airtight, and C++14 tries to address "Who owns it", but only for new code, and it's not airtight. Rust aggressively deals with all three problems. I can understand the unhappiness with Rust, though. It's not a comfortable language for many modern programmers, especially ones who've never done any constrained form of engineering. For them, I'd suggest Go and Python. Go can do pretty much anything you need to do on a web server, and fast. That's why Google created it. So can Python, but more slowly. Both are memory safe (well, Go isn't in multi thread mode.) Understanding the Rust mindset can be hard. That's a documentation problem. The "Rust for Dummies" book has not yet been written. The Rust tutorial glosses over the hard issues, and the Rust reference is written for people who are into language design, compiler design, and theory. Until recently the language design had so much churn that most of the Rust material on the web is out of date. In another year, there will probably be a decent Rust book. With Rust, you need a plan for who's going to own what before you start. Then you just have to explain that plan to the borrow checker. For a complex, mutable data structure, such as a DOM or a GUI's collection of interconnected widgets, this may take design work and design documents. If you plow ahead without thinking through who owns what, including in the error cases, you'll get Rust compile time errors. You would have hit trouble in C or C++ too, but it would have been in the form of a memory leak, crash, or security hole. Now you have to fix it up front. There are performance wins in this. Someone recently commented on HN that they'd discovered that typing into a dialog box produced some insane number (thousands) of allocation events per keystroke. That was partly because, at many places in the C++ code, a c_str was being copied into a fresh String object. That's a consequence of being afraid to borrow a reference to a string you don't own, for fear of creating a bug. It's safer to make a copy. In Rust, the compiler will tell you if you can do that safely. If you need to make a copy, you can, but if you just take a reference and Rust allows it, the code is good. Big step forward. [1] https://github.com/rust-lang/rust/pull/21787#issuecomment-73161760 https://github.com/rust-lang/rust/pull/21787#issuecomment-73...