I’m really excited about this! I love Ruby but the one thing it is missing is static typing.
This is probably going to come off as negative, but while I like the typing Crystal feels like a 100% copy of Ruby (warts and all) without the ecosystem.
Though maybe gems will work naturally.
Typing and native binaries seem like big gains.
Yeah, but like that’s true of any language?
Not trying to dispute that, only trying to say that it could offer gains greater than a copy of Ruby could. :-)
Yeah, you’re right about that.
My complaints are really that I’m tired of seeing Ruby’s warts continued in new languages.
What Ruby warts do you see being continued in Crystal?
Your complaint is valid, but if your new “copy of Ruby” changes too much, then it’s no longer a copy and no one who likes Ruby will want to use it. That puts languages like Crystal in between a rock and a hard place. Do you want to be like Ruby or “the next Ruby”? Or do you want to forge your own path? Neither path is an easy road in my opinion. And, finally, it’s a very fine line to walk between the two.
Hey, yeah I’ve made the same argument about RubyMotion (which has minor differences).
I believe that honestly if Crystal gets the ecosystem it should start ripping out the warts. It’ll be a long journey, it’ll have a lot of discomfort, but we’ve learned a lot since ‘91.
Agreed, I have the exact opposite opinion: too many languages are “inspired by X” but with some meaningless change (functions are defined with func instead of def for example). It is added cognitive load for no real gain.
This article puts to words what I’ve been feeling about Haskell. Haskell may succeed, but only in spite it’s over-promising community, poor tooling, and obfuscated documentation.
I say this all as a lover of Haskell.
I feel the same way, but there’s hope. I totally agree with your comment: last month I got frustrated with Hakyll and seriously thought about switching to Jekyll or something else. But the haskell workflow has gradually been getting better over the years, with cabal sandboxes, stack and stackage. Yes, there is a feeling that the ecosystem is fractured, but some of that is because new ideas are being fleshed out now and are still pretty raw.
I see a post like this every couple of months, and it is a good idea to remember that Haskell doesn’t have amazing tooling yet. But it has been getting a lot better…pretty amazing for a project that’s mostly worked on by unpaid volunteers.
One final note: it is good to talk about Haskell’s tooling issues as a caveat for newcomers. But posts like this can also ruffle feathers. Some people work pretty hard on improving these things, working for free. This feels like shitting on their work.
I sort of posted in knee-jerk frustration.
You’re absolutely right. There’s people working their ass off to make tooling better, and it is getting better (stack being a notable example). Being too negative will discourage them, and without them we’re stuck where we are.
Equally destructive though, are the naysayers that say that nothing is wrong. It (a) makes people feel stupid and (b) halts development on new tooling that is much needed.
Trying to build the old NES game “Battle Tank” in the browser
Are you building an emulator, or building the game from scratch?
From scratch, using Phaser.js for the frontend and Elixir for the backend (multiplayer)
Eek – the example pages for Phaser.js are succeptible to a variety of attacks, but I pushed out a pull request to fix some of the more prominent ones.
Thanks for the PR and keeping us informed. The PR looks like the security issue is because of the backend they have.
That sounds awesome!
Phaser is a fantastic framework.
A Book On Abstract Algebra. I really recommend it. So easy to read it is almost like bedtime reading, but it still teaches big concepts.
Hi, I’m the author of contracts.ruby. This is a well-written post! There’s also a great gem from Simon George that will auto-generate documentation from contracts: https://github.com/sfcgeorge/yard-contracts
If I understand it correctly, the contracts will still create exceptions at runtime right? Is there any tooling for trying to catch some of the errors statically?
Correct. There are various incomplete tools for static type-checking. Here are two:
They are all partial checkers, because it is impossible to typecheck Ruby statically. I have been thinking about writing something that uses contracts to do partial type-checking as well.
There’s also a language with Ruby syntax that has static typing:
Awesome didn’t know this one. Thanks for contracts.ruby, really love it!
I’m reading The Princeton Companion to Mathematics to brush up on my math. It has been really easy to read so far.
What’s your estimation for reading it cover-to-cover?
Well, I imagine it gets tougher. I saw someone say they read it in 1.5 years, so that’s my target. It is a thousand pages!
[Comment removed by author]
I loved Skiena’s Algorithm Design Manual, great book. The first half reads like your standard data structures/algorithms textbook, the second half is more of a cookbook for specific algorithms. He did an awesome job walking the line between informative and approachable and succeeding on both fronts.
I’m going to shamelessly recommend my book: manning.com/bhargava
I have been working on it for two years, and I’m proud of how well it has turned out.
Here’s a gist explaining why I think it is well written: https://gist.github.com/egonSchiele/c1ca3e08749169463d37
Great! Ping me anytime in the forums if you need help :)