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

Lily: An interpreted language with a focus on expressiveness and type safety

lily-lang.org

Post reply on HN
Print view View original

11–20 of 55 posts

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#11

Post by nickpsecurity »

weberc2 wrote: post #8
nickpsecurity wrote: post #2

Prior art like Wirth's or Modula-3 language added a minimal amount of features like exceptions or some OOP on top of simple, efficient, systems languages. Usually have a GC but many prefer ref counting for efficiency. This seems like that kind of thinking in an interpreted language. Just going by what's on the front page: didn't dig deep into it or anything. Interesting project.

Reference counting isn't more efficient than GC; usually the value of reference counting is that it's deterministic and you can bind finalizers to them (with traditional GC, finalizers run when GC runs which may not even happen). The canonical example is a file object that closes its operating system file when the object is no longer used; this is nice in theory, but as the Python folks found out, not a good substitu…

Oh yeah, my mistake. I should've said predictable, not efficient. I remember people liked it to avoid long pauses coming out of nowhere.

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#13

Post by rishav_sharan »

koube wrote: post #3

Maybe off topic, but I do a lot of ad-hoc python scripts where I drop scripts everywhere in my filesystem, but I need dependencies installed in a virtualenv so my ad-hoc scripts can access them. The problem I'm having is that sometimes things will run for a whole day and then fail at the end because of a typo or something. I've been looking at other languages to see if there's a language like python but type checked,…

Nim lang. Nothing would beat it if you like python

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#14

Post by falcor84 »

koube wrote: post #3

Maybe off topic, but I do a lot of ad-hoc python scripts where I drop scripts everywhere in my filesystem, but I need dependencies installed in a virtualenv so my ad-hoc scripts can access them. The problem I'm having is that sometimes things will run for a whole day and then fail at the end because of a typo or something. I've been looking at other languages to see if there's a language like python but type checked,…

I suppose that print statement was just a silly example, but just in case this may be of use to anyone, note that you can pass multiple arguments to print and they will be printed space-separated, each converted to a str, so you will (practically) never run into type errors.

print(str, int)

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#15

Post by blattimwind »

nickpsecurity wrote: post #11
weberc2 wrote: post #8

Earlier quoted context omitted.

Reference counting isn't more efficient than GC; usually the value of reference counting is that it's deterministic and you can bind finalizers to them (with traditional GC, finalizers run when GC runs which may not even happen). The canonical example is a file object that closes its operating system file when the object is no longer used; this is nice in theory, but as the Python folks found out, not a good substitu…

Oh yeah, my mistake. I should've said predictable, not efficient. I remember people liked it to avoid long pauses coming out of nowhere.

With (naive) ARC you can still get long pauses "seemingly out of nowhere", e.g. when a large object tree goes out of scope.

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#16

Post by koube »

falcor84 wrote: post #14
koube wrote: post #3

Maybe off topic, but I do a lot of ad-hoc python scripts where I drop scripts everywhere in my filesystem, but I need dependencies installed in a virtualenv so my ad-hoc scripts can access them. The problem I'm having is that sometimes things will run for a whole day and then fail at the end because of a typo or something. I've been looking at other languages to see if there's a language like python but type checked,…

I suppose that print statement was just a silly example, but just in case this may be of use to anyone, note that you can pass multiple arguments to print and they will be printed space-separated, each converted to a str, so you will (practically) never run into type errors. print(str, int)

True, that's a problem I don't have anymore but it's a quick and understandable example of a mistake that I think lots of people had made before.

Instead of a comma I would actually recommend f-strings, which are python's string interpolation. The only downside is that the code within the f-strings I think have even less prechecking.

https://www.python.org/dev/peps/pep-0498/

Example: print(f"There are {len(lights)} lights!")

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#17

Post by gwking »

weberc2 wrote: post #8
nickpsecurity wrote: post #2

