[HN Gopher] Crystal 1.0 - What to expect
___________________________________________________________________
Crystal 1.0 - What to expect
Author : mfkp
Score : 330 points
Date : 2021-03-22 18:52 UTC (4 hours ago)
(HTM) web link (crystal-lang.org)
(TXT) w3m dump (crystal-lang.org)
| terracatta wrote:
| I love the idea of Crystal but I remember reading that
| compilation times can balloon very quickly for moderately sized
| apps.
|
| Can anyone who writes Crystal today dispel or confirm that
| information? I imagine the inferred typing makes building a fast
| compiler really tough.
| chrisseaton wrote:
| Was that possibly before they backed off from global type
| inference? I think that was the cause of long compilation
| times. They require you to annotate a few types manually now
| which is an effective cut.
| astrowilson wrote:
| They haven't backed off from global inference. They did move
| to require you to type collections, but methods are not
| inferred at definition but rather at invocation and it
| happens globally.
|
| There is no solution really. If you want a language to feel
| like it is dynamically typed but actually has types,
| something gotta give, and in this case it is compilation
| times. And it gets quite high fast.
| chrisseaton wrote:
| > They haven't backed off from global inference.
|
| You might know a lot more than me about the subject, so
| feel free to correct me, but I think it used to be _truly_
| global inference - as in you were expected to write the
| whole program with no annotations. But now you 're required
| to annotate instance and class variable types, because
| compile times were becoming intractable.
| astrowilson wrote:
| It is still global. Typing collections and instance/class
| variables help, you can optionally type methods, but
| anything that is not explicitly typed is going to be
| inferred during invocation and that needs to happen based
| on all callers in the whole program. Reducing the amount
| of type variables do not eliminate the global behavior.
|
| Local inference considers a predefined context, such as a
| module or a class.
| edflsafoiewq wrote:
| I just downloaded 1.0 and tried hello world. It took over 2
| seconds. I hope that's just some kind of bug.
| straight-shoota wrote:
| No, that's expected. The program you wrote might be
| minimalistic, but there is still a lot of code under the hood
| for the runtime. If you compile a program that's twice as
| complex, you should still get roughly the same build time.
| FWIW The compiler builds in about 30 seconds. And it's a
| really complex piece of software.
| blacksmoke16 wrote:
| There is a cache that was previously cold. Subsequent runs
| should be faster. However compile times are longer than other
| languages like Go.
| edflsafoiewq wrote:
| In .cache/crystal/? 2 seconds is with that. If I delete it,
| the next build takes 3.
| rienko wrote:
| This comes from my experience building a prototype cli
| application, the language itself fells very productive, and the
| stdlib is robust fast and useful.
|
| Compiling isn't fast. By the language design it won't ever be
| possible to be in the same ballpark as golang. It's common for
| us that our 5k lines app, take >1m to build in release mode as
| we added more and more dependencies for integrations with
| different nosql databases (elastic, rocksdb etc).
|
| Using LLVM as backend is great for getting top notch
| performance, but to generate multiple IR methods for each type
| signature consumes a lot of time, especially when doing
| optimisation in release mode builds. I guess it's a similar
| problem that cranelift is trying to fix in Rust.
|
| Open classes makes it hard to cache compilation results from
| dependencies / libraries.
| devmunchies wrote:
| > It's common for us that our 5k lines app, take >1m to build
| in release mode
|
| Yes, for this reason I think crystal could be one of the best
| languages for microservices or faas.
| mfkp wrote:
| Link to the direct release changenotes:
| https://github.com/crystal-lang/crystal/releases/tag/1.0.0
| johnfn wrote:
| Huh - what's the last language that got mainstream adoption
| without backing from a large company? It almost seems impossible
| these days.
|
| Ruby?
| zem wrote:
| elixir and zig seem to be good candidates for going mainstream
| liveduo wrote:
| Companies love opportunities for sponsorship to get promotion
| (and status) back. That means unless ideologically opposed
| almost all small open-source projects will get a larger company
| to backed them up. I think there are more direction and
| governance issues than financial.
| Trasmatta wrote:
| Crystal has been getting at least some funding from various
| companies. Maybe not what you would consider a large one,
| though.
| StefanKarpinski wrote:
| Julia
| astrowilson wrote:
| It depends on what you mean by mainstream and by large company
| but Clojure, Elixir, and Elm are all languages that are
| frequently on HN and they were either personal projects or
| backed by small companies (<40 employees). I think Julia too.
| macawfish wrote:
| tldr: crystal is awesome!
|
| I tried crystal recently to dump some data from a GraphQL
| endpoint into Redisgraph. I had done the same with Rust, but
| string manipulation was much simpler in Crystal (the string
| interpolation is amazing!) so it was much simpler to quickly
| throw together the queries I needed. I think for me, rust is
| something I'd use for building a solid library, whereas Crystal
| would serve more as an alternative to Go, something more for
| quickly assembling some building blocks into applications or
| doing glue stuff with decent performance.
| ibraheemdev wrote:
| It feels like Crystal it took all the best things from the
| languages I love, and put them together into one, beautiful
| language:
|
| - Elegance of Ruby
|
| - Statically type checked + global type inference
|
| - No Nulls
|
| - Go-like concurrency
|
| - Easy C ffi
|
| - High performance
|
| I really hope the Crystal succeeds and the language goes
| mainstream - this release is a huge step forward towards that.
| Congrats to the Crystal team for reaching the 1.0 milestone!
| benbristow wrote:
| > No Nulls
|
| Does it not? It has 'nil', just like Ruby. Basically the same
| thing, the docs literally say it's 'similar to null in other
| languages'.
|
| https://crystal-lang.org/reference/syntax_and_semantics/lite...
| TylerE wrote:
| It has a Nil type, not a Nil Value.
|
| So a function might return an Int or a Nil, but if you then
| try to, say, invoke a function expecting an Int on a Nil, it
| predictably blows up. An Int cannot be Nil itself.
| mumblemumble wrote:
| To expand on that, Crystal's Nil goes hand-in-hand with its
| union types. So, if you want to allow a function's argument
| to be either an integer or nil, then the parameter type is
| "Int | Nil".
|
| It's not entirely unlike how algebraic data types with a
| "None" case work in the ML family of languages.
| Shoop wrote:
| It looks like it has nullable (nilable) types [0]. So a
| variable cannot be nil unless it is explicitly marked as
| having a nilable type.
|
| [0] https://crystal-
| lang.org/reference/syntax_and_semantics/type...
| straight-shoota wrote:
| More accurately would be "no surprising nulls at runtime". If
| a value can be `nil`, the compiler forces to treat it as
| nilable. It doesn't throw random null pointer exceptions.
| amir734jj wrote:
| Very well said. Elegance of ruby I think is very important for
| ruby developers who need a performant typed language.
| christophilus wrote:
| Fast compilation times are one of the best things from the
| languages I love.
|
| I'd really love to see OCaml get true parallelism, green
| threads, and a decent HTTP server story. Then, I don't think
| I'd look anywhere else.
| The_rationalist wrote:
| All of those points are already met and in a better way by
| mature languages like e.g Kotlin. Really the only argument
| would be the "Ruby elegance" (or familiarity?) which I don't
| know. What make ruby/crystal more "elegant" (I would prefer the
| term _readable_ ) than the competition?
| nine_k wrote:
| Kotlin mostly requires JVM, Crystal does not. Kotlin is
| heavily oriented towards Java familiarity and
| interoperability, Crystal is heavily oriented towards Ruby
| familiarity, and C interoperability.
|
| Also, Crystal was first released in 2014, when Kotlin was
| like 3 years old, and 100% JVM-bound.
| pjmlp wrote:
| Me too.
|
| I don't have any use for it, however as language geek it is
| quite nice to see ecosystems blossom.
| dkarras wrote:
| I think any new programming language should have a "why?" section
| on their page. I mean obviously this language is serving a need,
| but what is it? In any case, congrats! I like the features and
| would like to give it a try some day. I'm still curious about the
| motivations of this particular language though. Anyone more
| familiar care to elaborate a bit?
|
| Edit: Ok, looks like there is a "why" section on github!
| coldtea wrote:
| > _I think any new programming language should have a "why?"
| section on their page._
|
| It's right here:
|
| https://github.com/crystal-lang/crystal
| hootbootscoot wrote:
| HTTP is a first class member of the standard library, along
| with bcrypt, JSON, and a host of other useful stuff?
|
| https://crystal-lang.org/api
|
| This is a sweet spot for anything web-server related (which is
| quite a lot, these days, considering mobile API's and such...)
|
| I would actually hesitate to use a framework for many use
| cases, although Amber and Lucky are competing for a "soup-to-
| nuts" total platform, Kemal fills the Sinatra/Express niche
| nicely, and you really find yourself wondering what you want.
|
| The "shards" module system is very nice, and no external tool
| is needed, it comes with Crystal.
|
| No need for a C FFI, you can directly wrap the C ABI or C
| libraries and call both ways (from C to Crystal, from Crystal
| to C)
|
| It's not Rust nor C nor C++ but more like a better Go, in terms
| of being a statically typed compiled language that,
| nonetheless, is garbage-collected (everything is an object,
| check the API docs I linked above) but it's syntax is like
| Ruby, and so it' basically eats Elixer and all that's lunch...
| (Lucky takes on Phoenix, Amber takes on Rails? lol)
|
| It's also extremely fast, and the memory footprint is tiny...
| (anecdotal, but a 40kloc that was around 500mb ram on node is
| currently using 12mb)
|
| The compiler catches many errors and long-running applications
| don't apparently leak memory (cough cough anything dynamic) and
| one has the feeling that the static typing is allowing stack-
| frames scoping and Boehm to play nicely together, but this is
| just anecdotal.
|
| I guess you have one way to find out "Why Crystal"
|
| Let's not HackerNews Bikeshed this to death... go try it...
| you'll probably like it.
|
| Tooling? I use gedit, so I'm the wrong guy to ask. It works
| fine on most "ruby" presets for text coloration/highlighting
| whatever you call that stuff...
| mathgladiator wrote:
| I started this with my documentation because I am still
| convincing myself that it is a good idea.
|
| http://www.adama-lang.org/docs/why-the-origin-story
| syspec wrote:
| Which is exactly why you shouldn't do worry about why until
| later.
| mathgladiator wrote:
| I'd argue it's vital to front-load the why question; before
| you can lead an effort you must believe yourself.
|
| The importance of asking why is that you validate whether a
| project is some ego trip or a legitimate finding worth
| pursuing.
| Trasmatta wrote:
| They "why" is basically having a language with the aesthetics
| and usability of Ruby, but fully statically typed with global
| type inference, and impressive performance.
|
| The downside being a relatively slow compiler. It's the
| necessary trade-off for the type inference.
| Thaxll wrote:
| The "downside" you forgot to mention a lot of important
| things:
|
| - tooling is abyssmal ( IDE etc ... )
|
| - no mutli threading
|
| - no real support, I'm not even sure if there is one paid guy
| anymnore on the project
|
| - it's still immature
|
| - they break the API all the time
| straight-shoota wrote:
| Crystal is sponsored by https://manas.tech/ and the company
| actively provides paid support to a number of commercial
| clients. Breaking changes have been really low lately. I
| have a couple of shards that work on 1.0 as well as they
| did on 0.27 or so (that's 10 major dev releases ago). And
| with 1.0 there is a guarantee to not have breaking changes
| until 2.0. I don't agree to the other points too, but
| that's more subjective.
| haolez wrote:
| Besides funding (and maybe multithreading), I'd say that
| every new language will suffer from these limitations. They
| are difficult to avoid.
| ibraheemdev wrote:
| It is a relatively new language, all of the points you
| listed are expected. The last one should be taken care of
| now that they released 1.0.
| gravypod wrote:
| > - tooling is abyssmal ( IDE etc ... )
|
| As others have mentioned this is a side effect of how young
| it is.
|
| > - no real support, I'm not even sure if there is one paid
| guy anymnore on the project
|
| If paid support is all that counts then most languages
| would fall into that.
|
| > - it's still immature
|
| Tautological. Nothing can become mature without first being
| immature.
|
| > - they break the API all the time
|
| Isn't that what a 1.x is for? A stable major version?
| offtop5 wrote:
| >If paid support is all that counts then most languages
| would fall into that.
|
| Can you name another recent programming language that
| wasn't developed in-house at a major company. Go , Dart ,
| and Rust all started out with paid teams of programmers
| working on them.
|
| Not sure if Crystal will be able to progress at a rate
| fast enough to keep people interested. Likewise, you'd
| have to be insane to try and pitch this to your project
| manager. I consider myself to be a risk taker, but even
| for my own side projects I stick to older better known
| programming languages.
|
| it feels like we keep trying to solve the same problems
| over and over again instead of utilizing solutions which
| already exist
| gravypod wrote:
| Do zig, python, elisp, Clojure, Haskell (mostly a
| research project), etc fit the bill?
| offtop5 wrote:
| Out of those Pythons the only one that's widely used in
| production, and it's been around for a long time. Python
| itself is an extremely simple language, which I think can
| work as one person passion project.
|
| Modern python has grown significantly from its first
| release in the 90s though. I don't think that can happen
| today, we all want too much out of our programming
| languages.
| lgessler wrote:
| I can't speak to the others on the list but it seems odd
| to say Clojure isn't being used widely in production.
| Clojure's been powering big businesses for years now and
| Nubank, which primarily uses Clojure, is valued at $24bn:
| https://www.pymnts.com/news/investment-
| tracker/2021/brazilia....
| lemming wrote:
| All these companies, and more, are using Clojure in
| production: https://clojure.org/community/companies.
| pansa2 wrote:
| > _Python itself is an extremely simple language_
|
| Unfortunately that's not true at all - Python is far from
| simple. Sure, it's no C++, but it's very complex compared
| to languages like C, Go, Lua, even JavaScript.
| Trasmatta wrote:
| Those downsides aren't intrinsic to the design of the
| language, and are likely to be present for any new,
| immature language.
|
| The compile times are largely a side effect of the
| underlying language design, and it isn't likely to get
| significantly better, which is why I mentioned it.
| dkarras wrote:
| See, when you add "performance" to those properties it piques
| my interest. I'd love me a high performance language that is
| sanely typed, allows for metaprogramming, feels like an
| interpreted language while doing so etc. However the main
| page says absolutely nothing about performance. I even don't
| care about compile times.
|
| So what is the performance like?
| Trasmatta wrote:
| You can find some benchmarks here:
| https://github.com/kostya/benchmarks
|
| With the caveat of course being that benchmarks don't
| always reflect real world performance.
| elviejo wrote:
| thank you! this summary is enough for me to try it!
| [deleted]
| dang wrote:
| If curious, here are the significant past threads I found.
| Others?
|
| _An Introduction to Crystal_ -
| https://news.ycombinator.com/item?id=26217013 - Feb 2021 (39
| comments)
|
| _Switch from Ruby to Crystal_ -
| https://news.ycombinator.com/item?id=25005780 - Nov 2020 (35
| comments)
|
| _Go vs. Crystal Performance_ -
| https://news.ycombinator.com/item?id=23615303 - June 2020 (160
| comments)
|
| _Ruby vs. Crystal Performance_ -
| https://news.ycombinator.com/item?id=23431941 - June 2020 (148
| comments)
|
| _Crystal 0.34_ - https://news.ycombinator.com/item?id=22800139 -
| April 2020 (31 comments)
|
| _Towards Crystal 1.0_ -
| https://news.ycombinator.com/item?id=22725829 - March 2020 (32
| comments)
|
| _Crystal 0.33_ - https://news.ycombinator.com/item?id=22331005 -
| Feb 2020 (42 comments)
|
| _Nim vs. Crystal_ -
| https://news.ycombinator.com/item?id=21883882 - Dec 2019 (147
| comments)
|
| _Lilith: x86-64 OS written in Crystal_ -
| https://news.ycombinator.com/item?id=21860713 - Dec 2019 (251
| comments)
|
| _Crystal 0.31_ - https://news.ycombinator.com/item?id=21053366 -
| Sept 2019 (15 comments)
|
| _Parallelism in Crystal_ -
| https://news.ycombinator.com/item?id=20897029 - Sept 2019 (41
| comments)
|
| _Crystal 0.29_ - https://news.ycombinator.com/item?id=20110253 -
| June 2019 (7 comments)
|
| _Crystal 0.28.0 Released_ -
| https://news.ycombinator.com/item?id=19694006 - April 2019 (30
| comments)
|
| _Crystal 0.27.0 released_ -
| https://news.ycombinator.com/item?id=18370498 - Nov 2018 (36
| comments)
|
| _Crystal 0.26.0 released_ -
| https://news.ycombinator.com/item?id=17753367 - Aug 2018 (40
| comments)
|
| _Crystal 0.25.1 released_ -
| https://news.ycombinator.com/item?id=17424639 - June 2018 (152
| comments)
|
| _Crystal 0.25_ - https://news.ycombinator.com/item?id=17319689 -
| June 2018 (68 comments)
|
| _Why Crystal Is My Next Language_ -
| https://news.ycombinator.com/item?id=17280969 - June 2018 (192
| comments)
|
| _The Crystal Programming Language_ -
| https://news.ycombinator.com/item?id=16842442 - April 2018 (73
| comments)
|
| _Why I 'm excited about Crystal in 2018_ -
| https://news.ycombinator.com/item?id=16221053 - Jan 2018 (7
| comments)
|
| _Crystal 0.24.1 released_ -
| https://news.ycombinator.com/item?id=16021965 - Dec 2017 (22
| comments)
|
| _Overview of the Crystal language_ -
| https://news.ycombinator.com/item?id=15945262 - Dec 2017 (90
| comments)
|
| _Crystal in Production: Diploid_ -
| https://news.ycombinator.com/item?id=15574714 - Oct 2017 (120
| comments)
|
| _Journey from Node to Crystal_ -
| https://news.ycombinator.com/item?id=15240984 - Sept 2017 (6
| comments)
|
| _Crystal Lang vs. Node.js vs. Go Benchmarks_ -
| https://news.ycombinator.com/item?id=14368050 - May 2017 (10
| comments)
|
| _From Ruby to Crystal: A Quick Look_ -
| https://news.ycombinator.com/item?id=13949353 - March 2017 (43
| comments)
|
| _Building a Command-Line Application with Crystal_ -
| https://news.ycombinator.com/item?id=13945591 - March 2017 (33
| comments)
|
| _Porting Ruby to Crystal_ -
| https://news.ycombinator.com/item?id=13837109 - March 2017 (34
| comments)
|
| _A new year resolution to have Crystal reach the 1.0 milestone
| in 2017_ - https://news.ycombinator.com/item?id=13281333 - Dec
| 2016 (78 comments)
|
| _The Crystal Programming Language_ -
| https://news.ycombinator.com/item?id=13209575 - Dec 2016 (193
| comments)
|
| _Crystal: Fast as C, Slick as Ruby_ -
| https://news.ycombinator.com/item?id=12223395 - Aug 2016 (429
| comments)
|
| _Kemal: Fast, simple web framework for Crystal_ -
| https://news.ycombinator.com/item?id=11143811 - Feb 2016 (16
| comments)
|
| _The future of the Crystal language_ -
| https://news.ycombinator.com/item?id=10803635 - Dec 2015 (36
| comments)
|
| _Crystal-Lang - Beauty of Ruby, Faster Than Go_ -
| https://news.ycombinator.com/item?id=10014178 - Aug 2015 (31
| comments)
|
| _Amethyst - Rails inspired web-framework for Crystal language_ -
| https://news.ycombinator.com/item?id=9716508 - June 2015 (8
| comments)
|
| _Crystal Language_ -
| https://news.ycombinator.com/item?id=9669166 - June 2015 (171
| comments)
|
| _Crystal: the programming language_ -
| https://news.ycombinator.com/item?id=8658358 - Nov 2014 (51
| comments)
|
| _Meet Crystal language in its birthday. It is compiled and has
| ruby like syntax_ - https://news.ycombinator.com/item?id=6342609
| - Sept 2013 (84 comments)
| wiremine wrote:
| This is great, thanks for putting in the time to put this
| together!
|
| Side note: Anybody know of tools that auto-compile lists like
| this? I'm sure it's not perfect, but these sorts of reviews
| really add value to the current conversation.
| kryogen1c wrote:
| well! allow me to share a feature i discovered a few days ago
| after reading for years.
|
| when you browse via the web (unsure which apps support this
| feature), clicking the title - in this case, Crystal 1.0 -
| does what you expect and takes you to the article. in tinier
| font next to the title - in this case, (crystal-lang.org) -
| is a link that shows all the previous HN submissions for that
| website, which happens to be pretty similar to what dang
| posted.
|
| this wont work for platforms like medium or reuters, but is a
| big head start for a single-issue website like this.
| nitrogen wrote:
| Speculating: since dang is HN's main moderator, there might
| be some tools built into either HN or HN search that help
| with those types of lists, possibly related to dupe
| detection.
| dang wrote:
| Yes - some explanation at
| https://news.ycombinator.com/item?id=26245003 and the link
| back from there.
| dorianmariefr wrote:
| It just proves there is a strong interest in Crystal
| mathgladiator wrote:
| Wow, this is a great compilation! While I'm not using Crystal,
| this is a great "marketing plan" for any new language.
| yxhuvud wrote:
| Dang, that posted the list, is a moderator. It is probably
| pretty safe to say he is posting the list for the sake of
| curious readers rather than for marketing purposes.
| samuell wrote:
| Congrats on the release!
|
| The biggest factor drawing me to experiment a little with Crystal
| is that it is one of very few languages providing what otherwise
| has been pretty unique to Go: Lightweight threads+Channels+M:N
| concurrency (automatically multiplexing the lightweight threads
| onto a smaller number of OS threads).
|
| Also it does it with a very readable and clean syntax.
|
| Wrote a little about it, with code comparisons, before:
|
| https://rillabs.com/posts/crystal-concurrency-easier-syntax-...
| pansa2 wrote:
| > _automatically multiplexing the lightweight threads onto a
| smaller number of OS threads_
|
| For Crystal 1.0, the number of OS threads is always 1, isn't
| it? So although this provides concurrency, it's less powerful
| than Go where the same mechanism also provides parallelism.
| The_rationalist wrote:
| _The biggest factor drawing me to experiment a little with
| Crystal is that it is one of very few languages providing what
| otherwise has been pretty unique to Go: Lightweight
| threads+Channels+M:N concurrency_ This has no value proposition
| versus Kotlin coroutines and if it doesn 't have first class
| support for structured concurrency, cancelation and most
| importantly reactive streams then this language is sub-par.
| antattack wrote:
| Nim vs Crystal is an interesting read if not to just compare
| syntax (three articles span 3 years so I wonder how much has
| changed since):
|
| https://framework.embarklabs.io/news/2019/11/18/nim-vs-cryst...
| gpanders wrote:
| I hadn't heard of Crystal before reading the OP, but I agree
| that Nim seems like the most apt comparison as far as new-ish
| languages go.
| neolog wrote:
| How does it compare to Nim?
| machineko wrote:
| Nim is more mature and a with a lot bigger community with
| diffrent focus.
|
| Crystal focus is pure web trying to be Ruby and Nim is more
| like python.
| sergiotapia wrote:
| I've used both for medium sized projects.
|
| Nim was a better fit for me because: - More
| mature tools and 'beaten paths'. - much faster
| compilation times - much better cross platform support
| - more people I can reach out to for help, amazing Discord
| server - simple concurrency for my needs - tiny
| binaries - low memory usage - simple to
| understand import system. (i hated ruby's import system)
| shirleyquirk wrote:
| similar clarity and elegance of expression (crystal is a bit
| more beautiful i think)
|
| both use significant whitespace
|
| nim has better cross-platform and embedded support, as crystal
| targets llvm while nim targets c/c++/js
|
| nim has more low-level support with the tradeoff of supporting
| dangerous things like raw pointers
|
| crystal has better async imho
| maattdd wrote:
| Crystal doesn't use significant whitespace (like Ruby).
| yxhuvud wrote:
| Hmm, what can you do with pointers in nim that you can't do
| in Crystal?
| rishav_sharan wrote:
| Syntax wise: Nim is to python what Crystal is to Ruby
|
| capability wise both are incredibly powerful genral purpose
| languages
|
| For system language use, Nim is a better choice as you can use
| it with its Arc GC or no GC at all.
|
| Perf wise, Crystal seems to be marginably faster in most
| benchmarks. Though at that level the difference isn't much.
|
| crossplat wise, Crystal has no windows support while Nim has.
|
| Tooling wise; crystal IDE tools are pretty far behind that of
| Nim.
|
| Personally I like Crystal a lot due to its type system and
| syntax but you can't go wrong with either language.
| tomc1985 wrote:
| Really happy to see this go 1.0. Between Crystal and Zig it's
| nice to see C++/Rust get some competition
| genuine_smiles wrote:
| Would a developer looking a Zig/C++/Rust really also consider
| Crystal?
|
| I figured Crystal was for Ruby developers who want a good
| static type system.
| straight-shoota wrote:
| Crystal comes from a Ruby background, but it's far more than
| compiled Ruby. As a general purpose language mainly aiming at
| application development it can surely compete with any of the
| above in that field. The main objective inherited from Ruby
| is the focus on developer hapiness. While doing that it
| doesn't back down on performance or interoparability.
| nwmcsween wrote:
| Ruby is a great language, the only nits I have with it are
| error handling, types and a bit of the perlisms and shellisms
| that crept in. If Crystal fixed these I would be interested
| Doctor_Fegg wrote:
| Crystal's appeal, for me at least, is the productivity of
| Ruby with the memory efficiency and execution speed of C++.
| Static typing is just a way of achieving that, it's not
| something I'm seeking per se.
| straight-shoota wrote:
| Remember static typing is also really useful for code
| quality and avoiding hidden bugs. Some code in Ruby
| requires a ton of specs to discover bugs caused by type
| issues, while the Crystal compiler tells you immediately
| that something doesn't work out. I love Crystal's type
| system really for productivity reasons.
| sjwright wrote:
| I haven't ever understood the argument against static
| typing. I've never declared a variable and not
| simultaneously thought "this is going to be a float,
| always a float, never not a float."
|
| The only exception to this is untrusted input, but for
| that an string is usually always fine.
| pansa2 wrote:
| > _I've never declared a variable and not simultaneously
| thought "this is going to be a float, always a float,
| never not a float."_
|
| Never written generic/template code? Making that much
| easier is one of the main benefits of dynamic typing.
| onlyrealcuzzo wrote:
| Is static typing really necessary for speed?
|
| The fastest JavaScript engines and LuaJIT are closer in
| speed to Crystal than Crystal is to C.
|
| Granted - all these languages are really fast - and unless
| you're doing something INSANELY performance dependent and
| you REALLY know what you're doing - I think familiarity
| trumps all. You're almost certainly going to write faster
| Crystal code if you're a Crystal expert than you would
| write C, C++, or Rust.
| yellowapple wrote:
| I mean, as someone who previously looked at Rust and is
| currently looking at Zig, Crystal is certainly on my radar.
|
| That said, my current dayjob is around a Rails codebase, so I
| might not be representative of the normal systems programming
| crowd.
| tomc1985 wrote:
| Ruby 3 does static typing, so that would be the quickest path
| for static types.
|
| Crystal is interesting to me because its a systems language,
| using Ruby syntax and idioms.
|
| I'm a Rails developer by trade but I've been pining to go
| back into desktop GUI development. Right now the only viable
| cross-platform options seem to be Swing and Electron. I'm not
| sure what the desktop story is with Crystal but if it there
| is a workable solution based on GTK or something similar I'd
| be very happy!
| zem wrote:
| still no windows support :( desktop gui development was my
| main wish for crystal too, but ruling out a bunch of end
| users right out of the box was not an option.
| tomc1985 wrote:
| It looks like Windows support is preliminary. They are
| working on it...
| the_duke wrote:
| Crystal has a GC. I see it as more similar to the likes of Nim,
| Swift, Java or C#.
|
| It's a great language regardless.
| pjmlp wrote:
| My experience porting C++ stuff into Java/.NET, with
| occasional native libs, most of the time using a GC based
| language is more than enough for the expected system
| performance.
|
| Naturally it requires understanding the whole stack, how to
| improve performance in general, picking the right data
| structures and algorithms as well.
|
| Of course, there are scenarios where that might not be
| enough, and that is where a C or C++ native library might
| come into play.
|
| No need to be siloed into a single language.
| tomc1985 wrote:
| Ah! I hadn't thought of those, though I think because 3 out
| of 4 are tied to a specific platform
| coder543 wrote:
| I think you mean 1 out of 4?
|
| Swift is the only one on that list that really feels tied
| to any particular platform.
|
| C# has been extremely portable for years now thanks to .NET
| Core. Even SQL Server runs on Linux these days, if you
| really just enjoy spending money.
|
| Java has always had a strong focus on portability, of
| course.
|
| Nim... I don't know much about. Doesn't it compile to C? I
| don't think it intentionally has any particular platform
| affinity, although I wouldn't be surprised if it worked
| best on Linux.
| tomc1985 wrote:
| C# is tied to .net, and the cross-platform story on that
| framework is...complicated
|
| Java is tied to JVM
|
| Swift is tied to MacOS.
|
| Of course, with the exception of JVM, they are all
| nominally "cross-platform" in the OS sense of the word.
| But I haven't seen any substantial Linux/Mac .Net
| codebases yet, same with Swift on Windows
| kureikain wrote:
| Anyone want to try out Crystal and not familiar with a static
| type system, please don't let that discourage you. Crystal type
| infering is really good to the point you go pretty far without
| any manually type def.
|
| To me, dealing with JSON is always a challenge in truly static
| type language. Crystal solved it very nicely https://crystal-
| lang.org/api/1.0.0/JSON/Serializable.html
| cl0ne wrote:
| Congrats to the team! I've been trying out Crystal and Amber
| recently and have really enjoyed using it.
| jug wrote:
| Thanks for mentioning Amber! I assume it's this project:
| https://amber-lang.net/
|
| I've long wanted to get into Smalltalk and this looks like a
| very nice, modern way of doing so.
| robrtsql wrote:
| I think they meant this web framework:
| https://amberframework.org/
|
| There are two pretty big web frameworks in the Crystal world
| right now, one is Kemal which strives to be the Sinatra or
| Flask of the Crystal world (lightweight, supporting plugins),
| and the other is Crystal which is trying to be the Ruby on
| Rails or Django of the Crystal world (full-featured,
| opinionated).
| mfkp wrote:
| The other main one is https://luckyframework.org/ (also
| going for more of a full-featured Rails type framework)
| blacksmoke16 wrote:
| There are also other options:
| https://github.com/veelenga/awesome-crystal#web-frameworks.
|
| https://athenaframework.org is pretty unique. It's one of
| the more flexible frameworks IMO. It was inspired by
| Symfony and Spring, so takes a bit of a different approach
| as most other frameworks come from a more Ruby background.
| woodruffw wrote:
| Congratulations to the Crystal team. I've been following
| Crystal's development since around 2016, and it's been a long
| journey for a large group of incredibly dedicated contributors.
|
| One step closer to a world of static, Ruby-like expressivity!
| vasilakisfil wrote:
| Crystal is a beautiful language, however compiling times is
| something that put off most people who try it. How comes and they
| don't allow you to optionally provide types in your
| function/class signatures so you can help the compiler and speed
| up the whole process ? I mean global type inference is nice, but
| giving the option to specify types and speeding up the compiling
| time would be even more nice.
| colesantiago wrote:
| Rust also has a very slow compiler but I also see ex-rubyists
| using it?
| kickscondor wrote:
| I'm new to Crystal - have been using it the past three months on
| a new web API. (I'm using the Lucky framework -
| https://luckyframework.org/)
|
| It's fantastic. I can think in it. Thank you to all the devs
| behind this wonderful language!
| yellowapple wrote:
| Exciting news. Windows and multithreading are still showstoppers
| for me, unfortunately, but with the progress over the last couple
| years I'm hopeful that there's a light at the end of the tunnel
| on those fronts, especially now that the language itself is
| (ostensibly) stable.
| rienko wrote:
| multithreading is working with the -Dpreview_mt option, it's
| decent if the units of work are large enough at least 0,01ms,
| otherwise the channel overhead will dominate.
|
| I find the API nice and easy specially for those familiar with
| CSP or go. Performance should improve once it gets the
| necessary love for it to be released to be on by default.
|
| Windows requires a lot of boring work, especially considering
| most of the core devs use Linux / MacOS. Once they make it as
| priority it should be doable within a few months of work.
| bovermyer wrote:
| I've been waiting for this. I played around with Crystal earlier
| in its development, and even threw some money the devs' way to
| help with costs.
|
| Now I'm going to spend time writing something non-trivial in
| Crystal. Very excited!
| denysvitali wrote:
| I really need to give Crystal another try. It was a very good
| language 2-3 years ago, but it was not "production ready" and had
| a lot of breaking changes. I'm glad to see it reaching such a
| nice milestone, I'll definitely give it another try and hopefully
| fall in love with it again :)
| joshlk wrote:
| Love the idea... could someone do a similar idea with Python.
| dartharva wrote:
| Nim?
| derjames wrote:
| Genie?
| owaisin wrote:
| https://youtu.be/uFr6R8E03UQ
| freediver wrote:
| Really excited for Crystal.
|
| We embarked on a huge project (search engine) using Crystal a
| year ago after also considering Rust. We have been very satisfied
| with the exceptional performance, language capabilities and the
| community.
| unixhero wrote:
| Whoa. I will try it now. Finally it is ready for prime time:)
|
| Plugging this great howto video, which I didn't make
| https://youtu.be/DxFP-Wjqtsc
| revskill wrote:
| Waiting for Crystal On React (not Rails)
| Trasmatta wrote:
| There are a few web frameworks for Crystal, so you could easily
| add React to one of those for the frontend
| nlh wrote:
| I'm a huge Crystal fan and spoke at the first user conference
| recently about my project which is _almost_ what you 're asking
| for:
|
| https://nlh.me/projects/celestite
|
| It's a way to tightly integrate Crystal + Svelte, including
| server-side rendering and the ability to write your frontend
| purely from components.
|
| Not React (yet), but it's heading in that direction...
| maattdd wrote:
| Crystal is one of my most productive language for small project
| web oriented (Slack bot): a cleanup Ruby with added benefits
| (performance, type safety, null safety, proper concurrency).
|
| My only complaints: * compilation speed * type inference is
| sometimes not intuitive (class members * too OOP oriented (no
| constness, no UFCS/pipeline, no general monad operator,...etc)
| geordee wrote:
| Congratulations
___________________________________________________________________
(page generated 2021-03-22 23:00 UTC)