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

Crystal 0.25.1 released

crystal-lang.org

Post reply on HN
Print view View original

71–80 of 154 posts

Re: Crystal 0.25.1 released

#71

Post by MaxBarraclough »

coldtea wrote: post #54
MaxBarraclough wrote: post #38

Earlier quoted context omitted.

I see your point, but I sympathise with it less and less as time goes on. Programming languages are just tools. Software development should strive to be a proper, rational, engineering discipline. Humans aren't robots, but one's choice of development tools is steered by real forces, both technical and business. I don't see that whim, unconstrained by such forces, has any place in the decision. Same goes for curiosity…

> Software development should strive to be a proper, rational, engineering discipline. That will never happen. Or when it did it will be all mechanized, with machines doing the programming.

Even today, a tiny proportion of software development is actually done with a respectable engineering process.

It's not a myth, and I don't see that it should be dismissed as a pipe-dream to think that this sort of serious engineering approach could be adopted outside the critical-systems industry.

https://www.fastcompany.com/28121/they-write-right-stuff

Re: Crystal 0.25.1 released

#72

Post by kodablah »

RX14 wrote: post #67
kodablah wrote: post #55

Earlier quoted context omitted.

I think what we'll see coming soon, assuming some people work on it, is the recognition that Go's stdlib and all the supporting libs is where the real awesomeness lives. And for langs that support Go-style concurrency (like Crystal basically does, Kotlin, etc), people will start transpiling with only a couple of things dropping into the target language. There're just too many good pieces of crypto, http2, etc to rewr…

I can attest to this, the amount of times I've had a look and used go's stdlib as a reference for what to do when implementing something in the std for crystal is too many to count! Unfortunately, transpiling has a huge bunch of problems, which you can see in for example how quickly nim vs crystal compiler matured - even though the crystal compiler is more complex. I'd be interested in seeing go's stdlib, ssa backend…

I'm curious about the transpiling problems from, say, Go to Crystal (not after SSA, but before w/ the high level constructs). I have toyed with Go to Kotlin and even though duck typing is unimplemented in the latter, I can basically get there. I even started a project to dump Go AST and type info[0] but I haven't completed it really. There are just too many amazing Go libs out there to not exercise this option.

Go does have a buildmode for c-archive and c-shared, but it's built around the hobbled Cgo, so you have to explicitly export funcs, and things like structs cannot be exported. Still, a swig-like shim/bridge could be developed, but I am unsure at what cost (I think the go mobile stuff does a form of this).

0 - https://github.com/cretz/go-dump

Re: Crystal 0.25.1 released

#74

Post by pmontra »

abritinthebay wrote: post #8
sdogruyol wrote: post #3

Earlier quoted context omitted.

We use Crystal at RainforestQA to replace our heavy-load / slowish Ruby microservices. It's been great so far and we love it. We're also increasing the adoption to Crystal inside the organization. Also Crystal has a dedicated a wiki page for production users Used in production: https://github.com/crystal-lang/crystal/wiki/Used-in-product...

Interesting! I’m surprised you didn’t move to Elixir given the syntax similarities to Ruby

The syntax similarities between Elixir and Ruby stop as soon as one moves on from reading short blog post to writing real code. They are extremely different languages. Knowing Ruby helps only to remember the names of some standard library modules and functions, which were designed on purpose to match the name of the corresponding Ruby modules and methods, but not all of them. A vanilla example:

    $ iex
    > "1 2 3" |> String.split |> Enum.map(fn x -> String.to_integer(x) * 2 end)
    [2, 4, 6]

    $ irb
    > "1 2 3".split.map {|x| x.to_i * 2}
    [2, 4, 6]
which by the way highlights the extra verbosity of Elixir compared to Ruby. It's less verbose on more complex examples, mainly because of pattern matching, but the proof would be too long for this reply.

Re: Crystal 0.25.1 released

#75

Post by snake_case »

I tried out Crystal and Kemal a few months ago and really enjoyed it. However, one issue that's preventing me from wanting to take it to production is that apparently you cannot generate fat binaries and run them without Crystal also being installed in your deployed environment.

Is that true still? If it is, does anyone know when support for "real" fat binaries (no need for Crystal on the server) will be available?

Re: Crystal 0.25.1 released

#76

Post by shawabawa3 »

asterite wrote: post #48
shawabawa3 wrote: post #44

Are compilation times still incredibly slow? That was the deal breaker for me with crystal, toy project of maybe a few hundred lines of code taking 30+s to compile edit: specifically a static release compile, with shards build --no-debug --release --link-flags "-static"

The compiler takes about 30 seconds or a bit more to compile, and it has around 50000 lines of code. Do you have the few hundred lines that took you 30+s to compile?

Just dug out the code and tried again

It's 80 lines and depends on kemal, radix and kilt

`shards build --no-debug --release --link-flags "-static"` takes ~60s

I can't send the full code atm, but it basically just fetches json from an endpoint, stores it in memory, and returns it in a different format on an http endpoint

Re: Crystal 0.25.1 released

#77

Post by sjtgraham »

snake_case wrote: post #75

I tried out Crystal and Kemal a few months ago and really enjoyed it. However, one issue that's preventing me from wanting to take it to production is that apparently you cannot generate fat binaries and run them without Crystal also being installed in your deployed environment. Is that true still? If it is, does anyone know when support for "real" fat binaries (no need for Crystal on the server) will be available?

Do you mean statically linked binaries? Fat binaries generally refer to multiple ABIs in the same image, a mostly Apple thing these days.

Re: Crystal 0.25.1 released

#78

Post by asterite »

cutler wrote: post #73

Won't the impending releases of TruffleRuby, Graal and Substrate VM make Crystal irrelevant?

That's about speed (though I think Truffle/Graal make an app consume more memory). Crystal is type-safe, and no optimizing VM can do that for Ruby.

Not that type-safety is a killer feature, but that's just one difference.

Re: Crystal 0.25.1 released

#79

Post by kureikain »

Crystal is a nice language that just keep getting better.

Think about 10 years ago, we never think of a small company,community be able to writing a programming language. Nowsaday Crystal/Elixir/Nim prove what we can without huge financel support from huge company.

Crystal pick Ruby syntax, which is very elegant to me and I'm happy to have that option available and appreciate that.

Re: Crystal 0.25.1 released

#80

Post by asterite »

shawabawa3 wrote: post #76
asterite wrote: post #48

Earlier quoted context omitted.

The compiler takes about 30 seconds or a bit more to compile, and it has around 50000 lines of code. Do you have the few hundred lines that took you 30+s to compile?

Just dug out the code and tried again It's 80 lines and depends on kemal, radix and kilt `shards build --no-debug --release --link-flags "-static"` takes ~60s I can't send the full code atm, but it basically just fetches json from an endpoint, stores it in memory, and returns it in a different format on an http endpoint

Oh, release builds do take longer.

My point of view is that while developing you don't need the `--release` flag, so you can get a more or less fluent experience. The few times where you need to release an app it takes longer, but for me that's acceptable.

Post reply on HN