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

Nim binary size from 160 KB to 150 Bytes

hookrace.net

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Nim binary size from 160 KB to 150 Bytes

#61

Post by filwit »

phaylon wrote: post #55
filwit wrote: post #52

Earlier quoted context omitted.

> there are strictly more steps involved when you have null pointers. Well yes, and both Nim and Rust have non-nil pointers.. I suppose I misread your original statement as "Rust is objectively better ..." when you actually just said non-nil vars are an objectively better design pattern in general. My mistake. Our argument seems to stem around the two assertions (one from you, and one from me), those are: "nil vars a…

> Rust must either treat every Option reference as a potential 'loan path', which would significantly diminish their usefulness as a references, encouraging indexing for these scenarios, which leads to almost identical potential for out-of-bounds crashes... or it's relying on some kind of more complex mechanism (lifetime vars maybe?).. or additional runtime overhead. Can you give a concrete example of this? I'm a bit…

> I should clarify: What's confusing me is the indexing stuff. I'm not sure if this is referring to something about the `Option` or something else.

By indexing, I meant as an alternative to references.. For example, if you had a Sprite type which held a 'reference' to a Texture in your game's Texture list.. as soon as you allocate a Sprite it must borrow a reference to a Texture, preventing any future mutation of the Textures list for the lifetime of the Sprite, which obviously is too restricting for most games.. so the alternative is to have the Sprite simply hold an index to an item in the array instead, but this basically comes with the same pitfalls as nilable refs (ie, if you accidentally change it, your program can crash due to bounds-checking errors.. or end up with visual glitches.. not sure which would be more annoying).

