Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim 1.0

nim-lang.org

Post reply on HN
Print view View original

101–110 of 308 posts

Re: Nim 1.0

#101

Post by jdkardia »

scottlamb wrote: post #34
19ylram49 wrote: post #22

Earlier quoted context omitted.

On the contrary, I feel that the stylistic [and sometimes semantic] separation of primitive and boxed types in languages (e.g., `byte` VS `Byte` in Java) improves the developer experience, in that I can very quickly dissect the type of value that I’m dealing with when reading the code.

In Java that difference matters a lot for performance: primitives are unboxed, objects are boxed. (Not as true now with auto boxing and escape analysis, but this was absolutely true in version 1.0.) In C++ it can matter for correctness because primitives are uninitialized by default. But other types might be too and the standard library uses under_scores for things that are initialized on construction, so it's not a…

In this case it might be a 'documentation as code'thing, being able to see at a glance if something is a language primitive or a potentially very different implementation could have value.

However I'm not super familiar with Rust, so I couldn't speak to that why.

Re: Nim 1.0

#102

Post by gameswithgo »

pdimitar wrote: post #98
gtycomb wrote: post #75

Earlier quoted context omitted.

When I started an enterprise data project with a small team where Python was the familar workhorse we stopped for moment initially to think of ways to improve performance. Cython was the familiar route with Python but we started building small prototyes in Rust, Go, and Nim. Beyond the basics our progress slowed down with Rust and Go (yes, I know Go is very easy for some) but Nim allowed us to put together a fully fa…

I'm curious why did your progress with Rust stalled and at which point? I’m starting to learn it and so far I haven’t noticed any productivity blockers.

just keep at it, eventually you run into data structures hard to represent with a borrow checker and it will slow you down, at least at first

Re: Nim 1.0

#103

Post by ezrast »

19ylram49 wrote: post #78
detaro wrote: post #71

Earlier quoted context omitted.

"As fast as C" would commonly be interpreted as "a program written in it will be as fast as a well-written C equivalent", not as "there is a C program with the same performance characteristics". That a language is compiled to C does not mean that its compiler is going to be able to produce a C program that's as good as a that well-written C equivalent. (A relatively obvious example would be a compiler that introduces…

> "As fast as C" would commonly be interpreted as "a program written in it will be as fast as a well-written C equivalent" That’s your interpretation, which is fine, but the objective meaning stands. Even the idea of “well-written C” is, in my experience, fairly subjective amongst C programmers.

Remember that we're comparing languages, not programs. A language can be thought of as the space of all programs that can be interpreted by that language. In any language, any algorithm can be implemented arbitrarily slowly. So the only meaningful point of comparison between language X and language Y is the upper bound on the performance of each language's program-space.

That some particular C program exists that is at least as slow as a program in some other language is always true, trivially, and so is not a good interpretation of "as fast as C" regardless of its objectivity.

Re: Nim 1.0

#104

Post by TylerE »

vasili111 wrote: post #73
danielecook wrote: post #48

Earlier quoted context omitted.

