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

Nimrod: A New Approach to Metaprogramming [video]

infoq.com

Post reply on HN
Print view View original

51–60 of 84 posts

Re: Nimrod: A New Approach to Metaprogramming [video]

#51

Post by hcarvalhoalves »

girvo wrote: post #35
hcarvalhoalves wrote: post #14

Earlier quoted context omitted.

I've found some (arguably minor) things to be kinda messy. Maybe the result of a one-person language that grows too much before getting some feedback. 1) Everything is (strangely) called a procedure, and then there's syntax to differentiate arguments that will be modified in place (proc myproc(myarg : int, inplacearg : var int)). Kinda weird, and a lost opportunity to have checking for pure functions at compile time.…

Actual it does have a VM in the devel branch, and compiles as fast as Python runs now ;)

That will be cool to watch.

Re: Nimrod: A New Approach to Metaprogramming [video]

#52

Post by FG_Regulus »

ehsanu1 wrote: post #41
TylerE wrote: post #32

Earlier quoted context omitted.

There's really no reason not to use the GC though. It's very lightweight and quick.

While you're right for probably most classes of application, this is not an absolute truth. There are reasons not to use the GC - eg you're developing a browser, or a GC for a language, and many besides. I see a similar thread where you made a similar statement, so in favor of not rehashing that whole thread, here it is: https://news.ycombinator.com/item?id=7061533

And adding onto the other reply - Nimrod's GC has a realtime mode where you can specify when to run, and the maximum time. I made a (small) game in Nimrod and called the GC every frame for the remaining time (it can be used like a blocking high-accuracy timer). Testing the GC I couldn't get it to take longer than a couple microseconds - intentionally smashing my 16GB heap to hell. Why does a 16GB heap take so little time to GC? Because Nimrod's GC doesn't scale - it's deferred reference counting. Only cycle detections scan the whole heap, and you can disable those optionally (I do, I don't like designing cyclic stuff without explicitly knowing it gets broken).

Re: Nimrod: A New Approach to Metaprogramming [video]

#53

Post by ehsanu1 »

TylerE wrote: post #47
ehsanu1 wrote: post #41

Earlier quoted context omitted.

While you're right for probably most classes of application, this is not an absolute truth. There are reasons not to use the GC - eg you're developing a browser, or a GC for a language, and many besides. I see a similar thread where you made a similar statement, so in favor of not rehashing that whole thread, here it is: https://news.ycombinator.com/item?id=7061533

Oh, I strongly disagree with that logic. A browser is exactly the sort of situation where a GC is useful. I mean, it only took Mozilla 2 decades to get Firefox to not leak memory like a sieve.

`it only took Mozilla 2 decades to get Firefox to not leak memory like a sieve`

I'm sure you're aware that this is quite an unfair/exaggerated statement to make. But yes, I'm all in favor of language features that help prevent memory leaks.

But the reason the smart folks at Mozilla don't just switch to using a GC for all of Firefox (as do none of the other major browser vendors) is due to GC pauses sucking for user interaction. If you don't think that's a concern, or have a solution for it, please elaborate.

Re: Nimrod: A New Approach to Metaprogramming [video]

#54

Post by skybrian »

pjmlp wrote: post #42
skybrian wrote: post #39

Earlier quoted context omitted.

Actually it's a big improvement for large-scale programming due its effect on library dependencies. In Go you can easily declare an interface that matches a type in someone else's library without creating a hard dependency on that library. You can also superset and subset interfaces easily. That way you get loose coupling (almost like "duck-typing") in a mostly statically checked language. Contrast with Java where yo…

On the other hand when looking at type X you don't don't which set of interfaces it supports. Not very good for large scale programming, I would say. As for comparing with Java, well, yes it is true. However there are plenty of strong typed languages which offer similar capabilities.

I don't think it matters that much from a library maintainer's point of view.

If you you want to change a public method and can find all the type's usages, an IDE or search engine can tell you which call sites will break. (Or just compile everything and see what happens.)

If you can't find all the type's usages, you're screwed anyway because any change that would break an interface will also break a call site that calls a method directly, without using an interface. So having all the interfaces declared right there doesn't help that much.

Re: Nimrod: A New Approach to Metaprogramming [video]

#55

Post by ehsanu1 »

FG_Regulus wrote: post #52
ehsanu1 wrote: post #41

Earlier quoted context omitted.

While you're right for probably most classes of application, this is not an absolute truth. There are reasons not to use the GC - eg you're developing a browser, or a GC for a language, and many besides. I see a similar thread where you made a similar statement, so in favor of not rehashing that whole thread, here it is: https://news.ycombinator.com/item?id=7061533

