Building a Command-Line Application with Crystal | Hacker News Reader

Building a Command-Line Application with Crystal

jclem.net

99 pointswilllll33 comments

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.

[1] https://crystal-lang.org/2016/12/29/crystal-new-year-resolut...

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

meanwhile, crystal does not even support windows yet. https://github.com/crystal-lang/crystal/issues/26

Go-like cross-compilation only works with pure Go libraries that don't make use of either syscalls or cgo.

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?

according to https://dave.cheney.net/2016/01/18/cgo-is-not-go

> 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.")

Usually those praises come from young developers that never developed software back in the days when static linking was the only option.

So they look at Go's static linking, their experiences using -static in gcc and glibc, and think they just found something magical.

It is interesting the amount of knowledge that gets lost within a few generations.

> 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").

If you enjoy reading documents, BITSAVERS.ORG is a treasure mine full of lost knowledge.

https://archive.org/details/bitsavers

Here you will find Xerox PARC, DEC, Burroughs, Apple, Sun, Borland,... old research documents, papers, manuals.

In the context of static compilation, for example in MS-DOS, take Turbo Pascal 6.0 programmer's guide.

https://archive.org/details/bitsavers_borlandturVersion6.0Pr...

For some 8 bit love you can check ZX Spectrum and Atari archives.

http://www.worldofspectrum.org/

http://www.atariarchives.org/

Next step is to get an emulator for any of those old OS/computers and try to follow along one of those books.

Also there are some videos on YouTube showing those systems.

"The Smalltalk-80 Programming System"

https://www.youtube.com/watch?v=JLPiMl8XUKU

"NeXT vs Sun"

https://www.youtube.com/watch?v=UGhfB-NICzg

"Steve Jobs internal demo of NeXTSTEP 3"

https://www.youtube.com/watch?v=gveTy4EmNyk

"Amiga Programming"

https://www.youtube.com/watch?v=WOAyVIWFaXQ&list=PL1E7187BCF...

"Amiga Hardware Programming"

https://www.youtube.com/watch?v=p83QUZ1-P10&list=PLc3ltHgmii...

The Mother of All Demos"

https://www.youtube.com/watch?v=yJDv-zdhzMY

Just a very tiny sample of videos

I emailed the bitsavers link to our programming team at work with the subject: "jurassic park"

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.

Have you ever tried to cross-compile a Go application using native UI toolkit?

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.

[0] https://crystal-lang.org/api/master/JSON.html#mapping%28prop...

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.

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.

Here's a quick gist that does what I think you want, modulo any specific error handling. https://gist.github.com/usernamefornow/14f972df9429146b46846...

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.

BTW the Crystal website has just been redesigned :) https://crystal-lang.org/

Dangit, doesn't work natively on windows without bash :(

And I'm all windows lately. Guess I can try it on my mac but that's like over there.

I do love the multi-platform-ness and single file of go, so it'll be cool to try this and get some ruby love.

It seems like porting Crystal to run on WIndows is work in progress: https://github.com/crystal-lang/crystal/pull/3582

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!

Reply on news.ycombinator.com