I stumbled onto nim because a sequencing-data (DNA/RNA/etc) library was written for it ( https://github.com/brentp/hts-nim ). In addition to Go, it's been a great way to learn a compiled language. It's fast, easy to use, and has a friendly community.

How good is nim performance with sequencing-data in comparision with other programming languages you used for it before?

Nim performance is really really good. Like, maybe C - 5%. Comparable with stuff like Rust or D... way way faster than Go or anything interpreted.

Re: Nim 1.0

#105

Post by loeg »

ptx wrote: post #76
perturbation wrote: post #4

Congrats guys!!! This has been much-anticipated and I'm very excited. I personally wish that the owned reference stuff ( https://nim-lang.org/araq/ownedrefs.html ) had been part of 1.0, but I think that at some point shipping 1.0 >> everything else. I've been following (and evangelizing) Nim for a while, this will make it easier to do so.

I don't quite understand the definition of "memory safety" in that document. If deallocation can cause other objects to end up pointing to the wrong thing and the wrong data, how is that different from memory corruption? If your filesystem suddenly starts returning the contents of notepad.exe when asked for user32.dll and vice versa, is that not filesystem corruption? If an admin user object can suddenly start pointi…

It's type safety. The pointer will always point to an object of the same type. This is common in operating systems, for example. You have some out of band way of verifying that the object's identity has not changed (deallocation would be a change of identity) when you access the object under some sort of serialization.

It's certainly a weaker definition of memory safety than you and I, and I would guess most people, would have in mind. So in that sense, I think the author is wrong to call it memory safety.

You're totally correct that a logic bug in this category could cause a credentials pointer to point to a different or higher set of credentials, and that is an implementation risk.

Re: Nim 1.0

#106

Post by pier25 »

treeform wrote: post #28
nfrankel wrote: post #20

Question (genuine, not trolling): what's the use-case for Nim regarding other languages? What are its pros/cons?

To me Nim is a faster python that prevents typos. It can also compile to javascript. I used it where I would use python - backend of web apps. But now instead running a cluster of servers I can just run 1 because nim is fast. I also used to write frontend in CoffeeScript, but switched to nim because I can share code between backend and frontend. I don't have typos. I don't inherit any JS or OOP legacy like TypeScript…

Do you use any JS libraries in the front end?

Re: Nim 1.0

#107

Post by maxdamantus »

maxdamantus wrote: post #62
Arnavion wrote: post #54

Earlier quoted context omitted.

>it seems to defer type checking of generic code until it is instantiated (this is what happens in C++) ... and you don't get some error pointing to code internal to the function when the user applies types that don't work. Worth noting that C++ is going the opposite way with concepts. The compiler still won't enforce that `template void foo(T t) { t++; }` needs a `requires Incrementable T` (like Rust would require w…

Interesting. From what I remember of Go's generics proposal, they seemed to be trying to do something similar, which seemed a bit hacky to me (as you say, it addresses the error reporting issue but it's difficult to see how the constraints would be used to actually check the generic code, so functions can presumably still lie about being "for all types"). EDIT: actually, Go's generics proposal probably doesn't have t…

> EDIT: actually, Go's generics proposal probably doesn't have that issue, since the contracts are restricted enough to derive type declarations from them.

Just wanted to add that my initial memory was apparently of the earlier proposal for generics in Go, as reflected here: https://dev.to/deanveloper/go-2-draft-generics-3333 (in this earlier proposal, contracts simply specify code that is expected to compile, in such a way that it would be difficult/impossible to derive types for symbols introduced by the contract).

I guess the golang people figured out why that was not an optimal system and changed it ... wonder if the same will be true of Nim.

Re: Nim 1.0

#108

Post by [deleted] »

RussianCow wrote: post #96
19ylram49 wrote: post #78

Earlier quoted context omitted.

> "As fast as C" would commonly be interpreted as "a program written in it will be as fast as a well-written C equivalent" That’s your interpretation, which is fine, but the objective meaning stands. Even the idea of “well-written C” is, in my experience, fairly subjective amongst C programmers.

You're missing the point. The fact that a language compiles down to C doesn't mean it compiles down to efficient C. At the simplest level, the compiled code could add a bunch of unnecessary function calls and pointers and other forms of indirection that wouldn't be present in hand-written C. But for a more extreme example, you could also compile an interpreter or VM to C, and it would still be much slower than the eq…

[deleted]

Re: Nim 1.0

#109

Post by gtycomb »

pdimitar wrote: post #98
gtycomb wrote: post #75

Earlier quoted context omitted.

When I started an enterprise data project with a small team where Python was the familar workhorse we stopped for moment initially to think of ways to improve performance. Cython was the familiar route with Python but we started building small prototyes in Rust, Go, and Nim. Beyond the basics our progress slowed down with Rust and Go (yes, I know Go is very easy for some) but Nim allowed us to put together a fully fa…

I'm curious why did your progress with Rust stalled and at which point? I’m starting to learn it and so far I haven’t noticed any productivity blockers.

I heartily wish that you continue learning Rust, another significant contribution to open source languages. What has been already commented, things such as borrow/checker are humps you work through and it will work out for you eventually. The other challenges are some of your enterprise 3rd party integrations with the outside world, some of which may again demand your time if they are still in beta, etc.

Also, the organization has no desire to invest in training or experimenting. The project is funded by the "business" and they want to see a business result in return for their money ... so you basically you sneak in a bit of time as you try/test something new. Nim won out by somehow getting a team with python expertise learn and deploy their product fast enough.

Re: Nim 1.0

#110

Post by maxpert »

Congrats and Thanks Nim team. I’ve been tinkering with Nim to build a really efficient pubsub server. Something that can take heavy concurrent connections. Now I can actually build with confidence.
Post reply on HN