Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Crystal Programming Language

crystal-lang.org

Post reply on HN
Print view View original

141–150 of 180 posts

Re: The Crystal Programming Language

#141

Post by CyberDildonics »

zeeone wrote: post #102
CyberDildonics wrote: post #82

Earlier quoted context omitted.

You definitely should at least look into Julia. I would say it is more elegant than any other language I've seen while being faster than pretty much anything except for straight C / C++ / D / Rust (native systems languages). It should be easy to beat Go in performance and match or exceed Ruby in elegance and simplicity. It's Achilles heel(s) right now though are multi-threading and JIT compilation times (which should…

Julia's 1-based array indexing is counter-intuitive and a turn off.

I've seen people say this but really 1 based indexing should be extremely trivial to all the other complexities of writing a worthwhile program for anything more than a one liner.

Re: The Crystal Programming Language

#142

Post by CyberDildonics »

CyberDildonics wrote: post #82
sergiotapia wrote: post #46

I'm looking for something beautiful like Ruby but fast like Go. Do you think Crystal fits this bill? Also, are there packages/libs/gems for Crystal? What are they called? What do I google for? One of the major reasons why I dumped Go is that it's just too verbose and makes me write too much boilerplate code. I want to sort a collection and I have to write the same algorithm every single time for every single type. It…

You definitely should at least look into Julia. I would say it is more elegant than any other language I've seen while being faster than pretty much anything except for straight C / C++ / D / Rust (native systems languages). It should be easy to beat Go in performance and match or exceed Ruby in elegance and simplicity. It's Achilles heel(s) right now though are multi-threading and JIT compilation times (which should…

Wow, are people really that offended by someone suggesting Julia? It is a bullseye answer to the question.

Re: The Crystal Programming Language

#143

Post by wedesoft »

asterite wrote: post #24
zeeone wrote: post #16

Just curious, why Crystal? It looks just like Ruby. What problem(s) are you addressing with Crystal?

We like the way Ruby lets you quickly prototype things, but its performance isn't very good (it's just good) and it also lacks static type checks (for example "undefined method '...' for Nil" is a very common runtime error). So, we are trying to create a language with all the nice aspects of Ruby but with static checks and better performance. Of course that comes at a price: no dynamic aspects (no eval, no instance_e…

Macros is something I really miss in Ruby. But static classes strikes me as a bit of a limitation. E.g. a Crystal REPL can't create classes if I understand it correctly.

Re: The Crystal Programming Language

#144

Post by kibwen »

p0nce wrote: post #130
aikah wrote: post #124

I'm a go user right now, but I really want to ditch it because I'm in total disarray with the way the go language is managed and the deafness of the go team. Been looking at D,Nim and Crystal. - D is neat but I'm not interested at all in unsafe stuffs and don't want to have to debug programs or 3rd party libs that relies on that, I want a safe language. - Nim looks really good, although some features like (foo_bar =…

D has a memory safe subset (@safe). You could argue that Rust 3rd party libs rely on unsafe blocks.

The person you're replying to wasn't even talking about Rust. You'd also be vastly overestimating the amount of Rust libs that need unsafe code. For example, Rust's most mature web framework, the one powering crates.io, doesn't use unsafe code at all: https://github.com/iron/iron

Re: The Crystal Programming Language

#145

Post by kibwen »

atmosx wrote: post #120
davexunit wrote: post #83

I don't understand why Ruby's syntax is seen as so elegant. It's ambiguous and a nightmare to parse. http://programmingisterrible.com/post/42432568185/how-to-par...

I don't understand what parsing has to do with elegance in this context. There are some 'best practices' but I don't see the different syntax support as a bug. I feel that it's a trademark of a modern language. Let's take rust as a counter example. IMHO this is ugly: fn foo() {...} To make it elegant I should be able to remove the parenthesis because there's no argument inside: fn foo {...} But this will come up with…

It's not just about making parsing easy (which is usually motivated by the promise of better tooling), it's about making costs explicit. `foo.bar` with no trailing parentheses is always a field access in Rust, and a field access is basically the fastest thing one can do: take a known offset from a memory location. In comparison, `foo.bar()` has a relatively tremendous cost, depending on various factors. It's for this same reason that Rust requires you to write `(foo.bar)()` if you want to call a function stored in a struct.

This isn't a tradeoff worth making in all languages. But it is a tradeoff, and not a rejection of elegance.

Re: The Crystal Programming Language

#146

Post by snake117 »

Confusion wrote: post #114
davexunit wrote: post #86

Earlier quoted context omitted.

An ambiguous syntax is not elegant to program with. Is this a variable reference? Is it a method call? I dunno!

Boring arm chair language criticism. I have programmed professionally in Ruby for 5 years and it has never been a problem. You may as well complain that the ability to import an identifier leads to confusion about which identifier from which namespace you are calling when you reference one. I have 99 gripes about Ruby, but this ain't one.

I just started working with Ruby on Rails a few weeks ago and I think the so-called "elegant" syntax is the reason why I went with it. That and the fact that Rails is a joy to work with.

Re: The Crystal Programming Language

#147

Post by kibwen »

asterite wrote: post #129
chrisseaton wrote: post #126

Earlier quoted context omitted.

No, I didn't, sorry! I don't see that option documented anywhere except the changelog, and one passing reference in the docs that says it sets the release flag, but neither say it has any effect on optimisation.

Yeah, we need to document this better, sorry!

Get used to this, watching people run benchmarks after having forgotten to compile with optimizations is basically a meme in the Rust community. :)

Re: The Crystal Programming Language

#148

Post by Jweb_Guru »

kentt wrote: post #122
davexunit wrote: post #86

Earlier quoted context omitted.

An ambiguous syntax is not elegant to program with. Is this a variable reference? Is it a method call? I dunno!

Have you written Ruby often and still felt like this? I'm asking because I'm newer to Ruby and this does come up a fair bit, but I was assuming that with time the ambiguity would disappear.

I have written Ruby for many years now. The ambiguity never disappears, and the delight at how "expressive" the syntax is quickly turns to loathing. YMMV, of course.

Re: The Crystal Programming Language

#149

Post by Dewie3 »

aikah wrote: post #124

I'm a go user right now, but I really want to ditch it because I'm in total disarray with the way the go language is managed and the deafness of the go team. Been looking at D,Nim and Crystal. - D is neat but I'm not interested at all in unsafe stuffs and don't want to have to debug programs or 3rd party libs that relies on that, I want a safe language. - Nim looks really good, although some features like (foo_bar =…

If you don't like unsafe stuff perhaps you should be a bit wary about Nim as well. The attitude seems to be that unsafe things aren't that big of a deal as long as you decent tools to debug them.

Re: The Crystal Programming Language

#150

Post by asterite »

kibwen wrote: post #147
asterite wrote: post #129

Earlier quoted context omitted.

Yeah, we need to document this better, sorry!

Get used to this, watching people run benchmarks after having forgotten to compile with optimizations is basically a meme in the Rust community. :)

I don't think it's a big deal, benchmarks are just toy programs. Once you learn about the `--release` flag you never forget it for production-ready code.

C has -O3, why isn't it the default? Because it takes a lot more time to compile. So I think no optimizations by default is the best choice. And I think Rust should do the same, you will be compiling more things in non-release mode than in release mode.

Post reply on HN