Live data from Hacker News

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

lily-lang.org

51–55 of 55 posts

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

#51
post #10
post #5

Earlier quoted context omitted.

Depending what you want, using go run source.go gives you the compile time checks, while still giving you the source code visibility and simplicity of scripts

I took a look at Go but it seems to be more of a systems language than a scripting language and I assume that means it's less amendable to "This guy across the country needs this information in 2 hours max".

People say that about Go while I don’t have an opinion. I don’t understand what you mean by your example

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

#52

Earlier quoted context omitted.

But from what I've seen, most idiomatic Rust code doesn't use the `map[key]` syntax, but instead uses `map.get(key)`.

We must look at very different code :)

I actually didn't realize it was doable (not a heavy rust user - just an enthusiast). Kinda hidden away in docs under an example [0] and isn't in the book under hash maps [1]. Might be worth calling out somewhere explicitly? People getting started with rust probably aren't familiar with the trait-based operator overloading system yet.

[0] https://doc.rust-lang.org/std/collections/struct.HashMap.htm... [1] https://doc.rust-lang.org/book/second-edition/ch08-03-hash-m...

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

#53
post #52

Earlier quoted context omitted.

We must look at very different code :)

I actually didn't realize it was doable (not a heavy rust user - just an enthusiast). Kinda hidden away in docs under an example [0] and isn't in the book under hash maps [1]. Might be worth calling out somewhere explicitly? People getting started with rust probably aren't familiar with the trait-based operator overloading system yet. [0] https://doc.rust-lang.org/std/collections/struct.HashMap.htm... [1] https://doc…

Yeah, might be worth it on the API docs, for sure. Maybe file a bug? :)

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

#54
post #10

Earlier quoted context omitted.

I took a look at Go but it seems to be more of a systems language than a scripting language and I assume that means it's less amendable to "This guy across the country needs this information in 2 hours max".

People say that about Go while I don’t have an opinion. I don’t understand what you mean by your example

The point of my example is that my main priority is coding speed, and other things are an issue only if processing takes a long time. A systems language typically has a much slower coding speed than say, python, which is what I mainly use now.

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

#55
post #16

Earlier quoted context omitted.

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)} l…

I absolutely agree that f-strings are excellent for formatting, but I don't quite understand why you would use formatting in a regular print statement, when you could just stick to the commas and let the concatenation happen naturally in the output buffer?

print("There are", len(lights), "lights!")

Post reply on HN