Can the crystal compiler create shared libraries, which I can access from other languages, e.g., python, R etc.?
Unfortunately no, it need some runtime (libevent, boehm gc) which is hard (impossible?) to integrate inside a shared lib.
Crystal 1.0 – What to expect
251–260 of 351 posts
Re: Crystal 1.0 – What to expect
#252This is a great thread to plug my favourite crystal streamer: https://www.youtube.com/channel/UCaydNuV-VSO0gFSrvS9WgXg
Re: Crystal 1.0 – What to expect
#253I hope they offer aarch64 version in tier 1. Otherwise, it is not easy to cross compile for Raspberry Pi.
It's possible to have the compiler running on raspbian.
I did that with an older version, (not tested with current, but i guess it should still be possible) and it works nicely.
I found that easier than constant crosscompiling.
Re: Crystal 1.0 – What to expect
#254This is a great thread to plug my favourite crystal streamer: https://www.youtube.com/channel/UCaydNuV-VSO0gFSrvS9WgXg
Thanks for sharing this. Looks like the channel has covered variety of videos on Crystal ecosystem.
Re: Crystal 1.0 – What to expect
#255Earlier quoted context omitted.
Why is that important given Moores law and fast developer workstations? Everyone seems so preoccupied with compile speed for Crystal.
Two kinds of people: - people who routinely compile huge code bases; - people who compile an OS. C is still here because it compiles UNIX fast.
Even there compile speeds make a difference. The linux kernel is quite slow to compile, but when you make changes it doesn't take that long because it generally just rebuilds a file or two fairly quickly because of the way dependencies and changes are handled. If every driver change would require 15 minutes to build it wouldn't be nearly as popular as a platform.
I don't know how opensolaris kernel builds are, but they're not nearly as simple to wrap your head around as the linux kernel. As a result the level of participation is quite low.
Of course this is more a build issue than it is a language issue in this case.
But yes as you said the compile speed on the linux kernel is partly because it's C and not C++
Re: Crystal 1.0 – What to expect
#256Earlier quoted context omitted.
The question is legit, though.
Sure enough. Still wondering about why.
Also, this observation: in terms of developer time, compiled languages (a la Crystal, Go, Rust...) the disadvantage of compile time should be offset by much faster local test runs and even CI builds.
Re: Crystal 1.0 – What to expect
#257Earlier quoted context omitted.
Sure enough. Still wondering about why.
Also, this observation: in terms of developer time, compiled languages (a la Crystal, Go, Rust...) the disadvantage of compile time should be offset by much faster local test runs and even CI builds.
For a sufficiently big codebase, that is.
Re: Crystal 1.0 – What to expect
#258This is a great thread to plug my favourite crystal streamer: https://www.youtube.com/channel/UCaydNuV-VSO0gFSrvS9WgXg
I knew that would be Lorenzo's channel before opening the link. So many perfectly paced lessons on tremendously useful topics.
Re: Crystal 1.0 – What to expect
#259Earlier quoted context omitted.
It's not necessary strictly speaking, but it make things MUCH easier. JS in v8 has 3 (4?) layers of compilers already and each time some type changes at runtime you're taking a hit to go back to the interpreted version while functions jit compile again. There's a crazy amount of engineering effort that has to counteract a missing "this has one parameter and it's either a string or a float" annotation. In practice if…
That is because JS was not built for JIT compilation. With a dynamic language like Julia built for JIT compilation from the very start you get both much simpler and cleaner design and higher performance. It uses a method JIT so it is deterministic and easy to analyze unlike JavaScript. You can lookup ahead of time how each function will get compiled with given input types.
I'm not sure what you mean by this. Why do you think Julia was made for JIT from the beginning?
You can't analyse functions like this ahead of time:
function foo(x)
x + y
end
Re: Crystal 1.0 – What to expect
#260Ruby was one of the languages I "cut my teeth" with to some extent, and I've always loved it's syntax and guiding philosophies, but was pulled away to PHP for my job, and ended up using other things for side projects. So a project that compiles to native code but uses Ruby-like syntax is very much "what I would build if I committed to building a language". But I've kept pushing off learning it on the notion that I co…
It's very good for CLI apps, and quick one programs, web dev is decent Lucky is an awesome framework, the compile times make the code-compile-reload cycle subpar, specially if you compare it to scripting languages. Performance is normally excellent but the GC is suboptimal for some workflows, it's not yet written in crystal and it's too conservative recouping memory. The nicest side effect of crystal is that it's programs are far more likely to work on first compiles than ruby scripts, and the type system makes refactoring a large code base much safer.