The other alternative is to use an Option instead. However, I'm not familiar enough with Rust to know of the restrictions here, or even if that's possible (taking a look at the docs, it looks like it's possible, but life-time vars come into play, which could complicate things).

Re: Nim binary size from 160 KB to 150 Bytes

#62

Post by filwit »

pcwalton wrote: post #59
filwit wrote: post #58

Earlier quoted context omitted.

So I remembered correctly, Nim does not reach UB in non-release code (or rather, code without --boundCheck:on), it throws an exception. I still think this is a reasonable solution. We catch these errors during development iteration or enable it for safety-critical portions of release code (or the entire project).. and we can opt-out of these checks if we need the performance and safety isn't as important (games, simu…

> So I remembered correctly, Nim does not reach UB in non-release code (or rather, code without --boundCheck:on), it throws an exception. That's not really correct. It's undefined behavior either way; you're just getting lucky because the compiler doesn't happen to take advantage of the undefined behavior to perform optimizations at -O0.

I'm not sure what you're implying.. you can turn on most optimizations and still keep nil-checks on in Nim (either the whole project via --nilChecks:one, or select portions of code via {.push.}).

Unless you're claiming your example was still hiting UB, even with nil-checks on, and just happened to throw an exception by random chance, I'm not really sure how you figure UB is still happening here (since the exception will be thrown, preventing the deref). Nothing is preventing you from using nil-checks in production code.

Re: Nim binary size from 160 KB to 150 Bytes

#63

Post by phaylon »

filwit wrote: post #61
phaylon wrote: post #55

Earlier quoted context omitted.

> Rust must either treat every Option reference as a potential 'loan path', which would significantly diminish their usefulness as a references, encouraging indexing for these scenarios, which leads to almost identical potential for out-of-bounds crashes... or it's relying on some kind of more complex mechanism (lifetime vars maybe?).. or additional runtime overhead. Can you give a concrete example of this? I'm a bit…

> I should clarify: What's confusing me is the indexing stuff. I'm not sure if this is referring to something about the `Option ` or something else. By indexing, I meant as an alternative to references.. For example, if you had a Sprite type which held a 'reference' to a Texture in your game's Texture list.. as soon as you allocate a Sprite it must borrow a reference to a Texture, preventing any future mutation of th…

Rust solutions would probably be the following: Some kind of runtime assistance (`Rc`, `Arc` et al), using indices as you mentioned (though with `list.get(index)` you'd still have to deal with the fact that it might not be valid, since `get` will return an `Option`)[1] Another solution might be to allocate the textures in an arena that lives outside of the scope of your game logic, and have both the texture list and sprites contain borrows (Note I'm not sure about this, as I haven't done much with arenas yet).

Although I'm unsure where the `not nil` as discussed above comes into play here. What part in Nim would be `nil` here where Rust would have `Option`? The difference between `Option` and `&Texture` is that you have to somehow deal with the possibility of no texture when handling the former.

[1] I should note that actual indexing behavior (`list[index]`) will assume you know there is one in there and panic if it isn't. This is one of the things I dislike and hope there will be an optional (no pun intended) lint post-1.0.

Re: Nim binary size from 160 KB to 150 Bytes

#64

Post by duaneb »

dom96 wrote: post #12
teh wrote: post #5

Today I looked at Nim in a bit more depth because it keeps popping up. I have a slightly uncomfortable feeling about it that I hope is unfounded! To me it looks like it makes the unsafety of c more accessible because of better tooling and nicer syntax. Looking at e.g. [1] there are still pointers, null-pointers etc, just like in c. So now you have a language that looks superficially simple but is actually very danger…

You are correct in saying that Nim does have C style pointers (ptr keyword). These are unsafe, but are meant to be used as part of the FFI. So when developing ordinary applications you should not be using them, unless you absolutely have to. Nim also has references (ref keyword) which are traced by the GC and therefore safe.

Does nim allow statically flagging procedures as unsafe to assist in the separation of ffi and safe procedures?

Re: Nim binary size from 160 KB to 150 Bytes

#66

Post by k__ »

ilitirit wrote: post #37

I've tried Rust, Nim and Go and I prefer Nim. But this could also be because of my background as a C/C++ programmer, and my particular requirements (general purpose programming language that doesn't try to hold my hand too much). There are things I don't like about the language (eg. case-insensitivity), but overall if I had to choose a newish language for a new task, I'd choose Nim over Rust and Go. (However, if you…

Do you have some directions on the WinAPI in Nim?

I felt a bit overwhelmed with the whole wrapping thing.

Re: Nim binary size from 160 KB to 150 Bytes

#67

Post by mikhailt »

Fastidious wrote: post #39

I read this, and wonder why software has gotten so fat? Any simple application these days is easily on the few dozen of MB, most a few hundred, with a few on a few GB in size. Why aren't we streamlining software to reduce its size? I understand we have gotten "rich" on storage, but if the trend continues... I am sure many portable devices would benefit if applications were trimmed down.

For me, it is easy to understand why, it has to do with shipping code sooner to your customers. It takes a lot of resources and time to optimize your code and the longer your customers have to wait, the more money you lose. In many cases, the extra size is due to frameworks added to the programs to speed up the development.

Frameworks tend to be heavy in size because it needs to accommodate various tasks as well as many platforms it can support. It's not easy to make them modular, so you can pick what you want and leave the rest out to shrink down the size.

For customers, would you rather wait a few days to get a certain feature that works out good enough in a few days or would you rather wait a few months for a feature that works great?

The competition is intense, wait too long to ship a feature and you lose to competitors that managed to get it out sooner than you. So, it's tough to balance each feature and tough to say no to customers, so that you could stay focused and lean.

Re: Nim binary size from 160 KB to 150 Bytes

#69

Post by ilitirit »

k__ wrote: post #66
ilitirit wrote: post #37

I've tried Rust, Nim and Go and I prefer Nim. But this could also be because of my background as a C/C++ programmer, and my particular requirements (general purpose programming language that doesn't try to hold my hand too much). There are things I don't like about the language (eg. case-insensitivity), but overall if I had to choose a newish language for a new task, I'd choose Nim over Rust and Go. (However, if you…

Do you have some directions on the WinAPI in Nim? I felt a bit overwhelmed with the whole wrapping thing.

You don't have to wrap anything. It's exactly like using it from C, except maybe a bit easier/safer. Just import windows. Then you can write code like this:

    hWndMain = CreateWindowEx(
        WS_EX_TOPMOST,              # Optional window styles.
        CLASS_NAME,                 # Window class
        WINDOWNAME,                 # Window text
        windowStyles,               # Window style

        # Size and position
        centerX, centerY,
        APP_WIDTH, APP_HEIGHT,

        cast[HWND](nil),        # Parent window    
        cast[HMENU](nil),       # Menu
        hInstance,              # Instance handle
        cast[LPVOID](nil)       # Additional application data
        );
Post reply on HN