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

41–50 of 84 posts

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

#41

Post by ehsanu1 »

TylerE wrote: post #32
fedesilva wrote: post #21

Earlier quoted context omitted.

If I understand correctly once you stop using the GC, Nimrod is not memory safe. Rust is.

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

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

#42

Post by pjmlp »

skybrian wrote: post #39
klibertp wrote: post #26

Earlier quoted context omitted.

I looked at http://golangtutorials.blogspot.com/2011/06/interfaces-in-go... and the only new aspect of Go interfaces I see is that they are implicit - they are considered implemented if the type implements functions that interface defines and you don't need to explicitly write "implements Something". This is a handy shortcut, but it doesn't look like a "serious feature". It also looks a bit like polymorphic variants…

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.

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

#43

Post by beagle3 »

skybrian wrote: post #19
TheCoelacanth wrote: post #15

Earlier quoted context omitted.

Go basically only has one modern feature (goroutines). Beyond that it's a throwback to Java version 1.

Go interfaces are also new.

g++ had those years ago, maybe gcc 2.0 or something? Google results are all messed up with Protocol Buffers and stuff so I didn't find a good link.

Back when C++ didn't yet have templates, there were several suggestions about what kind of generics to implement and how. g++ implemented "protocols", which are basically the same as Go interfaces. I think this was eventually considered (and refused) in C++ as "concepts", but I might be mistaken. Templates are more general and can be kludged to implement protocols - which is probably the reason they won out in the C++ standardization race.

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

#44

Post by DorianMarie »

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.

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

#45

Post by klibertp »

skybrian wrote: post #39
klibertp wrote: post #26

Earlier quoted context omitted.

I looked at http://golangtutorials.blogspot.com/2011/06/interfaces-in-go... and the only new aspect of Go interfaces I see is that they are implicit - they are considered implemented if the type implements functions that interface defines and you don't need to explicitly write "implements Something". This is a handy shortcut, but it doesn't look like a "serious feature". It also looks a bit like polymorphic variants…

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…

I don't want to sound dismissive, but I think very few people here would like to "contrast with Java". We're (I am for sure) thinking more along the lines of comparing with Rust, OCaml, Haskell or Scala. Or Opa. Or Felix. Or Ur/Web. Or any number of modern languages implementing rich type systems.

Anyway, I believe this feature is very handy. It's not "new" however. As noted, OCaml objects - and also modules - support structure typing too. And you can't call OCaml a new language. Scala supports it too, in more than one way. And so on.

Also, compared to powerful and extremely rich type-systems that these other languages got Go's seems rather limited. What I meant by interfaces not being a "serious feature" - I should have said it differently, I know - was that compared to other features of modern type systems it's not that significant. I get a feeling that it only looks like it is in Go because it lacks those other features.

And BTW, that's a concious decision of language designers to keep the language simple. I don't say it's a bad decision, either. I just want to note that Go indeed is simple (at least in regard of types) and not that innovative. And also that using Java as a baseline is not the most ambitious thing to do. ;)

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

#46

Post by groovy2shoes »

klibertp wrote: post #26
skybrian wrote: post #19

Earlier quoted context omitted.

Go interfaces are also new.

I looked at http://golangtutorials.blogspot.com/2011/06/interfaces-in-go... and the only new aspect of Go interfaces I see is that they are implicit - they are considered implemented if the type implements functions that interface defines and you don't need to explicitly write "implements Something". This is a handy shortcut, but it doesn't look like a "serious feature". It also looks a bit like polymorphic variants…

> the only new aspect of Go interfaces I see is that they are implicit

This is not a new thing. Structural subtyping has been around since the earliest formal treatments of subtyping in the early 80s. OCaml's subtyping relation is structural.

There's a related notion of row polymorphism that was first formalized in the late 80s. As far as I know, it hasn't been widely adopted, but is the subject of ML Poly/R. Elm's extensible records also seem similar. Row polymorphism is also an important concept when dealing with typed concatenative languages, like Joy and Cat.

Really, Go brings nothing new to the table. It is a synthesis of (mostly) good ideas. Unfortunately, it also forgoes other good ideas (parametric polymorphism, sum types, and pattern matching come to mind). The goodness of exceptions is, of course, debated.

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

#47

Post by TylerE »

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

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.

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

#48

Post by lmm »

idlewan wrote: post #3

I really enjoy the language so far. For me, it's the perfect middleground between C and python: a fast compiled language, and one where you can be as productive as in python. I also tend to prefer catching errors early, and having a typed language that warns and errors at compile-time is great.

Do you know how it compares to a modern typed functional language - Haskell, OCaml, F# or Scala?

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

#49

Post by TylerE »

lmm wrote: post #48
idlewan wrote: post #3

I really enjoy the language so far. For me, it's the perfect middleground between C and python: a fast compiled language, and one where you can be as productive as in python. I also tend to prefer catching errors early, and having a typed language that warns and errors at compile-time is great.

Do you know how it compares to a modern typed functional language - Haskell, OCaml, F# or Scala?

Ocaml with better metaprogramming, an actually helpful compiler, and syntax that doesn't feel like having your eyes gouged out by a rusty spoon.

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

#50

Post by breuleux »

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.

Post reply on HN