Nim binary size from 160 KB to 150 Bytes • Hacker News Board

Re: Nim binary size from 160 KB to 150 Bytes

#31

Post by tshepang » Mon, May 04, 2015, 3:41 PM UTC

simias wrote: post #20

steveklabnik wrote: post #16

Earlier quoted context omitted.

Rust isn't putting a lot of specific effort into embedded, but we already work on many embedded platforms. As the language matures, I expect that support to grow.

Embedded and especially bare-metal applications really are 2nd class citizens in the rust ecosystem though. You basically can't use cargo (or at least not without a whole bunch of hacks) and many important features for low-level code are still gated and won't be available for 1.0. I think it's a bit of a shame because that's basically the #1 differentiator with languages like Go or Java as far as I'm concerned. But b…

Why can't one use Cargo for bare-metal applications?

Re: Nim binary size from 160 KB to 150 Bytes

#32

Post by Dewie3 » Mon, May 04, 2015, 3:45 PM UTC

filwit wrote: post #19

steveklabnik wrote: post #15

Earlier quoted context omitted.

As for null in general, you can hear it from the horse's mouth here: http://www.infoq.com/presentations/Null-References-The-Billi... There are a number of ways to approach this topic, so I'll just give you one: in languages with more advanced static type systems, you try to encode as much semantic information as possible in the type. As you've said, the idea of null can be useful, so it deserves a place in the type s…

I agree the concept of 'non-nil' vars is very useful (and we have that in Nim), but I'm not entirely convinced by the rest of that argument. Namely, I don't agree that nil is rare enough to justify the verbosity Rust uses for it. Non-nil vars may be seen more often, but that doesn't mean nil vars aren't also often used, either. In Nim, both nil and non-nil vars are at roughly the same reach.. while in Rust non-nil va…

> I agree the concept of 'non-nil' vars is very useful (

non-zebra numbers[1] are also very useful. But why have a "non-zebra number" when I can just have plain numbers?

[1] A "number" which is either a number, or a zebra

Re: Nim binary size from 160 KB to 150 Bytes

#33

Post by steveklabnik » Mon, May 04, 2015, 3:47 PM UTC

tshepang wrote: post #31

simias wrote: post #20

Earlier quoted context omitted.

Embedded and especially bare-metal applications really are 2nd class citizens in the rust ecosystem though. You basically can't use cargo (or at least not without a whole bunch of hacks) and many important features for low-level code are still gated and won't be available for 1.0. I think it's a bit of a shame because that's basically the #1 differentiator with languages like Go or Java as far as I'm concerned. But b…

Why can't one use Cargo for bare-metal applications?

See all the extra work that had to be done here: https://github.com/Ogeon/rust-on-raspberry-pi

Re: Nim binary size from 160 KB to 150 Bytes

#34

Post by bonesmoses » Mon, May 04, 2015, 3:54 PM UTC

I like the end result. However, it makes me wonder just why it's so acceptable that simple programs like this even compile down to a 160KB executable in the first place.

The actual active code is essentially some text and an interrupt. That much, at least, should be language independent. Are modern compilers incapable of discarding unreferenced code, or am I missing something?

Re: Nim binary size from 160 KB to 150 Bytes

#35

Post by polyfractal » Mon, May 04, 2015, 4:09 PM UTC

filwit wrote: post #30

polyfractal wrote: post #18

Earlier quoted context omitted.

It's not so much about "never nil" , but rather "never accidentally null" . Rust's compiler prevents you from moving data into a method which then nulls it out, leaving a dangling pointer in the calling code. At best this dangling pointer will look at garbage and cause a crash or undefined behavior. At worst, it will look at other, actively-used memory and cause a security vulnerability. Rust will just refuse to comp…

> Rust's compiler prevents you from moving data into a method which then nulls it out Just for clarity, we have this in Nim too, eg: type Foo = ref object Bar = object val: Foo not nil let f = Bar() # Error, 'val' must be set proc foobar(f: Foo not nil): Foo not nil = return nil # Error, can't return nil foobar(nil) # Error, can't pass nil > At best this dangling pointer will look at garbage and cause a crash or unde…

Oh, sorry, I should have been clearer: I wasn't trying to disparage Nim at all (it's on my list of languages to play with). I was just clearing up some points about Rust :)

Edit:

> Well I was not talking about iterating through a list, but rather maintaining arbitrary indexes to a mutable list. Eg, a Sprite which contains a index to a Texture array. In that scenario it's just as easy to miscalculate and crash your program via a bounds-checking error as it is to crash by nil-deref.

The solution here is to just use a reference instead of an arbitrary index. If you hand out references you can lean on the compiler to enforce memory safety -- the compiler won't let you access data that is no longer alive, won't let you accidentally share across thread boundaries if you don't explicitly want that, etc. And if that was a shared mutable list, it's doubly important to let the compiler help you reason about it, since shared, mutable state is the main source of data races.

This is one of those cases where leveraging the compiler allows you to write better, safer code.

Re: Nim binary size from 160 KB to 150 Bytes