Prior art like Wirth's or Modula-3 language added a minimal amount of features like exceptions or some OOP on top of simple, efficient, systems languages. Usually have a GC but many prefer ref counting for efficiency. This seems like that kind of thinking in an interpreted language. Just going by what's on the front page: didn't dig deep into it or anything. Interesting project.

Reference counting isn't more efficient than GC; usually the value of reference counting is that it's deterministic and you can bind finalizers to them (with traditional GC, finalizers run when GC runs which may not even happen). The canonical example is a file object that closes its operating system file when the object is no longer used; this is nice in theory, but as the Python folks found out, not a good substitu…

The other recurring example for me was OpenGL resources like textures (this was in ObjC). Again, it turned out not to work so while once I got into more complicated examples, because of ordering issues: my GLWindow instance would get deallocated, and my refcounted GLTexture class would then get finalized after the underlying CGLContext was gone, or just not the active context. I started coming up with more elaborate schemes to deal with it but then it no longer felt elegant.

There is one other aspect of RC systems that I have come to appreciate but never seen anyone else write about: they play well with each other. It's fairly trivial to create foreign object wrappers for python and objective-c in both directions, that each call the appropriate refcount ops of the foreign system. You can then have allocated data structures referring back and forth across the language bridges and when you abandon the root, everything deallocates properly and deterministically in both runtimes. I do not have much experience with GC runtimes and their FFIs but from what I've read I suspect this might be trickier to reason about. This is an obscure point, but one that I did find interesting in terms of language interop.

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#18

Post by yaccz »

koube wrote: post #3

Maybe off topic, but I do a lot of ad-hoc python scripts where I drop scripts everywhere in my filesystem, but I need dependencies installed in a virtualenv so my ad-hoc scripts can access them. The problem I'm having is that sometimes things will run for a whole day and then fail at the end because of a typo or something. I've been looking at other languages to see if there's a language like python but type checked,…

Your first mistake is dropping those scripts everywhere. Name them sanely and drop them somwhere in PATH. Add your own path to PATH just for these scripts if you don't have it already.

Your second mistake may be that you are writing python instead of a nice shell (eg. zsh is pretty good, way more powerful than bash) and ofloading to python only those parts that aint suitable for shell.

Now since you'd be offloading only sh-unsuitable parts as other programs, you can as well write them in whatever is best fit. Be it python, rust, c, haskell or whatever.

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#19

Post by yaccz »

losvedir wrote: post #9

One of the bullet points is "Abstract data types (with `Option` and `Result` predefined)." I wonder if they mean "Algebraic data type", since I have seen Option/Result before as an example of those, and they're both commonly abbreviated ADTs. Or maybe they're trying to get at a concept I'm missing here?

ADTs are not neccessary to implement Option.

Re: Lily: An interpreted language with a focus on expressiveness and type safety

#20

Post by dmux »

the_duke wrote: post #7
koube wrote: post #3

Maybe off topic, but I do a lot of ad-hoc python scripts where I drop scripts everywhere in my filesystem, but I need dependencies installed in a virtualenv so my ad-hoc scripts can access them. The problem I'm having is that sometimes things will run for a whole day and then fail at the end because of a typo or something. I've been looking at other languages to see if there's a language like python but type checked,…

It was weird for me at first, but actually Rust provides a great solution here. With https://github.com/DanielKeep/cargo-script you can have single file Rust "scripts" with ecosystem dependencies. When executing the file (via the cargo-script wrapper), dependencies are fetched and a binary is compiled on demand (and cached for re-runs). It's pretty awesome for scripts where type safety is important. #!/usr/bin/env ru…

Likewise with Apache Groovy, which has optional typing:

    #!/usr/bin/env groovy
    // @Grab annotation won't work in scripts
    import static groovy.grape.Grape.grab
    grab(group: 'org.apache.commons', module: 'commons-csv', version: '1.5')
    
    println "Starting to parse CSV"
Post reply on HN