[HN Gopher] Crystal 1.9.1
___________________________________________________________________
Crystal 1.9.1
Author : mikece
Score : 83 points
Date : 2023-07-17 18:43 UTC (4 hours ago)
(HTM) web link (crystal-lang.org)
(TXT) w3m dump (crystal-lang.org)
| Alifatisk wrote:
| "The changes are fixes for minor regression bugs in the standard
| library and library."
| jimbob45 wrote:
| I wanted to like Crystal but the documentation was heavily
| lacking. Even BeefLang had better documentation and that seems to
| be the brainchild of one single man.
| sprobertson wrote:
| Agreed, docs are oddly organized and some of the most
| interesting parts like concurrency/fibers only have a single
| page dedicated to them. I liked the idea of the language enough
| to try it for Advent of Code this year, and had to rely mostly
| on the API reference (which is actually solid).
|
| Seems like an easy win for them to improve the structure of the
| guides/docs to get more users.
| Corsome wrote:
| Is it really a one man show? It looks like Beef Lang has
| excellent home page https://www.beeflang.org/ and I never heard
| about it until now.
| neonsunset wrote:
| Did the author accidentally stole C# source code from 2028
| and rewrote it to C++ with LLVM back-end? (removing certain
| features like async/await :D)
| jimbob45 wrote:
| It's C# with some really nice additions for game development
| and a bespoke IDE. Allegedly, the guy who used to be the CTO
| for PopCap Games is the man leading the way.
| [deleted]
| [deleted]
| Alifatisk wrote:
| Keep growing Crystal, I am proud of you!
| unshavedyak wrote:
| This is neat. Who is making the most interesting (and
| realistically viable, ie not just a research lang) language in
| this space? Eg, for _me (! no language wars intended.. oof)_
| there is:
|
| 1. Rust for if i want something C++-esque. Rich stdlib & crates,
| i love it. My primary language for everything.
|
| 2. Zig for if i need C. Interesting language, but i can't speak
| from personal experience. Seems to be gaining a lot of traction,
| makes nice choices, feature rich in the right places, etc.
|
| 3. ??? for when i want Python.
|
| I'm asking about #3. Who (if anyone?) is making an attempt at
| "new and better Python"?
|
| .. and yes i know, all these languages i mentioned, including
| Python, are not dead, are loved by millions, and are all very
| productive. My statements are not implying that they are anything
| but amazing. Please don't yell at me :)
| xwowsersx wrote:
| Nim for #3, I think. I've found Nim to be an incredibly
| productive language. I was able to write very performant and
| readable code after just a couple of hours of reading the docs
| and looking at some tutorials. If the community and ecosystem
| grows larger, I could see building something large and non-
| trivial with Nim.
| etra0 wrote:
| I really wanted to like Nim, but its async story is not that
| great (no multithreaded runtime AFAIK, no channels) and
| albeit justifiable, I don't like the way it treats imports. I
| think Crystal and Go are better in the async space.
|
| I thought I'd have more troubles with the case insensitivity
| thing, but it turns out, it wasn't a big issue at all, and
| UFCS is great.
| [deleted]
| elcritch wrote:
| Agreed! There's a couple of fairly large projects in Nim:
| https://nimbus.team/ (https://github.com/status-im/nimbus-
| eth2) or https://github.com/zedeus/nitter
|
| Though there's still friction points I've been happy seeing
| the ecosystem grow lately. The compiler has seen a lot of bug
| fixes lately too which helps.
| thewataccount wrote:
| Honestly I think the best explanation for python is for when
| you want something "quick and dirty".
|
| Between the less verbose syntax, and the library support - it's
| incredibly difficult to beat if you measure time to POC. For
| many, many applications like cli scripts, webservers,
| datamanipulation, etc. C/CPP/Rust/Go are inarguably slower to
| get to POC, and have a higher learning curve. The network
| effect is incredibly strong as well with the library support.
|
| That said it'll be dirty. Might not be super fast, and it might
| not have all of the compile-time checking.
|
| I think the big thing is that this "quick and dirty" solution
| is "good enough" for a lot of people. And if it isn't, that's
| when you start moving things to rust/go/etc.
| throwmeout123 wrote:
| Scala 3 could be a great "new python" but it has too many
| community and governance issues, and also the haskalator people
| which has been nothing but a scourge for the lang. Let's hope
| they dont also destroy rust.
| synergy20 wrote:
| 3 doesn't exist,if I have to pick one maybe nim
|
| 4. crystal for ruby
| packetlost wrote:
| Honestly, I just want a hard fork of CPython with a few
| different design decisions and cleaning up of stdlib to support
| them:
|
| * Attributes are no longer dynamic, __slots__-like behavior for
| everything by default
|
| * GIL no more
|
| * Base off of Pypy for JIT speed
|
| * Real lambdas (I like how Lobster does this)
|
| * Maybe make type annotations required (but with inference)
|
| Python's syntax is _so_ close to nearly perfect (if you don 't
| mind tab-delimited code, I've gotten used to it)
|
| I think it would go over better than people fear. If you do
| what you can to make the core language fast _enough_ , C
| extension stop being as relevant. Right now, the Python
| ecosystem is absolutely held back by the FFI hell that it's
| stuck in.
| rich_sasha wrote:
| Right - and you'll wipe out somewhere around 60-90% of the
| users. The vast ecosystem will largely not be compatible and
| unless you're very lucky, most will not be compatible with
| your fork. Language withers.
|
| As I said in the other comment, the compromise on everything
| is what makes it tick... I don't like all of it either, but I
| like a language that has top class support for ML, database
| connectivity, web programming, file wrangling, task
| orchestration and web scraping all in one. And even some poor
| but workable parallelization.
| packetlost wrote:
| Retaining the community isn't _necessarily_ a goal, the
| syntax is the thing I 'd want to keep. Bringing over as
| much of the community as reasonable without compromising on
| other things, I think, is still a fairly worthy goal.
| lolinder wrote:
| Python-the-language is fine, but any time I see people explain
| why they chose Python for a project it usually boils down to
| Python having an _extremely_ large ecosystem of libraries to
| choose from. This means that any new-and-better Python would
| need to be take the Scala /Kotlin route by running on the same
| VM in order to take advantage of the existing ecosystem, but my
| understanding is that (unlike the JVM) the Python VM has no
| published API and therefore doesn't present a stable
| compilation target for any language other than Python.
|
| This leaves Python in a space similar to JavaScript, where
| there isn't a really solid way to build a successor.
| cassiogo wrote:
| https://nim-lang.org/ for #3 probably
| modernerd wrote:
| Mojo is one to keep an eye on for #3.
|
| https://docs.modular.com/mojo/
| [deleted]
| rookderby wrote:
| For #3, I think Python is working on making a better python. I
| have some 'lingua franca' projects at work. Python projects are
| easy to hand off and the the iterations are getting faster.
| Most of these projects are currently in python 3.9, but i'm
| looking forward to the speed increases that 3.11 will bring.
| mbb70 wrote:
| Agreed, much like Java turned out to be the next evolution of
| Java. Python is the the 'good enough at everything + huge
| ecosystem' language that you can't replace no matter how much
| cooler the concurrency paradigm.
| NoboruWataya wrote:
| Definitely agree that Java has come a long way recently and
| not at all looking to start a language war, but I think
| that at the very least Java should share its "next
| evolution of Java" podium with Kotlin.
| adgjlsfhk1 wrote:
| IMO Java is still at least 5 years behind C#. It's hard for
| me to take Java seriously without project Valhalla.
| pjmlp wrote:
| Just like .NET Native AOT is quite some years behind
| GraalVM, OpenJ9, having high profile real time bare metal
| runtimes like PTC and Aicas have been selling for 20
| years with deployment in battlefield scenarios, being
| used in the biggest mobile OS platform.
|
| As someone working on a polyglot delivery agency, many
| UNIX shops still don't take .NET seriously, given how
| many key libraries are still stuck in VS/Windows
| workflows or not yet ported from .NET Framework.
|
| It is more than just Java vs C#, the several JVM
| implementations and CLR also matter.
|
| Note that even Microsoft takes Java seriously enough to
| have their own Java distribution, after the Sun/Microsoft
| drama, and any major Azure product deployment also
| requires day 1 support for Java.
| neonsunset wrote:
| This is unlikely, since Native AOT is not exactly a
| separate flavour, it builds right on the same compiler
| optimizations, sans those that are possible with JIT
| only. In addition, years of development is a bad, bad
| proxy for the results. .NET had been changing very slowly
| up until it went the .NET Framework -> .NET Core -> .NET
| OSS route. Since then, the last 4 years have brought more
| (performance and feature) changes than the previous 10+.
|
| With .NET 8, I highly doubt JVM implementations would
| have superiority (with Dynamic PGO being enabled by
| default closing one of the avenues where HotSpot used to
| have an advantage), except maybe in certain niche
| scenarios.
|
| Also, Java can no longer be compared to C# directly
| (because they are not equal in features, or even levels
| of abstractions you can go as of now). A fair comparison
| would be Kotlin for higher level and Go for lower level
| scenarios.
| pjmlp wrote:
| Except plenty of people, including Microsoft own
| products, are still stuck in .NET Framework.
|
| Additionally plenty of business are only adopting LTS
| versions.
|
| Then we have big names like Sitecore, that decided it was
| time to move on, and all their major acquisition are
| based on Java and JS/TS products.
|
| The GUI civil war isn't helping the community.
|
| The .NET team was grilled on twitter due to the way the
| last Technetpower benchmark was conducted.
|
| While F# keeps being neglected, VB is stable, and CLR
| changes to mean C# Language Runtime, JVM now enjoys
| Scala, Kotlin and Clojure.
|
| NativeAOT is still not going to be fully done for .NET 8,
| and apparently it will require minimal APIs to be usable,
| hello rewrites, yet again.
|
| Still no roadmap for GUI support on Native AOT, and then
| there is the recent joke that VSCode MAUI plugin doesn't
| do Linux anyway, only Android, when on Linux.
|
| It is a bit more complex than playing football teams with
| languages on the school playground.
| neonsunset wrote:
| Let's address these claims one by one:
|
| > Except plenty of people, including Microsoft own
| products, are still stuck in .NET Framework.
|
| Would this necessitate evaluation of Java 8's (and
| corresponding JVM) viability against modern languages and
| platforms too?
|
| > Additionally plenty of business are only adopting LTS
| versions.
|
| .NET 6 is an LTS version and so is 8.
|
| > Then we have big names like Sitecore, that decided it
| was time to move on, and all their major acquisition are
| based on Java and JS/TS products.
|
| When a particular (medium size) company picks a
| technology, it has no impact on its viability because it
| does not retroactively alter its advantages or
| disadvantages unless the company invests in the ecosystem
| (which Sitecore does not, but then again, this is a
| nonsensical argument)
|
| > The GUI civil war isn't helping the community.
|
| It is true that situation with GUI frameworks in C# is
| far from ideal, it is being worked on, but there is no
| catching up to JS/TS front-ends written even for desktop
| applications. For all it's worth, Xamarin continues to be
| loved by enterprise, and, maybe, one day MAUI will be
| made successful despite extremely rough start (I'm not
| holding my breath though).
|
| > The .NET team was grilled on twitter due to the way the
| last Technetpower benchmark was conducted.
|
| Almost all top participants in Techempower pretty much do
| some degree of benchmark gaming. However, this does not,
| by itself, indicate the deficiency of the language or the
| runtime (if it did, we'd have all popular languages
| classified as deficient). In fact, asm emitted for C#
| trades blows with the likes emitted for C++. In many-core
| gRPC scenarios, Kotlin is at a similar level of
| performance, but as a language itself does not allow
| going as low-level as C# does (it effectively competes
| with both Go and Kotlin, offering a different set of
| tradeoffs).
|
| > While F# keeps being neglected, VB is stable, and CLR
| changes to mean C# Language Runtime, JVM now enjoys
| Scala, Kotlin and Clojure.
|
| Can you expand on this? F# ecosystem does see less
| developer activity than C# _from the language
| standpoint_. However, it receives all the same
| performance and shared library improvements, and .NET
| does not introduce changes which break F#. Similar to
| Sitecore statement, VM being targeted by a multitude of
| languages does not make it automatically better (or
| worse) nor is a proxy for its performance
| characteristics. It is necessary to assess a technology
| at its face value.
|
| > NativeAOT is still not going to be fully done for .NET
| 8, and apparently it will require minimal APIs to be
| usable, hello rewrites, yet again.
|
| NativeAOT was "done" for .NET 7 for win-x64, linux-x64
| and linux-arm64 targets, with osx-arm64 (it was not a
| goal for .NET 7) pull-request narrowly missing the
| feature snap window, therefore getting postponed to .NET
| 8. It also appears the argument might stem from
| conclusions learned from GraalVM AOT which do not apply
| to .NET. Unless used in a serverless function, back-end
| .NET deployments are best served by simply staying with
| JIT, which would offer higher sustained throughput.
| Native AOT is first and foremost designed for completely
| different scenarios.
|
| > Still no roadmap for GUI support on Native AOT, and
| then there is the recent joke that VSCode MAUI plugin
| doesn't do Linux anyway, only Android, when on Linux.
|
| All code targeting .NET historically relied on features
| by definition incompatible with true AOT (like in C++).
| It is a non-trivial effort to address issues of specific
| frameworks, which is being done, and the language itself
| adopts newer features (source generation. unsafe
| accessors, linker/trimmer improvements) to make it
| easier.
|
| As for Linux, please give Avalonia a try.
| oblio wrote:
| 99.99% of companies only use OpenJDK derived JDKs,
| though.
| pjmlp wrote:
| Sure if we forget ART isn't really derived from OpenJDK,
| and there are plenty of Java implementations beyond
| 0.01%, in business for the last 30 years.
| k__ wrote:
| I had the impression, the Python people have basically given
| up and ported everything remotely performance demanding to
| C/C++.
| biorach wrote:
| Given up? That was the plan all along.
| fuzztester wrote:
| Python was never supposed or planned to be a high
| performance language, at least not comparable to C or C++,
| AFAIK.
| rich_sasha wrote:
| There are many vying for Python's space but no clear winner. I
| think because actually Python is good at many very different
| areas, and improving one usually makes something else worse.
|
| Attempting to list some "better Pythons" by area, and the
| catches:
|
| - golang for web: seems good and simple but also less dynamic
|
| - Julia for scientific programming: Julia users are convinced
| it's better but converts are not queuing up. Also the story
| outside scientific programming is less convincing. Almost all
| ML/AI research is written in Python
|
| - glue language / generic file wrangling... Not sure if there
| is a clear contestant!
|
| - (shamelessly stolen from sibling comments) nim as a like for
| like faster/better replacement: faster and seemingly quite
| (still less) dynamic, but smaller ecosystem and unclear
| governance - currently one man and his GitHub login.
|
| Incidentally, I think this "second best at everything" meme-
| fact is part of its success. There is a huge pool of people
| using Python for one purpose, who, confronted with a new need,
| can also use Python, even if it's not the best tool for the
| job. It integrates easily with whatever else is written in
| Python, and it's one less language to learn. This is IMHO where
| complaints like "why people use Python for X when it sucks"
| miss the point.
| masukomi wrote:
| I'd say Raku for Glue language.
|
| In much the same way Perl was used for gluing different
| things together Raku does all of that, but better, in
| parallel, while providing you some hor d'oeuvres to nibble on
| while you write it.
| replwoacause wrote:
| PowerShell is my glue language of choice. Works cross
| platform and I get all the power of objects and the .NET
| Framework.
| speed_spread wrote:
| I like Powershell but IMO it still has too many
| fundamental Microsoftisms for it to be practical on Unix
| systems.
|
| I would opt for Nushell instead: https://www.nushell.sh/
| pjmlp wrote:
| > Julia users are convinced it's better but converts are not
| queuing up.
|
| There are enough of them, even if HN isn't paying attention,
|
| https://juliahub.com/case-studies/
| di4na wrote:
| For Glue, Janet is probably the biggest one right now. I am
| working on something, but it will take a long time.
| scythe wrote:
| As a somewhat reluctant user of Python for scientific
| computing, the main thing that keeps me from trying Julia is
| that it seems to have a severe case of featuritis. I never
| wanted or needed my convenience language to try to be a C++
| replacement, and the hodgepodge of syntax I see when I look
| at Julia samples is nauseating.
|
| Replacing Python is not practical right now because it is
| more comfortable to use a language that doesn't try to be
| everything to everyone, and that means that it will be built
| on a base language -- in Python's case, C. That ground is
| shifting, and nobody is sure if the new base will be Rust,
| Zig, something else, or if it will all blow over and C will
| come back. So the space isn't being targeted very much.
| BasedInfra wrote:
| Mojo for when you want python.
|
| https://www.modular.com/mojo
| m-hilgendorf wrote:
| For 3 I think it's Typescript and Dart. There's also stanza (1)
| which is a lot like Python but it's not being used outside of
| one startup (disclaimer: I used to work there). Ultimately I
| think optional typing on top of a garbage collected language is
| the answer.
|
| (1) https://lbstanza.org/
| 38 wrote:
| I would say Go is a good option for #3. its quite different,
| AKA braces instead of spaces, but its basically Python in
| regard to ease of use and big standard library. also it has the
| benefit is strong typing, but types can also be assumed in many
| places: hello := 9 world := "world"
| throwmeout123 wrote:
| No. Way too few abstractions in go.
| revskill wrote:
| My blame of Crystal is still lacking of discriminated union (like
| in Rust) and the hard to use macros system (while powerful)
|
| Other than that, it's powerful.
| rddbs wrote:
| There are union types, which despite being untagged might be
| enough in a lot of situations, and I believe has language
| support in things like switch statements.
|
| https://crystal-lang.org/reference/latest/syntax_and_semanti...
| yxhuvud wrote:
| Crystal union types are tagged as the actual type a variable
| contains is tracked.
|
| I honestly have no idea how anything could work if they were
| not tagged. Like how on earth would you know what method to
| invoke?
| andyferris wrote:
| You should look into the union keyword in C :)
|
| (Basically the programmer has to figure out how
| discrimination works - you're kinda on your own).
| Malp wrote:
| Happy to see this here; I found it to be a fun language to
| prototype reasonably performant things in + for learning about
| certain data structures. I expect to see the comments talking
| about the lack of docs, language server struggles, and
| compilation times (the whole stdlib and program is compiled from
| scratch every time a program is compiled/run, IIRC). The language
| is slowly growing and I encourage people to stick with its
| onboarding shortcomings and giving it a shot for their next
| project.
___________________________________________________________________
(page generated 2023-07-17 23:01 UTC)