Crystal is a programming language worth learning. It’s very fast and fun. I’ve noticed that it’s been two years, but no official version of 1. X has been released. What else needs to be done and how long will it take before the release of the official version? Will the standard library change significantly? I will finish the translation of crystal programming language, including syntax standard library and official Kemal web development framework.
There is this wiki page
Probably the most known and big parts of that are multithreading and Windows support.
Experimental multithreading support has already landed behind a compiler flag, however most of the standard library has not been updated with multithreading in mind yet.
Windows support judging just by the number of issues in done is 2/3 complete, but there wasn’t a lot progress in this area recently, at least not publicly visible on GitHub.
Well, I’d like to give a suggestion, because in my working community, many people have mentioned that this is a very good programming language, but its development is too slow.
My suggestion is that we can focus on creating a relatively perfect Linux version as the first stable version, so that some users can have enough confidence to use this Version to develop their enterprise applications, the language ecological construction will also develop faster.
Because the Windows version may take more time, we can continue to release version 2.x before adding in. I think it will be more beneficial to the development of this programming language if we move forward in such a gradual way. What do you think?
Because there is competition everywhere, including in the field of programming languages. We need to find a way to make the language survive and develop better.
Even Companies with the market cap of USD 1.3 Trillion, 1.2 Trillion, or 900 Billion took years before their programming language is anywhere to useable state.
The thing I think we learned from Ruby is that if Windows were not taken care of from Day 1, it might never actually arrive due to all the constrain you left in place during 1.0.
You’re right. Some support for Windows is better than none. However, there are certain things that are just as important as strategy.
First, how well a programming language develops depends on what features it has that appeal to users, such as being able to focus on one area better than others (for example, PHP is naturally web-focused, almost no one USES it for guis, but it has a lot of users and is popular).
Second, it is user-friendly. Do well enough in terms of stability and backwards compatibility. The stability of the language increases users’ confidence in it, while the downward compatibility allows the previous work to be preserved. Only through these efforts can the development of the language be sustainable.
In general, the success or failure of a programming language depends on whether it can solve certain kinds of problems better than other languages, which makes it outstanding in some aspects, so that it has the significance of existence, not optional. If we just wanted to be a big, universal programming language, we wouldn’t have a big enough team in the first place, which would lead to very slow language development. Second, there are already a lot of big languages out there (C#,D,kotlin, etc., and red in development) and we don’t have to spread our efforts too far to build a big language.
We can look for a future domain, focus on solving problems in that domain, or provide powerful technical solutions (e.g., Julia language, which is oriented towards scientific computing, and Nim, which is used for blockchain solutions). I think the focus of our work is to find the right time to make sure that we can always release a stability to solve some problems in the future, because there are already a lot of solutions to existing problems, and they are not bad.
Temporarily slow down the opening of a few minor feature points, fix the known bugs, and get the necessary functionality done. Focus on releasing a stable release so that the language can be put into production quickly. A large number of projects can help build the language ecosystem and attract more contributors to the community. I think this is an effective strategy to change the status quo and open up a new situation.
In addition, documentation of the programming language must be done well. This is very important, and Microsoft is very good at it. I want to make fun of the fact that our current official document is difficult for new users to read, although it is comprehensive but not well organized.
This is an interesting suggestion - and I created an account just to say so. C#, intentionally, is still really only a first class citizen on Windows. Swift has the same tie to Apple OSes. IF (conjecture) Crystal’s primary serious audience is, at least initially, Ruby developers (a safe assumption, IMO) then WHAT OS DO MOST RUBY DEVELOPERS USE IT ON?
You guys can do better research, but a quick search seems to point to Linux and maybe OSX. (https://www.quora.com/What-is-the-best-operating-system-for-developing-Ruby-on-Rails). In any case, the relevant quote from this link is “About 10% of the Rails community develops on Windows and the rest uses some form of Unix - OSX or Linux.”.
Strategically it is arguably NOT wise that the 90% should be left waiting for the 10%. Or, as the great thinker Goethe said, “The thing that matters most must not be at the mercy of the things that matter less.”
I don’t think running on Windows out of the gate is “the thing that matters most.” If you disagree, make your case but make it well because it is really risky to put off release 1.0 longer than is absolutely necessary to get a stable reference platform of the folks who are your likely primary audience – and I suggest those folks are writing Ruby on Linux and, maybe, MacOS.
Welcome to the forum! Hope you stay a for more than posting a single response
It’s correct that Crystal is especially attractive for developers with a Ruby background. But it’s still a different language, with different properties and capabilities. Compiling to native code makes a huge difference on how it can be used. And windows support is literally the single most requested feature we hear.
That being said, I believe that full windows support is technically not a strict necessity for 1.0.
But it’s paramount to make sure the stdlib API is fully portable and not closely tied to POSIX-isms. If we want to support windows eventually, we need to make sure now that the APIs can work for non-POSIX platforms without bending their knees.
And frankly, the best way to achieve that is simply port windows and while making it work, adjust the system APIs to be portable.
We’re actually quite far with that. Alongside the current progress with Process and Signal, the event loop is the main missing piece.
This strikes me as a product of our weird time.
Why do you think crystal is a better language today than it will be in 10 years?
Why does it need to be released soon?
Is there a deadline I don’t know about?
I agree, for various reasons.
First, the Windows platform will be more and more supported without doing anything, just based on the fact that windows 10 is the only supported Microsoft OS in the long run, and that it is shipped with a Linux binary support. That simple fact is enough to make me think about dropping this goal for the 1.x release. Not entirely sure it should be done, but still.
Second, as suggested on github, the web platform should be prioritized. It concerns everyone, even people on smartphones. Having great libraries to make reliable web applications could be a huge deal. Web Assembly definitively is, since we can compile a web assembly application that will run everywhere (even without a browser).
Finally, I think that OpenGL (and Vulcan) applications could be taken as first class citizens, even before Windows ones. Very few things are platform-specific there, and both native and web applications could profit from these libraries. If done correctly, any application with a GUI could take advantage of hardware acceleration. However, I do think that’s a massive amount of work and I’m not entirely sure we want to wait that long.
Aside from pure development, I do think that documentation should improve. I’ve seen a few libraries I use without proper explanation how to use them. OpenSSL documentation is definitively lacking, WebSocket and probably C bindings could be improved with a few more paragraphs, just to name some examples I encountered.
I understand that Ruby’s developers are the target audience here, and that they do wanted windows support for their language, but should they drive the Crystal development? I wasn’t a Ruby developer mainly because of the performance issue and their reputation for broken libraries. At least one Ruby developer on this forum said he won’t use Crystal until Kemal or another web framework will improve.
And a funny thing is, I don’t even like the Web. But that’s a strategic move.
Anyway, I don’t know the Windows support status. I agree that the Crystal development should not be rushed, but having a 1.x release send a message for developers: libraries are stable.
Thanks for the read.
Can you explain a bit about the event loop that is missing for Windows platform? If it really is the only thing to improve to have a windows support, that’s great.
I wonder, what do you think is the ETA?
The event loop is responsible for waking up fibers that are waiting for IO when they can read/send data. It’s not a public API, so not as important, but the internal interface needs some refactoring + win32 implementation. If you’re interested #6957 has some details on that.
If it really is the only thing to improve to have a windows support, that’s great.
Unfortunately, not quite. It’s probably the major missing feature to get a reasonably useful part of the stdlib working. And porting the compiler depends on that. There are still some other rough edges, however.
I wonder, what do you think is the ETA?
No idea, honestly. We’re making some progress, but the number of contributers working on windows support is quite small. And there’s still some uncertainty as to which road blocks we might encounter when going into the details of fixing bugs on windows. So far, most looks like it could be work out relatively well, but we can only tell when we get there.
Nim went through this same issue last year, and the devs finally relented (after an extreme push from its user community) and jumped from 0.20.x to 1.0.0, released on September 23, 2019 (currently at 1.0.4). Since then Nim has received allot more ''play" because, purely from human psychology, that 1.0.0 designation conveys an official sense of stability. And as a sometimes Nim user/learner, it’s still has allot of instabilities, and is under significant feature development, but it’s perfectly useable if you know what you’re doing.
I also agree Windows support isn’t, and should never be, a delay issue, since as pointed out, not just for Crystal, almost all OSS projects are developed and used on non-Windows system. And Microsoft has finally recognized that it can’t dictate this, and created WSL https://docs.microsoft.com/en-us/windows/wsl/about to directly run Linux software inside Windows without forcing Linux software developers/users to jump through too many hoops.
I also agree don’t try to be all things to all people straight out of the box. Pick spefic niches (Ruby used domains are logical ones to start) and do them better than anything else. Crystal (any language) has to compete to distinguish itself from everything else, especially since it doesn’t have a Google (Go), Mozilla (Rust), Apple (Swift) or Microsoft (C#) footing the bills.
You don’t ever have to be perfect, but you do have to be very good (near the best) at solving the problems to some group of people you should be marketing to.
If you made the decision to initially make Rails|webapps fly, well, that tells you what you technically need to focus on (which is probably something I would have considered doing).
Elixir spunoff from Ruby to provide concurrency for webapps by leveraging Erlang. Crystal doesn’t have to invent a new domain, it could steal this domain from Elixir|Ruby by giving Rail users all the speed and features Elixir provides and promises, but using good ole familiar (and I would say as similar as possible) syntax, vocabulary, and structure.
Tech people too much think that just: create the better technology and they will come. NOT! Microsoft still can’t get users to give up Windows 7, no matter how many times they threaten them with EOL notices. People get irrationally attached to things.
My tangible suggestions for 2020:
Create a fully functioning, kick-ass, easy to use, parallel/multi-threading framework.
Please, please, please, update, make accurate, and pay somebody if necessary, to create first-class documentation!
Attend Ruby, Elixer, Go, et al conferences, and market the hell about the real tangible benefits of using Crystal, by demonstrating how well it does specific things better than them (some controversy about this will be good for Crystal). Show that Sinatra, Hanami, Jekyll, etc equivalent in Crystal and watch their jaws drop.
My 2 cents.
First, we have to believe that the Crystal language is going to get better and better. Otherwise, what we are doing now will not be of great significance. In order to make it develop faster and better, we need to have a good development strategy (just like people’s career development plans, we must consider the long term enough to avoid unnecessary risks in the development process), we can’t just wait for the arrival of users, but still try to take some proactive strategies. If you want to take 10 years to release a stable 1.0 release, this may result in you missing out on any opportunities during that time.
Secondly, there is an old saying “strike while the iron is hot”. It’s easy to see why the shortcomings of the Ruby language give Crystal its natural advantage. With Ruby’s current popularity, we can get a significant number of developers at a very low cost. The reality is that for all reasons, Ruby is on the decline in general, and I won’t go into that.
Third, the number of programming languages in the world is already very large, and new languages may be born every year. Here, I quote a movie line “the world of kongfu, no firm not broken, only fast not broken”. If we move too slowly, some existing users may choose to leave, which we do not want to see. We need to create a momentum that keeps moving forward, a charm that keeps existing users.
Thanks for responding to this, as well as instigating my earlier comment. I kept starting a response myself and kept finding I was meandering into what I do for a living: applying “Theory of Constraints” to business impediments.
Let’s just say that beginnings, including launching of new programming languages, are very delicate things and the ability to discern the bottleneck in a process and artfully remove it at the right time/ right order is critical to the outcome. “Strike while the iron is hot” is a good truism; General Patton reputedly said “A good plan, violently executed today, is far better than a perfect plan next week.” If the market wasn’t ready for a Crystal, or Crystal wasn’t already pretty polished, I would say “keep polishing” – but I think, instead, the polishing for 1.0 can and should be completed with a sense of urgency instead of perfection. I trust the development team knows the trade-offs, as they have been wise in delaying a launch before now. But I think 2020 is an very auspicious year and if it is possible to announce 1.0 while keeping an assured development path for Windows to eventually get full support, I hope they will do that. And THEN I will take Crystal seriously as an option.
The language will always be in open beta, just like how Path of Exile is. Any catastrophic issues that arise after a “release”, will be reported on GitHub and the lead devs will fix it. For any language, not just Crystal. “Release” in context of software development in modern times is just a marketing gimmick and evolved into what is essentially a misnomer.
Crystal is used in production already, and I urge anyone who is thinking about using it, start now. Time is gold, don’t waste it
A number is just that a number. Crystal is relatively stable and mostly ready for production use. It’s evolving like any other language though. The question you should be asking is when will Crystal get the same commercial backing that Ruby has. Honestly I hope the answer is never. Right now the community is very friendly. Last thing I want is it to become some corporate policy driven nightmare where you have to sign a one million page contract before updating the README file.
I respectfully disagree that “The language will always be in open beta…” and that “A number is just that a number.” With software, and especially in the competitive programming languages arena, 1.0 is a critical passage from preparing to compete to actually competing. And version 1.1 may, in fact, be even a better barometer of whether the language, and its lead architect, is a hotshot opportunity or has just taken a shot to the head.
Breaking changes should not happen after 1.0. 1.1 may well contain a goodly list of edge case bugs, but they should not be mainstream bugs. If there are breaking changes, commercial users are in trouble – doubly so if they’ve rolled out applications to end users who are just looking for a reliable solution. In that case, the language, and its developers, risk losing all credibility - and, yes, they made a big, likely fatal mistake in releasing 1.0.
For a hobby language, breaking changes may be “fun” and bugs may be half seriously considered “features” and “reading the code”, or asking questions on a forum, might even substitute for solid documentation.
But the professional who made the mistake of recommending a half-baked platform is likely in trouble … and his client as well.
What I’m recommending is NOT “putting lipstick on a pig” and calling it 1.0. Nor would I introduce a “beta” release in any significant enterprise use. I don’t know if it is true that even with finished releases of software, 90% of the cost is maintenance … I think it may well be more like 900% in today’s wonky world.
And in the case of Crystal there are alternatives - Rust is one; C++ is two; Java is three; Julia is four, C# is five; Kotlin is six … Yes, Crystal may well have some unique strengths (I certainly hope so or I wouldn’t be interested in its progress) – but those strengths have to be pulled off in a reasonably polished package before the gamble on those strengths can be justified vs the risks of things going south in horrible fashion.
1.0 is a special number in programming languages; features can be added and additional platforms can be added as well. But pretty much nothing can be taken back. Its important to make a good first impression.
In fact, the main reasons for creating this theme are as follows. I hope that users in this community can think about it. Since the development of this language, everyone may focus on the technical level. It’s time for us to think about its future again:
- How to stand out from many programming languages? You need to know that there are many general programming languages (what is crystal’s killer compared with other development languages)
- How to promote this programming language to more users? You should know that if users are hard to grow or lose, it will be catastrophic, and the language will gradually go to the end of being ignored (typical case: Free Pascal / Lazarus, it is absolutely a great technology, but it can only cry silently, there are too few people using it for development, and its development is almost stopped Stagnation, it may disappear at any time)
- We still need to do some extra preparations when we release version 1. X. the development documents of the language are very important, which may determine the success or failure of language promotion (typical case: CodeIgniter web framework, in the early stage of the development of PHP web framework, because its documents are easier to understand than any other framework, which makes its promotion and application speed faster than any other framework Framework is fast, although it is not the best performance and most powerful framework)
- We need to abide by some user consensus. Maybe, for users who have used crystal language for some time, we can feel that it is stable. But for users who have just contacted this language, only from version number, they will not think that it is a stable programming language that can be put into production. Inadvertently, this leads to As a result, we lost some users.
To add a little context to my comments, and a proviso: I am not a programmer. I have a CSC Masters, but it is dated and I don’t work as a programmer; I HIRE programmers.
So what do I care? Well, I have made a corporate decision to not go along with Microsoft trying to force me onto Windows 10 – which will break all my legacy applications and the hugely expensive custom C# database application which runs just fine on Windows 7 … and which Win 10 is DESIGNED to break. I believe I am okay at the moment, and my LAN can be pretty effectively isolated from the internet and contagion… even though Microsoft made even THAT really, really unreasonably difficult. My longer term plan is to move my applications to Linux FOSS and away from C# and MS-SQL. And putting critical stuff on “the cloud” is just retarded for nearly all applications which are not pen-ultimately e-commerce or otherwise part of the gig economy.
Everything is broken. Read it. Tatoo it on your forehead. (https://medium.com/message/everything-is-broken-81e5f33a24e1)
So here I am in the early stages of evaluating programming languages, databases, etc. for my Linux redoubt. There aren’t any obvious choices for language in writing enterprise software on LInux. I could use C, which I know, but I’d prefer something more modern. C# on Mono is just a come-on…and I suspect will likely always be. I guess I could choose Java; but I look at all that boilerplate and start to retch.
Kotlin I am seriously thinking about. Lazarus has some distinct advantages. I really like python syntax but it is really slow and the code base is really big. Maybe Go? I don’t know.
Hmmmm. How is that Crystal coming along?? So that’s how I came to be hanging around here. I’m not going to with something pre 1.0. But something 1.0 which a good Ruby programmer could get up to speed on in a few days? That would be really interesting. And, for whatever odd reason, I really care about interesting programming languages - even if I no longer code.
That’s the main problem.
- Windows support won’t be possible without breaking changes (because stdlib is still uses some posix concepts).
- Multithreading could require breaking changes in stdlib. I’m not sure how big they could be.
- Incremental compilation won’t (or very unlikely to) be possible without breaking changes, and those changes could be BIG, similar to what happened in https://github.com/crystal-lang/crystal/issues/1824.
- Current implementation of generics is “well, they works”. They are powerful enough to use them in simple cases (and even for an stdlib with all those Iterator\Iterables), but once you try to do something more advanced you will see rough edges. It is possible to construct cases that won’t work by design, and any fixes would possibly require breaking changes. Answering “do not use generics inheritance for now, it is broken” to issues in 1.0 language isn’t fine, generics inheritance should be limited to cases that are not broken by defined semantics, not compiler implementation.
- Macros are similar thing. They are powerful but “hacky”, many things there look like a temporary solution.
- Aaand there still exhaustive case, removal\fix of private types, simplification of Int\Float, and plenty of similar things that are breaking changes too and should be decided before 1.0.
Personally I believe that (1), (2), and (6) could be done in one year, so 1.0 in 2020 would mean lack of modular compilation, strange generics and macroses for all 1.x versions.
I think my tone could be slightly too critical. I don’t want to say crystal is bad - it is wonderful, much better than any alternatives and i love it with all it’s limitations.
But 1.0 mean that it’s development in mentioned fields (and possible some other) will be stopped or severely limited, and that would be sad.