6 ms·

There actually is one high-level Python-like language that really is almost "as fast as C". http://nim-lang.org http://nim-lang.org I am using it for years al

by progman 10y ago

There actually is one high-level Python-like language that really is almost "as fast as C". http://nim-lang.org http://nim-lang.org I am using it for years already, and it is really performant, somewhere between C and Rust. I am still wondering why so few people use it. Benchmark: https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks Nim vs Rust: http://arthurtw.github.io/2015/01/12/quick-comparison-nim-vs-rust.html http://arthurtw.github.io/2015/01/12/quick-comparison-nim-vs... Performance discussion: http://forum.nim-lang.org/t/2261 http://forum.nim-lang.org/t/2261 Embedded Nim: https://hookrace.net/blog/nim-binary-size/ https://hookrace.net/blog/nim-binary-size/ Nim on LLVM: https://github.com/arnetheduck/nlvm https://github.com/arnetheduck/nlvm

def- 10y ago
> I am still wondering why so few people use it. While Nim is my favorite language, I can understand that it has a small userbase, for these reasons: 1. No major backer like Google for Go or Mozilla for Rust 2. No killer feature like "memory safety and performance without GC" for Rust, instead a mix of all the reasonable down-to-earth features I want in a programming language 3. Some unique decisions instead of what you're used to from other languages, for example partial case sensitivity
- untothebreach 10y ago
  I used both nim (back when it was still nimrod) and rust for a while, before eventually settling on rust. I tried to give nim a chance, and was told that "they will grow on you" ("they" being the things you mentioned that were "unique decisions instead of what you're used to from other languages"). They never did, and though I got used to avoiding the problems I initially had with them, the language just never "felt good" to me.
- valarauca1 10y ago
  4. The fact that operator order is changed by the amount of white space between symbols 2+2 * 5 = 20 2 + 2 * 5 = 12
  - adrusi 10y ago
    If you're consistent about how you space your infix operators, this will have no impact on your code. If you put space around some operators and not around others, in a way that doesn't correspond to precedence, you're going to confuse anyone who reads your code, in any language.
    - valarauca1 10y ago
      Being confused by code is no excuse for code not doing what ya know... every other programming language has done for the past 50 years. I get that trying new things, but somethings are pretty well agreed upon.
  - xutopia 10y ago
    damn... I actually like that a lot!
    - qu4z-2 10y ago
      I like it for distinguishing homonym operators, but not for the precedence stuff they seem to have there. I'd like something like this though: let a = 10; a / 5 output> 2 let b = pwd(); b/temp output> Directory<"~/temp"> b / 2 error> b:Directory does not implement method "divide(:number)" a/temp error> a:int does not implement method "get(:string)"
  - progman 10y ago
    I am a strong proponent of Nim but this is probably the worst idea I have ever encountered in language development. Honestly! Partial case sensitivity and the special underscore case are features I can live with. Unfortunately this has actually become a stumbling block for a wider adoption of Nim. All strange special features should be optional, not default.
    - dom96 10y ago
      What makes you think this is default? It most certainly is not and will be removed completely in the future. Edit: here is a source: http://nim-lang.org/docs/manual.html#syntax-strong-spaces http://nim-lang.org/docs/manual.html#syntax-strong-spaces ("... if the experimental parser directive #?strongSpaces is used..."). The last time this was discussed I said that it would be removed completely, and I still believe it will be. It's simply not a priority for us right now.
- ericfrederich 10y ago
  wow... have never heard of that partial case sensitivity before. I think this goes beyond syntactic sugar. Holding the hand of the developer too much? Personally, as a Python programmer I like interfacing with C++ code like Qt via PyQt. If I see a camelCase method I know where it came from, but if I see a PEP-8 style name or method I know it's our own code, not from Qt.
bluetomcat 10y ago
Shameless plug: is it considered totally uncool in 2016 for one to be developing a memory-unsafe, manual MM, non-OO, thread-denying language that preserves most of the C semantics? https://github.com/bbu/quaint-lang https://github.com/bbu/quaint-lang
- lmm 10y ago
  Yes. Memory unsafety doesn't work.
