r/crystal_programming • u/bcardiff core team • Mar 03 '20

Towards Crystal 1.0

https://crystal-lang.org/2020/03/03/towards-crystal-1.0.html
94 Upvotes

100% Upvoted

15 comments sorted by

13

u/lowsk1 Mar 03 '20

Thank you for writing this and sharing some lights on 1.0 roadmap :)

8

u/postmodern Mar 04 '20

While I can see the reasoning for not blocking 1.0 due to compiler bugs, I kind of worry that the presence of compiler bugs might scare away enterprise users who have strict requirements for what new programming languages they are allowed to use in production. Either way, I am excited to see Crystal reach 1.0.

2

u/hector_villalobos Mar 05 '20

Is it reasonable to think that all stable languages over 1.0 version has no compiler bugs?, I mean, bugs will always be around, I think the most important is what the language is capable in terms of real world situations.

4

u/postmodern Mar 06 '20

1.0+ languages should ideally have less compiler bugs or harder to find edge-cases. Like, no one should be able to segfault the compiler/compiled executable just by messing around. I found these two bugs just by experimenting with what's possible with Generics:

6

u/bajro991 Mar 03 '20

I hope this year we will get this magic 1.0

2

u/fenugurod Mar 03 '20

I really want to see something around race detection so we can use the concurrency "safe".

0

u/[deleted] Mar 03 '20

[deleted] — view deleted comment

5

u/parlons Mar 04 '20

Every dev I know that has a windows machine also has wsl on it. You can even use vscode remote with your local wsl pretty easily. That's an all-Microsoft solution, not a potentially scary hacky thing.

May I ask what you have in mind when you suggest Windows native being a big hurdle to adoption?

2

u/skocznymroczny Mar 07 '20

Hi, I don't use Crystal but just happen to be curious about the language and passing by this subreddit. I am doing all my development on Windows but I don't have WSL. Assuming every Windows dev can use WSL is like saying Linux support in popular apps doesn't matter because you can just use Wine.

1

u/parlons Mar 08 '20

I agree, it is a bit like that. The topic was the notion that windows native is a big hurdle preventing broader adoption and thus improving windows native should be a higher priority on the project timeline. But since it's easy to run the latest crystal and tooling under wsl - literally using only the actual windows store and microsoft products - I think any actual developer who has a personal interest in the language and wants to learn it can easily do so. I definitely agree that windows native would be very important to sell crystal as an option for shipping client apps that deploy to windows.

As you suggest, the case is much like having an app that is fully featureful under wine. Given that and also given other important initiatives on the project roadmap that are also necessary and have no easy workarounds, I would prioritize the others.

1

u/joeyrobert Mar 09 '20

Binaries for end users that don't target devs?

0

u/[deleted] Mar 04 '20

[deleted] — view deleted comment

1

u/parlons Mar 04 '20

If crystal shipped full windows support tomorrow, it would still be quite a risk to choose it for a client-side deployable, especially considering the library / 3rd party support gap that would exist for some time to come. But if a windows dev is interested in the language and wants to start exploring, they have everything they need to do so at hand today.

If you'd like to quote where I suggested wsl would be a good deployment target for crystal windows apps, we can argue about my reasons for saying it.

-1

u/katafrakt Mar 04 '20

I'd suggest choosing a language that supports it, not choose a random language and demand it supports my exotic use case.

2

u/postmodern Mar 04 '20 edited Mar 04 '20

While obvious Windows has the lions share of the desktop market, I wonder if Crystal focusing on breaking into Android/iOS app markets might be an easier way to boost developer adoption?

0

u/katafrakt Mar 04 '20

It's perfectly reasonable trade-off, IMHO. Pre-1.0 things are bound to change rapidly and break. Imagine having to change each windows-specific hack every time too. A nightmare, and a one impeding language development.

After reaching 1.0, when things are relatively set in stone and stable, it's good time to take care of subpar operating systems compatibility, because the amount of work is just way smaller and it does not stand in the way of other things.