Live data from Hacker News

Crystal for Rubyists

crystalforrubyists.com

61–70 of 94 posts

Re: Crystal for Rubyists

#62
post #43
post #32

Earlier quoted context omitted.

Pfff, yesterday i talked with a Brain fucker...it was terrifying. Can we just stop calling peoples after tools?

Generally I would agree, but in this case, "Crystal user" isn't that much better.

A developer who uses crystal? Like a builder who uses a hammer is not a hammer-user ;)

EDIT: Wow that took a long time to realize what you meant...haha no, truly not good, and thinking about it my comment "A developer who uses crystal?" is now terrible too.

Re: Crystal for Rubyists

#64
post #58

Earlier quoted context omitted.

> The slow(ish) Crystal compilation will not please Ruby users I don't know what's the general opinion, but distribution for dynamic languages is a nightmare (and I'm including intra-machine, ie. switching between environments). Personally, I'd be thrilled to trade off speed of compilation for distribution simplicity! > My impression is that not many Ruby programmers have switched to Crystal. This depends on the cont…

> distribution for dynamic languages is a nightmare Weird statement. Software distribution generally is just a terrible mess, regardless of what sort of language it's written in. The one exception is JS, which happens to be dynamic and also has what is probably the most reliable and ubiquitous platform available—so much so that its distribution story is often credited, rightly or wrongly, as the only reason anyone ac…

There are very significant differences between distributing programs in a static vs. dynamic language.

Github's Hub tool is a good example.

It was originally written in Ruby. This requires that the user:

- may need to handle a certain environment in terms of Ruby interpreter (potentially install a new version)

- may need to handle a certain libraries group (gemsets in RVM)

- needs to install dependencies

- needs to handle switching to the appropriate Ruby interpreter version and libraries group

Especially point 3 is a pain.

Even just installing everything as system Ruby won't work, because often, different Ruby interpreter versions are required.

Once they moved to Golang:

- the distributor compiles for different platforms

- the user downloads the given version for their O/S

That's all.

Re: Crystal for Rubyists

#65

This is great Serdar. As an alternative to Chapter 2 I’ll also share https://github.com/compumike/crystal-docker-quickstart my project template which lets you get a Crystal (currently 1.6.2) dev environment running with just Docker. Good for kicking the tires, which is what I think your audience is probably wanting to do! And then eventually can install a binary package as you suggest.

Nice! It doesn't work in Windows native, right? Asking because newbies might come from there (although I bet most of them use WSL).

Hmm I don’t know — I don’t have a Windows or WSL setup to test with right now. What breaks?

Re: Crystal for Rubyists

#66
post #58

Earlier quoted context omitted.

> distribution for dynamic languages is a nightmare Weird statement. Software distribution generally is just a terrible mess, regardless of what sort of language it's written in. The one exception is JS, which happens to be dynamic and also has what is probably the most reliable and ubiquitous platform available—so much so that its distribution story is often credited, rightly or wrongly, as the only reason anyone ac…

There are very significant differences between distributing programs in a static vs. dynamic language. Github's Hub tool is a good example. It was originally written in Ruby. This requires that the user: - may need to handle a certain environment in terms of Ruby interpreter (potentially install a new version) - may need to handle a certain libraries group (gemsets in RVM) - needs to install dependencies - needs to h…

Okay. Sounds like you're on the road to a convincing argument against Ruby. (I myself have avoided Ruby in the past for similar reasons, despite other things about it that are attractive.) And gesturing towards Golang is really just highlighting a conscious design decision by the Golang team—who didn't have to design it as a static language in order to achieve the same effect; they're orthogonal issues.

Where does the generalization to dynamic vs. static languages come from?

> Github's Hub tool is a good example.

I gave an example already (a counterexample, that is—JS). Was there something wrong with that?

Re: Crystal for Rubyists

#67
post #30

> What’s awesome about Ruby? > Dynamically typed As someone who has experienced the joy and at least some feeling of safety from moving to typescript from javascript, I would seriously question that dynamic typing is awesome.

As someone who was on the type train in Uni and moved to dynamic languages, my first feeling was slow and unsafe. I couldn't imagine how things wouldn't just explode. In practice I've rarely seen issues. Ruby is still the fastest way for me to get a concept working. I'd definitely consider it awesome.

Re: Crystal for Rubyists

#69
It's quite easy for me to churn out some data munging scripts using Ruby but I was running into performance issues on large csv files. Crystal is like having super powers for csv parsing if you already have Ruby skills. I really think it's the sweet spot for the language.

Re: Crystal for Rubyists

#70
post #58

Earlier quoted context omitted.

> distribution for dynamic languages is a nightmare Weird statement. Software distribution generally is just a terrible mess, regardless of what sort of language it's written in. The one exception is JS, which happens to be dynamic and also has what is probably the most reliable and ubiquitous platform available—so much so that its distribution story is often credited, rightly or wrongly, as the only reason anyone ac…

There are very significant differences between distributing programs in a static vs. dynamic language. Github's Hub tool is a good example. It was originally written in Ruby. This requires that the user: - may need to handle a certain environment in terms of Ruby interpreter (potentially install a new version) - may need to handle a certain libraries group (gemsets in RVM) - needs to install dependencies - needs to h…

I wouldn't shrug my shoulders at

>> the distributor compiles for different platforms

Most people aren't doing that for you. There are lots of tools out there where you do need to still manually compile it yourself and make sure you have the appropriate dependencies which will still be painful. That being said, I agree that shipping a script can be a problem, but lots of people use Brew and that seems to work ok.

Post reply on HN