paulcsmith

Right now I'd say we need to make it easier to work with nested params so you can easily save Parent + (n) children. Easier handling of uploaded files is another big one. It's being actively worked on right now. There are a few more escape hatches that are needed when you need to break out of the framework. But overall it is fairly full featured.

You can check out our roadmap to 1.0 here: https://docs.google.com/document/d/1EYzx37Kq5h7iLH9SQTFyXNwb...

Hello! I'm the creator of the Lucky web framework https://luckyframework.org. I've been building it for about 3 years and we've got a number of people using it in production.

It still lacks some features found in bigger frameworks, but is nearing 1.0 and gaining many new contributors that are helping us fill in the gaps.

Feel free to hop on our chatroom to ask questions about it. We try to be super friendly and love answering questions and getting feedback https://gitter.im/luckyframework/Lobby

author of Lucky here. Would love to hear what you don't like about Lucky's ORM (Avram). It is not quite as feature complete as ActiveRecord, but in some ways it has more features (like being able to do more advanced queries in Crystal `>`, `ILIKE`, etc.

Totally agree. If this happened post 1.0 I’d be concerned. But pre 1.0 this is what I’d expect and want. Polish things up because afterward you can’t!

This looks awesome! What backend framework are you using? I'm the author Lucky and was wondering if you happened to use it on the backend since you are using Crystal

I'm Paul, the creator of Lucky.

If you have any questions or feedback let me know. Always happy to help.

If you want to chat about Lucky feel free to hop on https://gitter.im/luckyframework/Lobby

Author of Lucky here. The title may have been a bit misleading. Lucky is not Ruby on Rails for Crystal. It has a different take on nearly everything in Rails, but it aims to solve the same problems: make web development fun and productive.

But it also adds: and make writing fast applications easy, and prevents bug from making it to production.

If you use Lucky now, you will be missing the vast ecosystem that Ruby and Rails provide, but I think that is a temporary problem. Lucky and Crystal are growing quite quickly.

I agree. I've been using Rails for 12 years and it is my second favorite framework :)

Lucky and Crystal are missing the ecosystem, which the article mentions, but it also adds a lot that Rails is missing. Lucky is much much faster and the speed is effortless. Rails can be fast, but based on my experience so far, you have to do some work to get reasonable speeds.

Lucky and Crystal have also caught a lot of bugs, which makes development much more pleasurable, and happier customers.

Right now, it probably takes longer to use Lucky and Crystal. Like you said, the ecosystem is lacking so you often have to write code that Ruby would have a gem for, but in the long term, this will be solved. I'm very confident of that.

I do not think Lucky is Ruby on Rails for Crystal. There are new patterns for just about everything. Routing is different, querying is different, views are very different.

It is Rails-like in the sense that it is aimed at productivity and developer happiness and that it aims to have most of what you need in one package.

Of course Ruby has a better ecosystem, this is mentioned in the article. Lucky (and Crystal) have a long way to go, but things are progressing rather quickly

I'm glad you were pleasantly surprised. Feel free to hop on https://gitter.im/luckyframework/Lobby if you have any questions or comments!

You can use Lucky without a database, but if you use one, Postgres is the only support database.

You don't need node or yarn if you are using API mode. You can generate an API only app with `lucky init <app-name> --api`

The process manager is used to start the watcher process. You can use Lucky without it by running `lucky watch` instead of `lucky dev`, but using the process manager is nice because you can also run asset compilation, job queues and whatever other processes you app needs to run.

Lucky can be stripped down further still, but the documentation focuses on the more opinionated route

I've played around with a number of languages and settled on Crystal because:

* Speed

* Pleasant to use type system

* Doesn't get in my way

* Catches lots of bugs

* Fun!

I wrote http://luckyframework.org/ to write web applications with minimal boilerplate and as few runtime errors as possible. Take a look and let me know what you think

Hey HN!

I'm Paul Smith, the creator of Lucky.

I created Lucky because I wanted a framework that was fast, fun, productive, and caught lots of bugs that I would normally miss.

I'm happy to answer any question you have!

Hi HN,

Lucky is a web framework written in Crystal that helps you build web apps quickly, catches bugs for you, and runs incredibly fast.

This article explains how actions and routes are built to catch as many bugs as possible and help make development easy.

Let me know what you think :)

Can you explain a bit more what you mean? What advantages do "Python variety" lists give you over what Elixir does with lists and tuples?

This totally makes sense. I think the disadvantage is that this is done at runtime, but assuming you have a test that hits it, it would catch the bug.

My colleagues wrote a library that does something like this. You may want to check it out: https://github.com/thoughtbot/wrapped

And for a Ruby/Elixir/dynamic lang programmer just catching `nil` is actually a pretty big win, even without the custom type.

I will go more into depth about leveraging the type system with Lucky for even better data modeling in one of the Lucky guides

TL;DR I totally agree. This can be done with Crystal and Lucky but I wanted to keep the example simple.

I totally agree with your sentiment and you have a lot of great points. This post was not meant to get too deep into things right off the bat, so it left off a lot of this stuff.

In this case the phone number always has a country code with +1 because we have a validation that ensures it won't make it into the database without it. We also only accept US country codes in the validation.

I get your point though that just having a `String` doesn't really guarantee that those validations took place, luckily, LuckyRecord has the idea of custom types that can define their own casting and validation behavior. So we could have done this:

``` field phone : UnitedStatesPhoneNumber? ```

And it would validate that the string param is a valid US number before saving. It would also do that for queries and you could add whatever other type specific methods you want to it. so you could do

``` def formatted_fax_number phone.try { |number| number.without_country_code } end ```

But like I said, I think this is fitting for a whole separate post, rather than an intro style post :D

I've been working on https://luckyframework.org and I can say that meta programming is extremely powerful and much easier for me to use than either Ruby or Elixir.

You can see a bit of what the macro system enables here: https://robots.thoughtbot.com/lucky-an-experimental-new-web-...

It generates a bunch of query methods and type specific querying. Without the macro system this would have been impossible.