- exDM69 10y ago
  No, definitely not! I'd be very interested in a language that is roughly as low level as C, but has some obvious warts "fixed" while still being able to run on bare metal or with a minimal runtime system. I also don't care about a standard lib as long as I can call open(), close(), read(), write(), socket(), etc. Native threads is another requirement for me. Things I'd like to see in a language: - compile to native executable - type inference - module system without header files - easy to call into native C code, and export functions so they can be called from C or any other language - first class SIMD structures (this is missing from Rust!), so that you don't have to duplicate code for sin4f and sin8f (which would be line-by-line equal, except types) - perhaps some kind of modern polymorphism (ie. not class based OOP) - can target GPUs via LLVM or SPIR-V - memory safety is optional, but nice to have. I'd be mostly interested in using this kind of language for GPU kernels and tight inner loops, where you wouldn't be allocating anyways I have a bunch of design ideas and prototypes in my drawer waiting for a lot of free time and inspiration appearing. I like my tools sharp, even if it means there's going to be blood occasionally.
  - bluetomcat 10y ago
    My next big endeavour with Quaint will be to create a clean module and linking system (without header files or any textual inclusions). Each source file will be transformed to a corresponding unit which contains code, data and exported type definitions. The linker would then merge these units and produce a native executable that runs your program in the self-hosted VM which will be a part of that executable. Pure native compilation or LLVM integration is too much of a hassle for me at this point. One of the virtues of the language would also be the direct correspondence between the HLL code and the emitted VM instructions, without any optimisation passes. This makes it much easier to reason about code performance and to write code which performs consistently and predictably (albeit a bit slower).
3pt14159 10y ago
I love and use Nim (in production). I wrote about why I don't think it's gained wide adoption in a previous post here: https://news.ycombinator.com/item?id=11960814 https://news.ycombinator.com/item?id=11960814 The only thing I would add would be that compared to Ruby, Nim still takes you quite a while to put something together, so defaulting to Ruby isn't necessarily a great idea.
steveklabnik 10y ago
Just a small note for anyone reading the "Nim vs Rust" post; today, regex! is much slower than Regex::new.
hetman 10y ago
All the benchmarks you posted suggest that Rust is faster than Nim, not the other way around. Did you have something else in mind?
- steveklabnik 10y ago
  A lot of them did show the other way, then came to Rust people's attention and improvements were submitted. As well as both languages' implementations changing over time.
Veedrac 10y ago
The first benchmark ("Nim vs Rust") I looked at says > Rust regex! runs faster than Regex which is a very old claim - Regex should now be much faster than regex! ever was. Any pre-1.0 Rust benchmarks are probably wrong (to be fair, most benchmarks are probably wrong anyway).

by progman 10y ago

def- 10y ago

> I am still wondering why so few people use it. While Nim is my favorite language, I can understand that it has a small userbase, for these reasons: 1. No major backer like Google for Go or Mozilla for Rust 2. No killer feature like "memory safety and performance without GC" for Rust, instead a mix of all the reasonable down-to-earth features I want in a programming language 3. Some unique decisions instead of what you're used to from other languages, for example partial case sensitivity

untothebreach 10y ago
I used both nim (back when it was still nimrod) and rust for a while, before eventually settling on rust. I tried to give nim a chance, and was told that "they will grow on you" ("they" being the things you mentioned that were "unique decisions instead of what you're used to from other languages"). They never did, and though I got used to avoiding the problems I initially had with them, the language just never "felt good" to me.
valarauca1 10y ago
4. The fact that operator order is changed by the amount of white space between symbols 2+2 * 5 = 20 2 + 2 * 5 = 12
- adrusi 10y ago
  If you're consistent about how you space your infix operators, this will have no impact on your code. If you put space around some operators and not around others, in a way that doesn't correspond to precedence, you're going to confuse anyone who reads your code, in any language.
  - valarauca1 10y ago
    Being confused by code is no excuse for code not doing what ya know... every other programming language has done for the past 50 years. I get that trying new things, but somethings are pretty well agreed upon.
- xutopia 10y ago
  damn... I actually like that a lot!
  - qu4z-2 10y ago
    I like it for distinguishing homonym operators, but not for the precedence stuff they seem to have there. I'd like something like this though: let a = 10; a / 5 output> 2 let b = pwd(); b/temp output> Directory<"~/temp"> b / 2 error> b:Directory does not implement method "divide(:number)" a/temp error> a:int does not implement method "get(:string)"
