[HN Gopher] A look at Crystal, a programming language for humans
___________________________________________________________________
A look at Crystal, a programming language for humans
Author : fork-bomber
Score : 224 points
Date : 2023-05-04 06:28 UTC (1 days ago)
(HTM) web link (www.deusinmachina.net)
(TXT) w3m dump (www.deusinmachina.net)
| notmypenguin wrote:
| There's really a lot to be said for an easily readable relatively
| terse language that compiles to a tiny binary executable with low
| memory usage and can be run as a service, profiled, etc.
|
| We use it extensively in production. I really would only ever
| consider Rust as an alternative, it's _that_ good.
| segfaltnh wrote:
| What's your largest Crystal code base? How are the compile
| times?
|
| I've only done toy stuff in Crystal and super curious about
| "real world" experiences.
| zw963 wrote:
| For "real word" experiences, check Crystal lang itself, and
| lucky, mint-lang, those are not toy stuff.
| pmarreck wrote:
| it's = "it is"
|
| otherwise it's "its"
|
| he or she makes this grammatical error multiple times
|
| if you don't know which to use, if you can substitute "it is" and
| it makes sense, then use "it's", otherwise not
| lgreiv wrote:
| I wish Crystal would take off. It has so many things going for it
| (many of them mentioned in the article): performance, useful
| tooling such as an opinionated formatter, an integrated RSpec-
| like test framework, a powerful standard library, an awesome type
| system that gets out of the way most of the time, a familiar
| syntax.
|
| So far I have been building some smaller personal CLI tools and a
| few web apps (with the Lucky framework). I've also tinkered with
| running it in AWS lambda functions in a custom (albeit
| unfinished) runtime.
|
| Coming from a decade of Ruby, due to the similar syntax and
| mindset Crystal is my go to for cases where I need performance or
| runtime-less execution (e.g. in containers from scratch that
| contain only the binary and dependencies, if needed).
|
| Crystal's standard library provided enough functionality for me
| in the past to get away with only few dependencies per project,
| which is great for supply chain security and complexity. Some of
| it's highlights are: - an ergonomic HTTP::Server
| and client - OAuth / OAuth2 clients with token refresh
| - JSON/YAML/XML parsing/generation/mapping - JSON/YAML
| mapping to classes - native templating similar to ERB
| KRAKRISMOTT wrote:
| Their development team is slow ass. They live in an idealistic
| world where Windows users are not worth supporting. Bugs and
| features take too long to fix and ship. Feels more like a toy
| enthusiast project relying entirely on organic growth. It
| cannot survive in a world where the most successful programming
| projects have full-time corporate backed teams.
| alwaysbeconsing wrote:
| It looks nice, I've been wanting to try it. Regarding tooling,
| how is the debugger/debugging support?
| lgreiv wrote:
| It's a bit of legwork, but it's there.
|
| https://github.com/amberframework/docs/blob/master/examples/.
| ..
| norman784 wrote:
| I also wished for a long time for Crystal to take off, but now
| having Go and Rust I don't see Crystal to gain too much
| relevance in the future, while it might be appealing to Ruby
| devs, Ruby is becoming better every day, but still Ruby devs
| stay in Ruby because of the ecosystem, the company where I work
| on already decided that no new project will be written in C,
| C++, Ruby, Java and instead use Go or Rust, I suppose that
| other companies are doing the same.
| capableweb wrote:
| > , but now having Go and Rust
|
| If you go for Go or Rust you would never go for something
| like Crystal regardless, as they have different focuses. Just
| like Ruby, Crystal optimizes for code legibility and
| expressiveness, which both Go and Rust never really cared
| about, as it's about stability + performance (in the case of
| Golang) or safety + performance (in the case of Rust). Both
| of Go and Rust have horrible syntax compared to Ruby/Crystal,
| which is a fine tradeoff to make in cases.
| bcrosby95 wrote:
| Rust is pretty expressive. Horrible syntax... that's just a
| subjective measure. I wish programmers would get over it,
| because it's a huge hindrance to trying a large number of
| languages out there with lots of nice things. But people
| are gonna be people, so it won't happen.
| capableweb wrote:
| Yeah, I agree that it's highly subjective. And I don't
| mean that people shouldn't chose something just based on
| one variable, it obviously depends. No language is
| perfect for every use case. Personally I use Rust for a
| lot of things, even though I'm more productive in other
| languages, but sometimes it's just a really good fit for
| the problem.
|
| Pseudo-code, but this is how I see the difference in
| expressiveness and syntax: 3.times {
| println('Foobar') } for i in 0..3 {
| println!("Foobar") }
|
| Both of them makes sense though, so not a huge
| difference, but it's the same way in lots of ways in Rust
| in general.
|
| > because it's a huge hindrance to trying a large number
| of languages out there with lots of nice things
|
| I know exactly what you're talking about, as most of the
| time I work in Clojure, and trying to show Clojure to
| other programmers who are used to C-like languages and
| never heard of any lisp-like language is a constant
| struggle, as their first reaction is always "eww,
| parenthesizes everywhere!" even though their favorite
| language usually has the same amount or even more.
| kmac_ wrote:
| Ruby is fine until your large application starts to
| include more and more dependencies. There is no coherent
| API across, every library has it's own mini DSL and the
| mess starts to build up. Then it comes method_missing,
| monkey patching and strings and dictionaries passing in
| all the places. True horror. All Ruby's readability
| dissapears. Small apps look beautiful, but large ones
| quickly become a mess. On top of that resource
| utilization is atrocious. But there are places where Ruby
| shines like RSpec, Rails, pry in runtime (I miss that
| one).
| shrimp_emoji wrote:
| Rust is spiky, like a crab.
| JohnFen wrote:
| I've been learning Rust over the last few months, because
| it seems like a good language to have on my CV.
|
| It's certainly a taste thing, but I am not enjoying it at
| all. I find it unpleasant. I think it's going to join the
| short list of "languages I can use but would prefer not
| to".
|
| I've never learned Crystal, but if it's like Ruby, then I
| think I'd enjoy it just fine.
| aatd86 wrote:
| That must be subjective because Go's syntax is pretty fine
| to me.
|
| To illustrate, when I started learning Go, I implemented
| Concurrent Hash Array Mapped Tries from some PhD thesis and
| the pseudo code algorithm actually looked pretty much like
| the Go code. A testament to how legible it is.
|
| Then again, I have never tried ruby so I can't compare.
| caseyohara wrote:
| Apples and oranges. Ruby is very, very expressive
| compared to Go. Go's legibility comes from the simplicity
| of its syntax, Ruby's legibility comes from its
| expressive syntax.
| galangalalgol wrote:
| Can you give either an example or explanation of what you
| mean by expressive syntax? People talk about it but I
| don't really know what they mean.
| ghotli wrote:
| Ruby was one of my first languages and for awhile I
| described it as 'programming in english' especially Rails
| with the ActiveSupport gem. I often just fired up IRB
| (the repl) and guessed what function names I could use on
| a given object and it worked. I think this is why a lot
| of DSLs ended up in Ruby (chef, etc) plus the
| method_missing idiom allowed for a lot of this sort of
| expressivity at the expense of sometimes being thoroughly
| confused as to where a method was defined.
|
| Overall I ended up writing more performance oriented
| applications and ruby (at least at the time) wasn't worth
| the 'it's pleasant to read and write' vs 'this ruby
| script that used to take a day now takes 15mins written
| in a language more suited for the task'. The other
| language I'd consider less expressive just in a less
| optimized-for-the-human-while-writing kind of way.
|
| Crystal seemed nice in the respect that it might be the
| best of both worlds, but like mentioned elsewhere here
| it's still fairly niche.
| galangalalgol wrote:
| I looked at the activesupport gem and I think maybe the
| things we call general purpose languages are actually
| just really broad domain specific languages. From the gem
| description "Rich support for multibyte strings,
| internationalization, time zones, and testing.". I do
| testing, and occasionally I have a string, but mostly I
| only do numeric programming, I don't think of that as a
| niche. Fortran was/is for numeric programming I think of
| numeric programming as the default normal sort of
| programming. That probably isn't so much the case
| anymore, but we probably all think of our domain as the
| normal one. So expressiveness is probably highly relative
| to the domain. Julia seems very expressive to me. So do
| rust and modern c++. But I don't do much string handling,
| and I don't really even know what internationalization
| means.
| pmontra wrote:
| I stay in Ruby because my customers want Rails and because my
| own scripts don't need to be fast. Edit and run is one step
| faster than edit, compile, run.
| vidarh wrote:
| As a Ruby dev, that Crystal is "close but different" means I
| know I won't be able to use my Ruby code but at the same time
| I get too little in return to make it feel worthwhile.
|
| For the very rare circumstances where Ruby is too slow for
| what I need to do, there's usually code in some other
| language I can wrap in an extension, and that code is far
| more likely to be C or some other more established language
| than Crystal.
| npn wrote:
| To me Crystal is actually a more polished Ruby
| implementation. There was some annoying inconsistent in
| ruby stdlib that was corrected in Crystal, for example the
| modules for file/directory interaction.
|
| Ruby was my main language for scripting, but I switched to
| Crystal completely after getting comfortable with it. Now
| it is really hard to switch back to Ruby.
|
| Also, I thing compiled language is the greatest friend for
| older programmers. Over the time I'm getting more and more
| sloppy and very often make some typing error. Crystal being
| compiled language saved me countless time by refusing to
| compile when I made the mistake. Meanwhile in Ruby it can
| only be found after the script ran for a while, sometime it
| became a disaster because the action was destructive.
| vidarh wrote:
| The thing is, any annoyance in the stdlib you can paper
| over with gems if you want, and still be able to keep
| using all the libraries out there.
|
| As for the type checking, Ruby is getting more and more
| _opt in_ type checking, so that reason is slowly
| diminishing as well.
| pelasaco wrote:
| Exactly.. I was a Crystal enthusiast, but because of their
| slow development pace and small community, half-baked
| documentation (all understandable, no critics here) and the
| raise of Go (great documentation, fast pace development, huge
| community), was hard to keep focus on that. Go became my
| option to ruby, and I'm doing fine with that.
| actionfromafar wrote:
| I can't suffer Go. C, Rust, C++, Ruby Python, Java, C#,
| VB.Net are all fine, F# looks cool too but I never used it.
|
| I started to use Crystal in a small commercial project, as
| a web backend, and it was very fun and promising.
|
| But the project got cancelled for completely unrelated
| reasons.
|
| I long for an excuse to use Crystal again. Hard typing
| combined with Ruby carefree style and EXEs without
| runtime... really cool stuff.
|
| I think Crystal will crack the Win32 nut eventually.
| rookderby wrote:
| I think windows is the main thing holding crystal back. I
| make little games for jams and I'm always trying out new
| languages. I submitted a bug related to running processes
| on windows last november, it was just recently closed as
| completed. Although I spend almost all of my at-home time
| on linux, I know that I _have_ to provided windows
| executables for jams. I plan to come back to crystal when
| I can write once and can compile the same code
| everywhere.
| kashif wrote:
| I wish Nim would take off...but alas the worst languages are
| always the most popular - JS, C++ ...
| lgreiv wrote:
| Nim really looks awesome too! If I came from a python
| background, I could see me reaching for Nim rather than
| Crystal.
| Conscat wrote:
| The most flexible languages with the most advanced
| development tools are always the most popular - JS, C++
| mavu wrote:
| Counterpoint: why should I care if it "takes off"? It is a very
| much stable, fast, useful language that can be used today.
| lgreiv wrote:
| While it may be possible to onboard Ruby developers fairly
| easy, it is still easier to find talent for an ,,established"
| language. For my personal projects, I gladly use Crystal, but
| in my professional role as a technical decision maker I need
| to factor aspects like this in.
| ARandomerDude wrote:
| The more people use it, the more jobs there will be for it,
| and the more the ecosystem will flourish.
| webkike wrote:
| You get more and better libraries if the language is popular.
| Your favorite APIs (such as AWS for example) implement
| clients in the language
| Koshkin wrote:
| More, of course. But better? Percentage-wise, unlikely.
| webkike wrote:
| Maybe not if you consider good as a threshold, but the
| quality of good libraries will improve with a larger pool
| of skilled contributors
| biql wrote:
| I wonder if the lack of libraries in a new language is just
| a few ChatGPT-integrations away. After all, Crystal is so
| similar to Ruby. I bet as soon as context/environment aware
| ChatGPT tools/agents that can compile / run tests / apply
| fixes until it works are available, this will become the
| reality: "Create this Ruby library but for Crystal" and in
| a few hours you can include it in your Crystal project.
| [deleted]
| webkike wrote:
| I would personally never use a chatgpt transliterated
| library
| pelasaco wrote:
| all those features are offered by Go too.. The similarities
| among ruby and crystal are normally easy to spot in small
| projects, but their differences get really visible in big
| projects.
| rowanG077 wrote:
| Go's type system is anything but nice
| moe wrote:
| Go is not a good comparison.
|
| Crystal is expressive, 500 lines of Go commonly translate to
| 50 lines of Crystal. The DX in Crystal is really closer to
| Ruby than to Go. It's essentially a very fast and type-safe
| version of Ruby.
| unrealhoang wrote:
| > 500 lines of Go commonly translate to 50 lines of Crystal
|
| This is a vast exaggeration. And even if I grant it, it's
| still thousand of loc that you don't have to write because
| of available libraries.
| DennisP wrote:
| Although they do try to make it easy to use C libraries:
|
| https://crystal-
| lang.org/reference/1.8/syntax_and_semantics/...
| antifa wrote:
| IMO crystal's value is that I can do things normally
| associated with golang without the horrors of actually
| dealing with golang's absence of a good type system and
| other quirks like error handling.
| [deleted]
| pelasaco wrote:
| > The DX in Crystal is really closer to Ruby than to Go.
|
| Me as polyglot can say that is much easier to switch
| completely between languages and paradigm than write or
| talk similar (but not equal) languages. So it is maybe a
| great reason for beginners to start to play with Crystal as
| Rubyists, but as soon as you start to work daily with the
| language, other factors like good documentation, tons of
| examples, great standard lib, active community and
| development, etc are much more important than if its
| remembers ruby or not.
| mirekrusin wrote:
| Maybe with LLMs it won't matter much anymore? Maybe in
| the near future we'll have copilot for crystal as vscode
| plugin and the rest doesn't matter much - just quality of
| this plugin?
| yellowapple wrote:
| At that point, why bother with high-level languages at
| all? A sufficiently-good AI should be able to read a
| specification / test suite and directly generate a binary
| which passes those tests.
| mirekrusin wrote:
| Maybe. Or maybe it'll become validation/what-is-happening
| lowest denominator. Programming languages are also a good
| Intermediate Language between humans<->machines and
| machines<->machines apparently due to recent AI
| advancements.
| aatd86 wrote:
| What will your LLM be trained on?
|
| It only makes the problem even more acute I think.
| vidarh wrote:
| Yesterday I told ChatGPT:
|
| > We're going to write a program in a "new" language that
| is a mix of Ruby and INTERCAL. We're going to take the
| "come from" statement and use it to allow "hijacking" the
| return of a function. Furthermore, we're going to do it
| conditionally. "come from <method> if <condition>" will
| execute the following block if <method> was executed and
| <condition> is true. In <condition>, "result" can be used
| to refer to the result of executing <method>.
|
| And that was enough to get it to understand my example
| code and correctly infer what it was intended to return.
|
| Given it took that little, I don't think you need much
| code in a new language before you have a reasonable
| starting point as long as you can give examples and
| document the differences, and then use that on a few
| large projects that has good test suites, and work
| through any breakage.
| aatd86 wrote:
| You still need libraries and the ecosystem.
|
| If it can't find those, then because there is no training
| data, best case scenario is that it will hallucinate APIs
| that don't exist.
| mirekrusin wrote:
| But that's the thing, libraries are written and it should
| be able to just read/learn/train on it, that's all.
| vidarh wrote:
| If the LLM understands the language it can aid in
| _creation_ of the libraries and ecosystem because it can
| also translate code. I just tested it by having ChatGPT
| translate one of my Ruby scripts to Python for example.
|
| I don't like Crystal all that much, but it's similar
| enough to Ruby that if ChatGPT can handle Ruby->Python,
| it can handle Ruby->Crystal with relatively little work.
|
| But it doesn't need to handle it flawlessly, because
| every new library you translate and fix up gives you a
| new codebase you can use to finetune it.
| mirekrusin wrote:
| We need RLHF -> RLCF/RLIF/RLEF (Reinforcement Learning
| from Compiler/Interpreter/Execution Feedback).
| mirekrusin wrote:
| Ideally on source code so it knows standard library and
| how to use it with enough comprehension to be useful.
| straight-shoota wrote:
| Crystal core developer speaking:
|
| I think this argument is less about the concrete
| syntactical and semantic similarities to Ruby, but the
| shared general idea to focus on developer happiness. For
| example, code is easy to read, yet still expressive.
| Thaxll wrote:
| Crystal won't take off because it's an "amateur" language, to
| have a good and properly supported language you need a lot of
| poeple and money, which Crystal has not.
|
| I would not rely my business on a language where there is just
| one full time dev working on it and relying on donations.
| rco8786 wrote:
| This reads a bit like a tautology..."Crystal has not taken
| off because Crystal has not taken off".
| avg_dev wrote:
| I'm not sure that I agree with the poster you are replying
| to, that Crystal won't take off, but I'm pretty sure that
| the statement "Crystal has not taken off because Crystal
| has not taken off" is kind of useful/valid/worthwhile. I
| believe that this is how network effects work.
|
| I also am pretty sure I read about someone here on HN who
| used Crystal to build the code for their profitable cookie
| baking/selling business (the baked goods). I can't recall
| the details exactly. Edit: Here it is:
| https://news.ycombinator.com/item?id=23433847
| Thaxll wrote:
| Crystal has been going on for years and there is still no
| major support, it won't change, basically if you're a new
| lanague you have a couple of years after that you just
| missed the train.
| nindalf wrote:
| Not historically true. Python didn't take off for years
| after the initial release in 1991. Even in the mid 2000s
| people were evangelising Python like it was a new thing
| (https://xkcd.com/353/)
|
| Or take Rust, which has gained adoption more recently. It
| took a while to get going after the 1.0 release in 2015.
| If you look at daily downloads of Rust crates
| (https://lib.rs/stats) as a proxy for adoption:
|
| - 2015 to 2017 - not many downloads
|
| - 2018 - first signs of real growth, reaches 1M per day.
|
| - 2018 to 2021 - 10x growth, 10M per day
|
| - 2021 to 2024 - 10x growth (projected)
|
| So new languages shouldn't lose hope if they don't see
| adoption immediately. It's possible that they might be
| adopted later. But for language authors, it's the hope
| that kills you. You continue working on it even if maybe
| you shouldn't.
| viraptor wrote:
| Another one: nix started in 2003 but hasn't really
| entered the common usage/popularity until the last 4 (or
| so) years as far as I can tell.
| ModernMech wrote:
| Define "shouldn't". Working on a language is a gift in
| itself.
| nindalf wrote:
| Sure, let me define "shouldn't". For those authors who
| hope to see their language become mainstream and achieve
| widespread adoption, they may want to cut their losses.
| If they're working on it for intrinsic reward they should
| continue, by all means.
| dragonwriter wrote:
| No, its quite possible for a language to have strong
| backing before it takes off (C#, JavaScript, Go, Swift,
| Dart, Rust all did, to varying extents, from day one) and
| those tend to also be the langauges that take off quickly.
| Other languages struggle until they attract either a
| sufficient mass of distributed backing or the one key
| backer that gives it the level of support and visibility
| that supports the adoption curve taking off, and most never
| reach that point.
| stakhanov wrote:
| > because it's an "amateur" language
|
| Python was an amateur language until it was not.
| capableweb wrote:
| Even Rust started as a "amateur" language until it was
| picked up by Rust.
|
| Nothing is saying that Crystal won't be picked up just like
| Rust was, by some company.
| pritambarhate wrote:
| Yes and Python (released in 1991) took a lot more time to
| become popular compared to Java (released in 1995) which
| was corporate backed.
|
| Python still seems to have funding issues. For example, JS
| (backed by multiple big corporations) performance has
| improved a lot compared to Python. The main Python
| implementation doesn't have a proper JIT as far as I know.
|
| So it shows the difference between amateur languages and
| corporate backed languages.
| hgs3 wrote:
| > Yes and Python (released in 1991) took a lot more time
| to become popular compared to Java (released in 1995)
| which was corporate backed.
|
| Being corporate backed is the real answer. Languages that
| became popular through grassroots support are the
| exception, not the rule.
| chubot wrote:
| This isn't quite true. Python was certainly Guido's passion
| project, and it started that way. But early in its life, it
| was funded by the United States government via CNRI (under
| Bob Kahn).
|
| At every job Guido had subsequently, he had at least some
| buy-in to work on Python, and some coworkers were also paid
| to work on Python.
|
| There was a core "PythonLabs" group (I think including
| Jeremy Hylton?) that apparently moved from CNRI to the a
| startup BeOpen:
|
| https://www.computerhistory.org/collections/catalog/1027387
| 6... (I watched this whole video, there's also a couple Lex
| Fridman videos)
|
| At Google from 2005 to ~2014, Guido nominally had 50% of
| his time to work on CPython, but that's pretty fuzzy
| because he was really productive in any case. (I was his
| officemate for a couple years during that time.)
|
| https://en.wikipedia.org/wiki/History_of_Python
| p0w3n3d wrote:
| In my opinion a new programming language nowadays should focus on
| (in this order):
|
| 1. easy interfacing with existing library ecosystem (like e.g. C
| interfaces)
|
| 2. nice testing framework
|
| 3. good IDE with good context help and refactor plugins
|
| 4. syntactic sugars and improvements over other languages
| [deleted]
| [deleted]
| straight-shoota wrote:
| Crystal core developer speaking:
|
| I think Crystal shines with these focus points, except 3. which
| needs some love (but it's on our radar).
|
| 1. C bindings are nice and easy
|
| 2. The integrated spec framework builds on the syntax of rspec
| and is quite capable. Of course it's opinionated, and there are
| alternatives in the ecosystem.
|
| 3. There are some IDE plugins with basic features. Context
| awareness in source code is an intricate problem because it
| requires a lot of semantic analysis. So it needs a bit more
| effort to iron out.
|
| 4. Crystal feels like a dynamic language, yet it's fully
| statically typed. Features like type inference and union types
| make this possible.
| segfaltnh wrote:
| I bet it's hard to be motivated to build numbers 2 or 3 when
| number 4 isn't getting attention. That's why most languages
| start there, that's the raison d'etre.
| graboid wrote:
| 1) is so important. There are so many cool and interesting
| languages out there that are developed by a single person/small
| teams and which
|
| will probably never gain traction because of a missing
| ecosystem of libraries.
| avg_dev wrote:
| On (3): see
| https://en.wikipedia.org/wiki/Language_Server_Protocol?wprov...
|
| LSP is pretty well supported in editors; it has emacs and vim
| and vscode support (a lot of other support as well). It makes
| it possible for any editor that supports LSP to be language
| aware (supporting the use of code completion, syntax
| highlighting, warning and error messages, and refactoring
| tools, per the Wikipedia article). All that is needed is for
| someone to implement a language server for the language. I used
| to use Perl a few years ago and even that had some (slightly
| buggy) LS implementations, which I found very helpful.
|
| I haven't used Crystal but I did use Ruby extensively for some
| time, and having read this and some other articles about
| Crystal, I'm guessing (2) is well taken care of because of the
| aim of matching rspec functionality, and (4) by means of being
| Ruby-influenced. Not sure about (1).
| avg_dev wrote:
| Also see this comment:
| https://news.ycombinator.com/item?id=35828603 :(
| transfire wrote:
| Crystal should get more attention, from desktop application
| developers in particular. Crystal makes it much easier to
| maintain large performant code bases.
|
| Basically working with Crystal is much more like working with
| Python or Ruby, but with performance comparable to C. Unlike Rust
| or Go where you get the performance, but you don't get the huge
| bump in productivity b/c youre working at a lower level of
| abstraction.
| Alifatisk wrote:
| The burden with Ruby is that there is no clear way of shipping
| an application to the end users without requiring the end user
| to install the runtime.
|
| Crystal might be the proper solution as the syntax is almost
| identical (if not is already) and I can finally ship self
| contained binaries!
| Alifatisk wrote:
| I've had my eyes on Crystal for a couple of years, the only
| drawback is Windows support. When that's done, I might use it!
| xenonite wrote:
| ,,All the main platform features for Windows are finished" (10
| days ago)
|
| https://github.com/crystal-lang/crystal/issues/5430
| Alifatisk wrote:
| Thanks!
| actionfromafar wrote:
| Danke
| zerr wrote:
| The minimum requirement for a language to take off: first class
| Windows support. The current preview support is good enough to
| start playing. A high-performance (C-like, LLVM based) and a very
| high-level language with Ruby-like expressiveness coupled with
| static typing and compile-time (as well as runtime) safety, and
| with the ability to produce standalone native executables make it
| really one of a kind.
| pmarreck wrote:
| > The minimum requirement for a language to take off: first
| class Windows support
|
| many open source languages "made it" without this
| qualification, and I'd suggest that Microsoft has a long
| history of primarily supporting its ecosystem languages on its
| platform.
| metaltyphoon wrote:
| Can you name a language that "made it" and what you mean by
| "make it"?
| pmarreck wrote:
| Bash? Ruby earlier on? Node earlier on? Erlang? Elixir?
| Perl, earlier on? Clojure? Go earlier on? All the standard
| Unix utilities and their DSL's? (sed, awk, bc, jq, etc.)
| Apple's Objective-C/Cocoa, and Swift? Rust (earlier on)?
| Scala? Haskell?
|
| Every one of these languages' Windows support tends to lag
| their *nix support, and most are fairly widely deployed (my
| definition of "making it"). Many may support Windows now to
| some degree, but did not originally and not for their
| entire incubation period.
|
| Early Python did not have good Windows support. Neither did
| PHP... which is exactly why Microsoft basically copied PHP
| to make ASP.
|
| Hell, even C/C++ was basically fleshed out on Unixes long
| before Windows even existed.
|
| Linux (and Unix flavors before it, as well as things like
| BSD) is the premiere developer OS, period. It enjoys, by
| far, the most languages to choose from. Windows is the
| developer OS only for the Windows ecosystem of
| technologies, which is far too limiting IMHO.
|
| The fact that you've even asked this question makes me
| think you are living under a Redmond rock.
|
| If you didn't have access to WSL, you wouldn't even be able
| to fully enjoy most of these languages. Which is exactly
| why WSL exists! No one would need it otherwise!
|
| In fact, the only open-source language I can think of that
| DID premiere with first-class Windows support was Java.
| JoelMcCracken wrote:
| I'm not sure, but I would be surprised if early node had
| good windows support _before_ it became big.
| latexr wrote:
| > The minimum requirement for a language to take off: first
| class Windows support.
|
| Swift is doing quite well, and it didn't need Windows support
| to drive adoption.
| anta40 wrote:
| Swift is different niche, though. Rust, Go, Nim, D etc can be
| used for writing Mac, Linux, Windows apps.
|
| Swift is practically limited on MacOs & iOS.
| ezekg wrote:
| Swift has support for server web apps
| (https://vapor.codes/), so I assume it has some
| interoperability with other operating systems.
| latexr wrote:
| The comment I quoted claimed that for a language to take
| off it needs first class Windows support.
|
| If we're going to limit the discussion to languages which
| "can be used for writing Mac, Linux, Windows apps", then
| the argument is pointless. By definition, any language
| which can be used to write Windows apps has Windows
| support. That's circular logic.
|
| To address the argument, it _only_ makes sense to discuss
| languages which don't have1 first class Windows support.
| Everything else is irrelevant.
|
| 1 Or didn't but were still popular at that time.
| metaltyphoon wrote:
| Swift is necessary on macOS and is doing fairly poor outside
| of it because it didn't have Windows and Linux support on
| par.
| latexr wrote:
| The original comment claimed a language needs first class
| Windows support _at a minimum_ to take off. Swift proves
| that is not a hard requirement, regardless of the reason
| for its popularity: that it's the official vendor-supported
| language for a family of platforms that have been
| profitable for developers.
|
| That Swift isn't as popular outside the officially
| supported platforms isn't surprising and doesn't matter.
| The point is precisely that it didn't have to cater to a
| specific one (Windows) to achieve success.
| booleandilemma wrote:
| I have never looked into Swift, because it seems to me, as a
| non-Mac developer, like a niche, Mac-only language.
|
| In my mind, if I'm not developing for the iPhone, why would I
| use Swift?
|
| If I need to write a CLI app, why, of all languages, would I
| pick Swift?
| latexr wrote:
| > I have never looked into Swift
|
| Which is a valid choice, but it doesn't mean that it isn't
| successful or that it hasn't taken off. Swift has achieved
| exactly the goal it was supposed to: become the official
| language for Apple platforms, replacing Objective-C as the
| entry point.
|
| > If I need to write a CLI app, why, of all languages,
| would I pick Swift?
|
| _You_ probably wouldn't. Other people might, for a variety
| of reasons including enjoying the language itself. I write
| CLI apps regularly and use several languages; Swift is one
| of them.
| npn wrote:
| Almost there. From now on it it's only matter of developer
| experience.
|
| Like provide a installer which do all the necessary setup for
| you, including install Visual C++ Build Tools, LLVM and other
| stuff.
|
| Then the community need to update the libraries to make them
| run smoothly on Windows, too. But this is not that hard.
|
| My major annoyed point for using Crystal in Windows now is the
| native libraries, which need extra build steps that sometime
| not very straight forward. But I think we can overcome it with
| some extra effort from the community: provide the compiled
| lib/dll files beforehand so other people do not have to compile
| the native library all over again.
|
| This will also take time, but unlike the previous challenges,
| it's mostly the DX now.
| LVB wrote:
| Slow compile times were a real issue for me when I was trying to
| leverage Crystal. This is acknowledged as a significant (and
| challenging to solve) issue: https://dev.to/asterite/incremental-
| compilation-for-crystal-...
| npn wrote:
| Compilation time was a huge pain point for me, too. Dev builds
| took 30s to finish, completely killed the productivity.
|
| It's much better now though, after I compile the compiler
| myself, using glibc instead of musl, using LLVM 15 instead of
| LLVM 14, and disable the GC (for the compiler).
|
| Dev builds now only take 5~8s, and release builds only take ~1
| minutes instead of 2 minutes 30 seconds.
| e12e wrote:
| > I recently implemented a Brainfuck interpreter in the Crystal
| programming language
|
| Aw, a bit of a missed opportunity to write a crystal version of
| the impressive (but probably dated?) "How I start"-article for
| Nim:
|
| https://howistart.org/posts/nim/1/
| varjag wrote:
| There are two types of modern programming languages: those that
| look like C and those that look like Python.
| dym_sh wrote:
| someone discovered whitespace significance but doesnt know how
| to call it yet
| dw-im-here wrote:
| You mean there are two modern programming languages which you
| know
| varjag wrote:
| Read what I say, not what you mean.
| lkschubert8 wrote:
| + Those that look like ruby?
| quickthrower2 wrote:
| Ruby looks like Python
| d3ckard wrote:
| It does not. No language with statements is like Ruby.
| pjmlp wrote:
| If anything, Ruby looks like Smalltalk without image file.
| sph wrote:
| (concat '(c python) lisp-derived-languages)
|
| Also add Forth, Prolog, Brainfuck, Haskell/ML and Ruby. There's
| more to programming than you think.
| tmtvl wrote:
| Don't forget APL.
| varjag wrote:
| Right, because we see so many APL derived languages lately.
| varjag wrote:
| I meant the syntax of novelty languages we have on HN
| regularly.
|
| And Ruby _is_ Python-mimicry open your eyes.
| segfaltnh wrote:
| Didn't ruby and python both get created in the same
| year...?
| cristoperb wrote:
| Python was released earlier than Ruby (1991 vs
| 1993/1995), and Matz was familiar with it. But Ruby is
| clearly an attempt at an object-oriented Perl rather than
| a Python mimic:
|
| > I knew Python then. But I didn't like it, because I
| didn't think it was a true object-oriented language---OO
| features appeared to be add-on to the language. As a
| language manic and OO fan for 15 years, I really wanted a
| genuine object-oriented, easy-to-use scripting language.
| I looked for, but couldn't find one.
|
| https://ruby-doc.org/docs/ruby-doc-bundle/FAQ/FAQ.html
| chaxor wrote:
| "OO features appeared to be add-on"
|
| No one tell them about the horrors of R. That's a 'yikes'
| of a language that no one should ever use.
| pjmlp wrote:
| You forgot those that look like Pascal and those that look like
| ML.
| varjag wrote:
| Hadn't seen := in a new language in a while tho.
| pjmlp wrote:
| Walrus operator in Python.
| poo-yie wrote:
| go has it. it's not brand new, but relatively new.
| [deleted]
| anta40 wrote:
| Windows support is still under development, yes?
|
| https://crystal-lang.org/install/on_windows/
|
| I'll stick with Nim then, it's Windows support is much better. Of
| course for backend dev, Linux is usually #1 choice. Let's try
| Crystal.
| russdill wrote:
| Build support in general isn't great. The way external objects
| are linked is a bit hinky, cross compilation support is poor,
| and running multiple instances of the compiler at the same time
| on the same machine isn't supported.
| sethrin wrote:
| Not sure what you mean by that last bit. That seems like
| something handled by asdf or some other package management
| tool.
| ubertaco wrote:
| I love Crystal, and have loved it for several years. It was my
| go-to for Advent of Code or small fun projects for a while.
|
| Eventually, I got so tired of constantly jumping between browser
| docs and my editor because of the lack of a working and useful
| language server (yes, I know about Scry and Crystalline, but
| neither of them actually do autocomplete outside of maybe 2% of
| cases), and I got so used to an amazing tooling experience when
| writing F# (my other favorite language) that I just kinda dropped
| off using Crystal.
|
| Things I would've written in Crystal, I wrote in F#. If I
| _really_ needed a static binary, I picked up Rust (though I love
| Crystal's syntax _so much more_ than Rust's).
|
| If Crystal gets a good language server, heck yeah I'll roll with
| it. In the meantime, it just sorta feels like a missed
| opportunity.
| actionfromafar wrote:
| I'm afraid to try F#, I might like it too much from what I see.
|
| If only F# could compile to a single EXE.
| metaltyphoon wrote:
| It can do that already.
| pjmlp wrote:
| Native AOT is getting there.
| laurentlb wrote:
| I compile my F# application with --standalone and share a
| single exe file to my users. It still requires .NET to be
| executed (but note it works on many platforms thanks to
| Mono).
| JohnFen wrote:
| > It still requires .NET to be executed
|
| Which means it's not really standalone.
| [deleted]
| zw963 wrote:
| For friends from China who are interested in Crystal,i create the
| Github crystal-china org, https://github.com/crystal-china, and I
| also hold https://crystal-china.org domain name, although there
| is still no time to build a website.
|
| Let us discuss use Chinese in TG,Discord, and do something
| together.
| alex_lav wrote:
| I find myself getting pretty immediately turned off by IMO kind
| of silly and unverifiable catch phrases languages use as
| marketing tools. Crystal uses "a programming language for
| humans", much like EmberJS's "for _ambitious_ web developers". As
| I skim the Crystal page, it's not clear to me what is supposed to
| stand out as a language that makes it "for humans" any more than
| any other language? It just seems silly.
| slondr wrote:
| I never saw the pitch of crystal compared to Ruby with RBS.
| compumike wrote:
| For me, the pitch is performance: Crystal would be several
| times faster, while using a tiny fraction as much RAM.
|
| In my use case for https://heiioncall.com/ I ported a part of
| our system from Ruby to Crystal and we're seeing about ~10x
| faster throughput while using ~1/10th as much memory.
|
| That changes the operating economics drastically enough that,
| for example, Heii On-Call provides free website and API
| endpoint monitoring.
| mrkeen wrote:
| > I remember when I first learned about type inference, one of my
| first thoughts was, why can't we just create a statically typed
| language that does type inference for everything. The compiler
| would still have to figure out the types at compile time anyway,
| and I'd save myself a few keystrokes.
|
| > Turns out this is what Crystal does. It does aggressive type
| inferencing, and only asks you to declare types when it can't
| figure it out.
|
| > Crystal does not have a global type inference engine
| davidgrenier wrote:
| Correct me if I'm wrong, but F# has had that on inception 18
| years ago which it inherited from the ML family of programming
| languages.
|
| Though I agree it's a much saner default to ask for type
| information rather than default to Any/dyn like Julia does.
| yxhuvud wrote:
| The underlying principle in Crystal is that data structures
| usually require explicit declaration while types of values
| passed around on the stack usually don't need to be declared.
| I find it makes it easy to reason about the result while
| still being very stream lined.
| ghusbands wrote:
| As the sibling comment points out, this has been a feature of
| many functional programming languages for a long time. If you
| infer everything, though, it becomes a little unfriendly in
| use.
|
| When you make a change in one location and accidentally use the
| wrong type for something, it can affect global type inference
| and you get error messages in other locations. In essence, if
| you use only type inference, a change anywhere in the program
| can turn up as an error due to a type mismatch anywhere else in
| the program.
|
| Most languages with powerful type inference aim for a middle
| ground where important types are declared and mostly-local
| types are inferred.
| Izmaki wrote:
| So it's Python but with small syntactical differences?
| realusername wrote:
| It's more like a high-performance typed Ruby.
| ubertaco wrote:
| In the same way that a car and a boat are the same, but with
| small cosmetic differences.
| actionfromafar wrote:
| Good analogy. Right down to, that there even are cars which
| _work on water_! [0]
|
| 0: https://pypi.org/project/brackets/
| colesantiago wrote:
| Can python compile to a binary with no extra tooling?
| actionfromafar wrote:
| If shedskin becomes ready, that would be a contender. It's
| really cool, it converts Python to C++.
| sph wrote:
| Sure, if Python were Ruby-like, it had `do` blocks, static
| typing, was compiled to native language with LLVM.
|
| But yeah, it has "if", "class" and a not-great multithreading
| story like Python.
| k__ wrote:
| end end end
|
| lol, I don't think so.
| coryaf wrote:
| Looks fine I guess, but (like Ruby) it's not as intuitive as
| Python, and I have a lot of hopes that Mojo will bring about a
| performant Python like programming experience
| bantunes wrote:
| Ruby is Python minus white space mandates and having to try
| three times to get strings right. Also, backwards compatibility
| is not such a big deal. Of course, also minus the massive
| corporate support by the likes of Google.
|
| Try it, it's very programmer-friendly.
| pmarreck wrote:
| this must be a matter of opinion, because I always thought
| Python was a crappier Ruby
| czbond wrote:
| Same. Python always seemed like it was cobbled together
| poorly. While to me, Ruby seemed to be elegant experience.
|
| I used Ruby because I really don't like the "programming
| part" - but the "I'm creating a product ASAP, the language is
| the method of having to do so" part.
|
| I drank the Go koolaid (hoping for a C++ variant) but felt
| like I was using C or Assembly (har) in having to recreate
| practically everything ground up.
| pmarreck wrote:
| I could never stand Go. So much boilerplate. Literally
| designed to appeal to the most inexperienced developer.
| Write 4 times as much code to do the same amount of work as
| 1 line of Elixir or any functional language... Gross.
| prh8 wrote:
| Real world example for Crystal: our overnight sitemap generation
| (built using Ruby, as part of our Rails app) took 6 hours to
| generate 20 million links. At some point due to infra changes, it
| stopped running to completion. Since then, we ported it over to
| Crystal, with the main code virtually unchanged (library to help
| generate sitemaps has matching API). Just had to set up basic
| database mapping for a few tables. That version is now in
| production, and it now processes 30 million links in about 30
| minutes.
| CoolCold wrote:
| Hell, Ruby is that slow?!
| throwaway3838g wrote:
| Just curious, what makes Crystal so much faster for this use
| case?
| b33j0r wrote:
| Just a tip. I scrolled multiple screenfuls and actually know less
| now about this language.
|
| Put the recipe at the top.
|
| We want to know what it will produce. If you have a heart-warming
| story about how you learned it in the tootledge of Chef van
| Rossum, tell that story below the fold.
|
| I want a sense of the flavor before your whole life story :)
| avg_dev wrote:
| For future readers: https://crystal-lang.org/
|
| Summary:
|
| - Ruby-inspired syntax
|
| - statically-typed, with built-in type inference
|
| - types are non-nullable, with nullable types represented as a
| union of a type and nil
|
| - macros built-in including templating, AST inspection, type
| inspection, ...
|
| - green threads ("fibers") for concurrency
|
| - C-bindings built-in
|
| - package manager built-in ("shards")
|
| (also it is compiled and cross-platform with Windows
| functionality in some kind of preview/beta that the article
| author found mostly usable [I think debuggers and the
| interpreter were exceptions here], and it has a large standard
| lib)
| remram wrote:
| I wish they had used the headline to say something about the
| language rather than the useless tagline "for humans". Is it
| imperative, functional, object-oriented? For embedded, scripting,
| system programming?
|
| Is it new? A dialect of something else?
|
| Nope, all I know is it's "for humans", and possibly computers can
| run it too (?)
| pwdisswordfishc wrote:
| It's as opposed to Ook, the programming language for
| orangutans.
| [deleted]
| compumike wrote:
| We've been happily using Crystal in production at Heii On-Call
| (free website / cron job monitoring, free critical alerting to
| iOS/Android apps, on-call scheduling) [1] specifically for
| higher-throughput components of the overall system, such as the
| API server [2] and the system that continuously does website
| monitoring [3]. For context, we do use Ruby on Rails for the main
| website frontend.
|
| Really I find Crystal to be _so_ much more ergonomic and pleasant
| to use than Go or Rust, though I could see that being a matter of
| opinion. Very concise, very readable, very fast once compiled.
|
| Porting utility classes from Ruby is so easy too. I end up
| spending more time porting unit tests than porting the underlying
| code. And the testing story (Crystal's "spec" [4]) is really
| nice.
|
| If you want to try Crystal without installing anything, I made a
| "crystal-docker-quickstart" project template you can clone [5].
| You can safely try out Crystal and have your first static binary
| compiled in about 15 seconds via something like:
| git clone https://github.com/compumike/crystal-docker-
| quickstart.git my_app cd my_app ./d_dev
| make && out/my_app
|
| Lastly, I've found that the Crystal community [6] is small but
| friendly and helpful. It's at that magical stage of an open
| source community where people are extremely competent and
| responsive, but not (yet?) burned out from dealing with so many
| people.
|
| [1] https://heiioncall.com/
|
| [2] https://api.heiioncall.com/
|
| [3] https://heiioncall.com/outbound_prober
|
| [4] https://crystal-lang.org/reference/1.8/guides/testing.html
|
| [5] https://github.com/compumike/crystal-docker-quickstart
|
| [6] https://forum.crystal-lang.org/
| pantulis wrote:
| As a very anecdotal data point, I once created a pet project that
| interfaced with a CouchDB endpoint and inserted some keys with
| dates in a complex nested JSON structure and deployed it to
| Heroku. (It was ment to be called as a Apple Shortcut)
|
| It took me half a day with Ruby, two days with Crystal and a
| little more than a week with Rust. The Crystal experience was
| very very smooth coming from Ruby. With Rust it felt like I was
| wrestling with the compiler.
| segfaltnh wrote:
| And you had a ton of experience with Ruby heading into this
| comparative exercise?
|
| I feel like a lot of us are hitting a point in our career where
| we have decades of experience doing it one way, and learning
| something new is slow, but make the mistake of thinking that's
| entirely a reflection on that new thing. (Myself included.)
| pantulis wrote:
| Yes, I used to be a seasoned Ruby dev myself, not so much as
| I'd like these days.
|
| I had of course no previous experience with Crystal or Rust
| whatsoever. The trickiest point with Crystal was mapping the
| JSON dynamic payload to a typed structure to be parsed,
| modified and sent back. On top of strong typing, Rust added
| its particular syntax and lifetime complexities.
|
| It was a fun side project and, performance wise, being it
| deployed in Heroku and so on, I didn't get any clear
| advantage between Crystal and Rust because everything was
| just doing a couple of network calls to a CouchDB endpoint
| with minimal modifications to the payload.
|
| I wanted to share this as anecdotal evidence for Ruby
| developers. Coming from other languages, the developer
| experience would arguably be different.
| [deleted]
| rvba wrote:
| As someone who isnt a programmer, why are those "guides" done so
| poorly?
|
| def double(val) val + val end
|
| The example does not show what happens when you try to connect
| text and a number. Will it glue them together? Give an error?
|
| Also, "for humans", the whole x = x + 1 is illogical.
| brightball wrote:
| I'm honestly more interested in jRuby at this point. I think the
| coming combination of jRuby with fibers is going to become
| extremely compelling based on the early numbers that Charles
| Nutter was seeing. This is approaching BEAM levels of
| concurrency.
|
| https://twitter.com/headius/status/1653051050285203456?s=46&...
| singularity2001 wrote:
| They seem to suffer from similar problems as Julia: Type
| inference for large projects seems to be extremely difficult and
| results in huge compile times / startup times and or runtimes.
| eigenspace wrote:
| There's been a lot of progress made over the past few releases
| for Julia's startup and compile times. With the upcoming
| release of version 1.9, we'll be caching native machine code
| from the precompilation phase of a package.
|
| Packages will be able to specify precompilation workflows that
| are run when the package is installed and then cache the
| results from that leading to a huge improvement of the loading
| time for most heavy packages.
| jwoertink wrote:
| Lucky core dev here! I've been using Crystal in production since
| about 2017. I love the language, but there's definitely some hard
| tradeoffs which are mentioned in this thread. Our larger app has
| some serious compile time issues. We deploy with github actions,
| and it takes about 30min to build the production binary, compile
| assets, and push the binary to the server. But overall, I've
| found my apps are way more stable, and really fast as well as
| running on much smaller machines. The tradeoffs for us are
| definitely worth it.
| watzon wrote:
| Absolutely concur. Build times are an issue, support is a
| problem, and I've fallen out of love with a lot of the "magic"
| you get from Crystal and Ruby. I'll take explicit imports over
| a globally shared namespace any day.
___________________________________________________________________
(page generated 2023-05-05 23:02 UTC)