#36

Post by filwit » Mon, May 04, 2015, 4:16 PM UTC

pcwalton wrote: post #22

filwit wrote: post #13

Earlier quoted context omitted.

So Rust has some cool safety features, especially for concurrent code. But, and perhaps I'm just uninformed, I never really understood the safety benefit of Rust's 'never nil' design. Nil is a useful modelling tool, even in Rust where it exists via Option /None, correct? Perhaps by forcing you to be extremely explicit (and enforcing `match` always handles all conditions) you gain some arguable safety, but at what cos…

> Nil is a useful modelling tool, even in Rust where it exists via Option /None, correct? It's not that null is not useful. It's that most pointers can never be null, so nullability is the wrong default. And it is useful for the compiler to force you to handle the case in which pointers are null. > Perhaps by forcing you to be extremely explicit (and enforcing `match` always handles all conditions) you gain some argu…

> it is useful for the compiler to force you to handle the case in which pointers are null.

Well I agree that it's very useful (and we have that in Nim), but..

> With constructs like Option::map the code is usually even less verbose than the equivalent code with null.

I'm still not convinced of this part. It certainly hasn't been the case with the, admittedly small amount of, Rust code I've seen. However, I'll look for more comparisons in the future (or offer Nim comparisons to Rust snippets anyone posts). Point is, nil is still a useful and commonly used tool. So the argument for verbosity and conveniences is relevant, IMO.

> With null, the semantics of the language are that an exception can be thrown [1] whenever those constructs are invoked. That's pretty much objectively easier to reason about.

That completely depends on how often you want to use nil refs, and how easy they are to use. Like I said in another response, I agree Rust's design may be better for some domains, but I certainly wouldn't call it "objectively" easier to reason about in a general sense.

> Huh? Lifetimes are totally independent.

Well like my post implied, I was only guessing as to the design. And it's interesting to hear that it takes advantages of special compiler optimizations. That said, I still don't see how it's completely decoupled from the life-time system.. you're saying that if I have a Option reference to a mutable list in Rust, the compiler can determine weather or not the list is 'frozen' based on the runtime state of that reference?

> Or you could do what Nim does, and make dereferencing null undefined behavior.

I didn't think derefing nil was undefined behavior. I thought only dereferencing a pointer which points to once-valid-but-now-free memory was undefined behavior, and that situation is covered by GCed refs. Can you explain this a bit?

EDIT:

> Not in my experience. They show up in production all the time.

I did say 'rarely', and I drew a comparison to bounds-check crashes, which surely also show up in production.

Re: Nim binary size from 160 KB to 150 Bytes

#37

Post by ilitirit » Mon, May 04, 2015, 4:17 PM UTC

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 threw D into the equation I'd probably go with D simply because I feel it's slightly more mature).

Incidentally, the way I tried to teach myself Nim (and to see if the language was usable for creating small Windows apps) was to write a WinApi program. It took about the same or less effort as what it would have taken me in C/C++, but it just felt much safer and more pleasant to work with.

Re: Nim binary size from 160 KB to 150 Bytes

#38

Post by filwit » Mon, May 04, 2015, 4:18 PM UTC

polyfractal wrote: post #35

filwit wrote: post #30

Earlier quoted context omitted.

> Rust's compiler prevents you from moving data into a method which then nulls it out Just for clarity, we have this in Nim too, eg: type Foo = ref object Bar = object val: Foo not nil let f = Bar() # Error, 'val' must be set proc foobar(f: Foo not nil): Foo not nil = return nil # Error, can't return nil foobar(nil) # Error, can't pass nil > At best this dangling pointer will look at garbage and cause a crash or unde…

Oh, sorry, I should have been clearer: I wasn't trying to disparage Nim at all (it's on my list of languages to play with). I was just clearing up some points about Rust :) Edit: > Well I was not talking about iterating through a list, but rather maintaining arbitrary indexes to a mutable list. Eg, a Sprite which contains a index to a Texture array. In that scenario it's just as easy to miscalculate and crash your pr…

No worries. I also wasn't implying you where trying to discourage Nim, and I hope my post didn't come off as accusatory. Cheers!

EDIT:

> The solution here is to just use a reference instead of an arbitrary index.

Ah, sorry I should have said "mutable Texture array". In that case Rust's borrow-checking will 'freeze' the array, preventing Textures from ever being changed during the lifetime of your Sprites. So you're left with either Option or indexing as a solution, each with it's own merits, but neither as.. practical as nilable GCed references, IMO (again, just my opinion.. others seem to find it easy enough).

Re: Nim binary size from 160 KB to 150 Bytes

#39

Post by Fastidious » Mon, May 04, 2015, 4:24 PM UTC

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.

Re: Nim binary size from 160 KB to 150 Bytes

#40

Post by level » Mon, May 04, 2015, 4:24 PM UTC

_blrj wrote: post #10

I love these articles; I make sure to bookmark them just in case one day I want to build binaries that do nothing.

In case you haven't seen it, here's a similar article on making a tiny ELF executable. [1]

[1] http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...