- progman 10y ago
  I am a strong proponent of Nim but this is probably the worst idea I have ever encountered in language development. Honestly! Partial case sensitivity and the special underscore case are features I can live with. Unfortunately this has actually become a stumbling block for a wider adoption of Nim. All strange special features should be optional, not default.
  - dom96 10y ago
    What makes you think this is default? It most certainly is not and will be removed completely in the future. Edit: here is a source: http://nim-lang.org/docs/manual.html#syntax-strong-spaces http://nim-lang.org/docs/manual.html#syntax-strong-spaces ("... if the experimental parser directive #?strongSpaces is used..."). The last time this was discussed I said that it would be removed completely, and I still believe it will be. It's simply not a priority for us right now.
ericfrederich 10y ago
wow... have never heard of that partial case sensitivity before. I think this goes beyond syntactic sugar. Holding the hand of the developer too much? Personally, as a Python programmer I like interfacing with C++ code like Qt via PyQt. If I see a camelCase method I know where it came from, but if I see a PEP-8 style name or method I know it's our own code, not from Qt.

bluetomcat 10y ago

Shameless plug: is it considered totally uncool in 2016 for one to be developing a memory-unsafe, manual MM, non-OO, thread-denying language that preserves most of the C semantics? https://github.com/bbu/quaint-lang https://github.com/bbu/quaint-lang

lmm 10y ago
Yes. Memory unsafety doesn't work.
exDM69 10y ago
No, definitely not! I'd be very interested in a language that is roughly as low level as C, but has some obvious warts "fixed" while still being able to run on bare metal or with a minimal runtime system. I also don't care about a standard lib as long as I can call open(), close(), read(), write(), socket(), etc. Native threads is another requirement for me. Things I'd like to see in a language: - compile to native executable - type inference - module system without header files - easy to call into native C code, and export functions so they can be called from C or any other language - first class SIMD structures (this is missing from Rust!), so that you don't have to duplicate code for sin4f and sin8f (which would be line-by-line equal, except types) - perhaps some kind of modern polymorphism (ie. not class based OOP) - can target GPUs via LLVM or SPIR-V - memory safety is optional, but nice to have. I'd be mostly interested in using this kind of language for GPU kernels and tight inner loops, where you wouldn't be allocating anyways I have a bunch of design ideas and prototypes in my drawer waiting for a lot of free time and inspiration appearing. I like my tools sharp, even if it means there's going to be blood occasionally.
- bluetomcat 10y ago
  My next big endeavour with Quaint will be to create a clean module and linking system (without header files or any textual inclusions). Each source file will be transformed to a corresponding unit which contains code, data and exported type definitions. The linker would then merge these units and produce a native executable that runs your program in the self-hosted VM which will be a part of that executable. Pure native compilation or LLVM integration is too much of a hassle for me at this point. One of the virtues of the language would also be the direct correspondence between the HLL code and the emitted VM instructions, without any optimisation passes. This makes it much easier to reason about code performance and to write code which performs consistently and predictably (albeit a bit slower).

3pt14159 10y ago

I love and use Nim (in production). I wrote about why I don't think it's gained wide adoption in a previous post here: https://news.ycombinator.com/item?id=11960814 https://news.ycombinator.com/item?id=11960814 The only thing I would add would be that compared to Ruby, Nim still takes you quite a while to put something together, so defaulting to Ruby isn't necessarily a great idea.

steveklabnik 10y ago

Just a small note for anyone reading the "Nim vs Rust" post; today, regex! is much slower than Regex::new.

hetman 10y ago

All the benchmarks you posted suggest that Rust is faster than Nim, not the other way around. Did you have something else in mind?

steveklabnik 10y ago
A lot of them did show the other way, then came to Rust people's attention and improvements were submitted. As well as both languages' implementations changing over time.

Veedrac 10y ago

The first benchmark ("Nim vs Rust") I looked at says > Rust regex! runs faster than Regex which is a very old claim - Regex should now be much faster than regex! ever was. Any pre-1.0 Rust benchmarks are probably wrong (to be fair, most benchmarks are probably wrong anyway).