And adding onto the other reply - Nimrod's GC has a realtime mode where you can specify when to run, and the maximum time. I made a (small) game in Nimrod and called the GC every frame for the remaining time (it can be used like a blocking high-accuracy timer). Testing the GC I couldn't get it to take longer than a couple microseconds - intentionally smashing my 16GB heap to hell. Why does a 16GB heap take so little…

That's really cool! And yeah, doesn't scale as you said, so I still don't see how we can go GC-less for everything.

Re: Nimrod: A New Approach to Metaprogramming [video]

#56

Post by TylerE »

ehsanu1 wrote: post #53
TylerE wrote: post #47

Earlier quoted context omitted.

Oh, I strongly disagree with that logic. A browser is exactly the sort of situation where a GC is useful. I mean, it only took Mozilla 2 decades to get Firefox to not leak memory like a sieve.

`it only took Mozilla 2 decades to get Firefox to not leak memory like a sieve` I'm sure you're aware that this is quite an unfair/exaggerated statement to make. But yes, I'm all in favor of language features that help prevent memory leaks. But the reason the smart folks at Mozilla don't just switch to using a GC for all of Firefox (as do none of the other major browser vendors) is due to GC pauses sucking for user i…

I don't see how that's all that unfair. Development on the Mozilla codebase started in early 1998, almost 16 years ago.

Re: Nimrod: A New Approach to Metaprogramming [video]

#57

Post by bjornsing »

DorianMarie wrote: post #44
skrebbel wrote: post #8

I am very intrigued by Nimrod. The language seems to have goals that overlap with e.g. Rust, but with a bunch of really interesting design decisions (e.g. GC by default, but first class support for manual memory management). Given the amount of force driving Rust (and Rust's PR machine), compared to Nimrod which seems to be really pushed forward by one single person, I'm really impressed by how far Nimrod got. I real…

To support the fact it's mainly one guy: https://github.com/Araq/Nimrod/graphs/contributors His name is Andreas Rumpf and he is really impressive.

Yea, that's one of the most impressive 25-year-olds (?) I've ever seen... :)

Re: Nimrod: A New Approach to Metaprogramming [video]

#58

Post by mortyseinfeld »

breuleux wrote: post #50
rayiner wrote: post #6

On a related note, the most principled approach to macros for an infix language I've yet seen is Honu (brought to you by the Racket people): http://www.cs.utah.edu/plt/publications/gpce12-rf.pdf .

Funny you should say that, because I've been working on my own approach this month: https://github.com/breuleux/liso I'm probably going to post about it soon in more detail, if people are interested.

Wish it were a Intellij plugin and for Clojure instead of Racket. I'd buy it.

Re: Nimrod: A New Approach to Metaprogramming [video]

#59

Post by ehsanu1 »

TylerE wrote: post #56
ehsanu1 wrote: post #53

Earlier quoted context omitted.

`it only took Mozilla 2 decades to get Firefox to not leak memory like a sieve` I'm sure you're aware that this is quite an unfair/exaggerated statement to make. But yes, I'm all in favor of language features that help prevent memory leaks. But the reason the smart folks at Mozilla don't just switch to using a GC for all of Firefox (as do none of the other major browser vendors) is due to GC pauses sucking for user i…

I don't see how that's all that unfair. Development on the Mozilla codebase started in early 1998, almost 16 years ago.

Memory leaks waxed and waned as development focus changed. I remember Firefox's memory usage being quite decent around version 2, and even into 3. Later, some things got bloated, though a large part of the memory problem was due to misbehaving plugins. The memshrink project managed to fix even memory leaks across plugin authors' projects.

Also, note that a GC does not automatically mean no memory leaks. For instance, see how leaky Gmail is (was worse according to their dev team).

Re: Nimrod: A New Approach to Metaprogramming [video]

#60

Post by bjz_ »

TylerE wrote: post #47
ehsanu1 wrote: post #41

Earlier quoted context omitted.

While you're right for probably most classes of application, this is not an absolute truth. There are reasons not to use the GC - eg you're developing a browser, or a GC for a language, and many besides. I see a similar thread where you made a similar statement, so in favor of not rehashing that whole thread, here it is: https://news.ycombinator.com/item?id=7061533

Oh, I strongly disagree with that logic. A browser is exactly the sort of situation where a GC is useful. I mean, it only took Mozilla 2 decades to get Firefox to not leak memory like a sieve.

Well... isn't that the point of Rust? Preventing memory leaks without the need for GC?
Post reply on HN