I've spent a number of years using ruby and I got super excited about the potential of Crystal about a year ago. The notion that I can use a Ruby-like syntax and ship a binary to deploy my web apps was killer. But, a year ago the language was a bit rough, and to some extent, it still is. The team behind it is open about their goals and it blows me away with how much changes on a daily basis for a team of their size. Hopefully, the crystal team can set out to complete what they set their sights on for 2017[1]. That would really round out the feature set for a 1.0 release.
I think what I like the most is the community is willing to help you out. Although, nowadays a strong community is what makes or breaks a language.
Anyone compare Nim to Crystal? Both are AOT languages with syntax inspired by dynamic languages (Python & Ruby). Nim transpiles to C and Crystal uses LLVM. I've been playing with Nim, but I have a feeling Crystal will catch on quicker.
i think nim has better compiler options (in particular, i don't know if it has already achieved go-like cross-compilation of static binaries, but if not it's further along that road than crystal is). https://nim-lang.org/docs/nimc.html
True and pretty obviously so, but Go is still fantastic in this regard. :) Compare to other native cross-compile stories like with how you'd have to go about to cross compile a Qt app on Linux to Windows... Or even worse to Mac.
I keep hearing praise over how easy it is to statically compile Go applications. Does the same apply to static compilation? Is it only easy when using pure Go libraries?
> It is interesting the amount of knowledge that gets lost within a few generations.
I've only been programming for 4 years. What's the second best way to learn the old practices and the way things were done (the first best being "living back then").
> It is possible to compile a Go program entirely statically, but it is by no means simple and shows that the ramifications of including cgo in your project will ripple through your entire build and deploy life cycle.
(that article also contains the beautiful line "You’re not writing a Go program that uses some logic from a C library, instead you’re writing a Go program that has to coexist with a belligerent piece of C code that is hard to replace, has the upper hand negotiations, and doesn’t care about your problems.")
> I could point out that your grammar ('some of documentation') invalidates your entire comment, but that's kinda silly.
He's not writing the hopefully high profile documentation for a project that people want to be used, ffs. No, it doesn't deserve to be discarded because of that, but it's clearly suboptimal.
You make it sound as if this version of the documentation is set in stone, forever. Can't small projects improve their documentation as they grow in popularity? E.g. do you think that Linus Torvalds' Linux documentation was always up to the highest standards of Strunk & White's prescribed English?
I absolutely do not share the opinion of person to whom you are replying, but to state that their comment is invalid due to a trivial typo is unnecessary, and has potential to be incendiary.
What point were you trying to make? You made one great statement, with which I agree fully, but followed with statement drawing a comparison between the documentation for a funded open-source project, and a typo in a comment thread. It's not just "kinda silly", it's utterly asinine.
No, I said I could have drawn that comparison, but I wasn't going to, because it would be silly, just as knocking a cool project down because its creators aren't native English speakers is silly.
I've started to transition from Ruby to Crystal for my pet projects and haven't hit any serious issues so far. Since you seem to have much more experience than I do, would you mind elaborating a bit on the issues you found and why you think the compiler and type system are bad?
I wouldn't count on it, judging by his previous comments he seems to prefer drive-by snipes over discussions. The fact that he made so many claims about how bad Crystal is without even attempting to explain why doesn't really make him seem credible. And the icing on the cake gotta be how he nitpicks on very minor grammatical errors made by non-native english speakers which he also seems to be completely unaware of that they are. Even I - a Swedish person - fully understand every sentence I've read so far, and English is not my primary language either.
I wouldn't take this guy seriously until he brings forth some constructive criticism.
Elixir is by far my favorite language out of the 6 I've seriously tried (Elixir, Ruby, JavaScript, Python, Java, Bash). I'm gonna dive into Go in near future.
Hmm, seems like the author either does not know about JSON.mapping [0] or just chose not to use it. Honestly, the corresponding macro for YAML is the main reason I use Crystal for CLI apps since it comes with the stdlib. YAML is easy enough to write quickly that I don't have to do too much with option parsing. Plus you can just use your editor rather than the shell.
I do use it in this project, but most definitely in the wrong way. I had a little trouble seeing how I could use it for getting at nested values of varying types and still have some sane error handling.
This post is very much about my first pass at this and my first experience with Crystal. Cleaning up the JSON parsing is the next item on my list when I have time.
edit: note that the cleanest way would probably to write your own converter so you could avoid the union type, but I didn't want to put that in and have to write a comment about it.
Makes sense, thanks. For some reason, I was set on parsing the "env" values into instances of the same class, regardless of what type they were in JSON, but it's not really necessary. I'll also look into writing custom converters, because I'll likely need that in the future.
You can pass union types to the macro, so that should handle your "varying types" problem. In terms of nesting, I just create another struct with its own JSON.mapping and use that as the type for the field.
I really, really like crystal but was bitten a few times on a project because it is still not quite ready for primetime.
Because its so young, there have been a handful of breaking changes which affected my code a few times (and even worse, my dependencies).
They have a good concurrency model but I'm waiting for them to add parallelism.
I mostly just crave the solidarity in tooling, dependencies, APIs, compiler options/performance which will come after hitting 1.0 (i hope). I'm excited for the day I can go all in. Keep it up Crystal team!
I think what I like the most is the community is willing to help you out. Although, nowadays a strong community is what makes or breaks a language.
[1] https://crystal-lang.org/2016/12/29/crystal-new-year-resolut...