5 ms·
I think Crystal is a very practical language to work in for web. It doesn't have the polish of Go (yet), but it feels more approachable to me. Rust has its plac
by andyfleming 10y ago
I think Crystal is a very practical language to work in for web. It doesn't have the polish of Go (yet), but it feels more approachable to me. Rust has its place with low-level systems work, but Crystal gives you something that is reasonable to write and still compiles to a binary. In turn, it performs well and is easy to distribute, deploy, and containerize as well.
- dingdingdang 10y agoI agree with this sentiment, Crystal, for the better, lacks Go's obsession with odd tooling conventions (see vendoring saga) while retaining the ease of use when it comes to actual programming and cross compilation capability.
- lmm 10y agoIf I'm already using, say, OCaml, why would I want to switch to Crystal? (assuming that multicore takes the same amount of time to arrive in each). Whenever I've read about Crystal it sounds like a broadly sensible language, but it doesn't sound like it brings anything new to the table - in which case I'll favour the more mature language with the bigger library/tool ecosystem.
- galfarragem 10y ago> it doesn't sound like it brings anything new to the table A fast and typed Ruby, isn't it enough? ;)
- lmm 10y agoOCaml (well, actually Scala in my case, but I can understand why people wouldn't want to have to use the JVM) is already that, as far as I can see. What is it that Crystal offers that OCaml doesn't?
- galfarragem 10y agoA gentle learning curve for developers with a Ruby background.
- coldtea 10y agoDoesn't share the fugly OCaml syntax.
- pimeys 10y agoIs this the same with Crystal, as shown in Ruby: irb(main):001:0> "".methods.size => 170 irb(main):002:0> 0.methods.size => 133 If it is, I mean, I don't see it being so fast.
- yxhuvud 10y agoWhat on earth has the size of the list of methods to do with performance?
- coltonv 10y agoThe number of methods in the standard library really doesn't impact performance in a compiled language since you can tree shake the stuff that isn't used. And even if you don't tree shake having lots of methods isn't really a noticable performance loss in compile to binary languages since you don't need to spin up a VM
- eropple 10y agoIt's not a Ruby. It doesn't even pretend to be a Ruby. I mean, to be a Ruby, this needs to work: a = Object.new list_of_modules.each { |mod| a.extend(mod) } Ruby cannot be separated from its dynamism and to claim it can is misleading.
- RX14 10y agoMost of the popular languages over the last 20 years haven't brought anything new to the table, they've just had the right mix of pre-existing features (I use features in a very broad sense to mean any reason why a developer would use it) at the right time.
- yxhuvud 10y agoRuby itself never brought anything new to the table, just a really well polished collection of ideas taken from other languages. Crystal is mostly the same, marrying Ruby stdlib with go channels and compilation to native code.
- j_s 10y agoThanks for the summary; helpful as I've not checked out Crystal at all yet. Maybe they can steal it as their everywhere blurb.
- nickpsecurity 10y agoIf you write a FOSS project, more people will help you if it's Scala or Crystal over Ocaml. My guess at a little over 1,000 stars for Ocaml but 7,000 for Crystal. There's that. ;) For psychological reasons, things that build on what's familiar get increased adoption. Trend started with C syntax that I can tell.
- throwaway7645 10y agoI think tho might be easy. OCaml might have OO,but it is meant to be used as FP. The ecosystem isn't honestly that impressive and isn't winning over people from Ruby or Python and isn't going to catch on more than it already has. If Crystal catches even 1/4 of Ruby's base it will be huge. OCaml is hard to get into btw (big language). Crystal looks easy.
- RX14 10y agoI think crystal has several advantages over go, first of which is the type inferrence. In crystal, you never specify types in method bodies. You don't have to specify types in method arguments either. Type unions are really expressive, and handing nil is as easy as `raise/return unless nillable_variable`. Second of which is `yield`, ruby's extremely powerful way of passing code to functions. In crystal, functions which take blocks are actually inlined, meaning that abstractions such as `3.times {}` or `5.upto(20, step: 5) { |i| ... }` have zero cost. For example, take a look at how simple the HTTP server example is on the crystal homepage. Very useful for building DSLs. Macros are another powerful (but hopefully not overused) tool for building clean programs. Crystal macros receive AST nodes but return source code as text. This text is then compiled and placed inside the program. This may sound like it would have the disadvantages of C macros, but as they're more integrated into the language, the compiler can insert the generated AST of the compiled macro into the original AST in a clean way. Using "dumb" text templating has several advantages: it's really easy to use because you're essentially just writing crystal code, and it's powerful as you get access to the AST. It also has the advantage that it's actually quite hard to make large scale modifications to a method body, preventing a lot of the silly macro uses.
- chrisseaton 10y agoRuby implementations with a JIT can also inline blocks, of course.
- gravypod 10y agoThat still comes at a cost. The macro/lazyeval approch is usually seen as "zero cost" because the JIT engine usually only spends time inlining if it's a hot block.
- RX14 10y agoOf course they can, however I was describing the advantages of crystal as opposed to go. Crystal vs Ruby don't really compete in the same way Crystal and Go do, it's very much a dynamic vs static typing split. Crystal is in general a bit more cleaned up but Ruby's community is much larger.