Crystal 1.9.1
crystal-lang.org
crystal-lang.org
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 :)
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.
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.
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.
> 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.
> Would this necessitate evaluation of Java 8's (and corresponding JVM) viability against modern languages and platforms too?
Contrary to .NET Framework versus .NET Core evolution, there are hardly any libraries for Java 8 that don't work in more recent versions (module based JVMs), or are available only in one specific OS.
Many business are stuck in Java 8 for reasons, or stuff like using Red-Hat Enterprise and not allowing any Java version other than the one shipped with the OS.
And there is the whole issue of keeping compatibility with Android, only supporting Java 11 (as of Android 12 - 13) and Java 17 (as of Android 12 - 14).
> .NET 6 is an LTS version and so is 8.
It is, that still doesn't make everyone run for them, specially when there are changes on how EF works or ASP.NET MVC setup code needs to be written.
Plus they still cannot handle Windows Forms and WPF properly, as the out of process designer is buggy and requires the likes to Telerik and Component One to rewrite their components for the new designer.
> 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).
Xamarin has lost most of the enterprise love with the MAUI rewrite, if anything people are paying more attention to Flutter, when before we used to joke about Dart.
Besides pure Microsoft partner agencies, most polyglot consulting agencies never cared about Xamarin in first place.
Additionally most of the enteprise consulting gigs are now around Web and mobile Web.
> 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).
There is always FFI, C# also doesn't allow for many workloads where WinDev is keen to only let C++ play, like Windows shell, many of WinUI foundation pieces, or the new DevDashboard UI, no matter what the .NET team will do.
> 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.
No tooling for GUI frameworks, no support for Blazor, not able to be part of Roslyn analysers, not able to take advantage of source generators (this breaks F# actually, as it cannot consume/produce such libs).
Sitecore isn't a language, it used to be the number 1 CMS product for the .NET ecosystem on big corporations, now they are leaving .NET behind, as they focus their portfolio in other developer stacks.
> 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.
No it wasn't, as it only supported CLI and dynamic libraries, a very tiny set of use cases.
Likewise, the .NET 8 Native AOT still won't be able to handle all .NET Native scenarios, and Blazor AOT still relies on Mono AOT capabilities, with their own set of caveats.
Making excuses for what is supported or not, when there are competing technologies that can handle it better.
Well in polyglot agencies, it means the other competing technology gets chosen for project delivery, they aren't married to be handled as being "XYZ Developer".
> 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.
Historically there have been endless versions of AOT compilation in .NET, including two C++ versions (Managed C++ and C++/CLI) able to mix native code with MSIL.
NGEN, Singularity Bartok (later adopted for Windows 8.x store), Midori Project N (later adopted for .NET Native), Mono AOT, CosmOS, Microsoft Research Phoenix.
> As for Linux, please give Avalonia a try.
If we ever get an RPF that actually cares about it.
I'm also not sure why do you want to use Native AOT with ASP.NET Core and EF Core, which are getting improved support lately, but there are specific scenarios where you may want that and long-running back-end services isn't one of them.
But the general message isn't new, I see it from time to time with developers whose experience has been predominantly shaped by working only within Windows ecosystem, and although your case appears to be different, the sentiment is the same. Maybe try enjoying the programming a little bit more by changing up the tools and environment?
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.
There are enough of them, even if HN isn't paying attention,
...but then, I'm heavily invested into Python and it wasn't clear to me where Janet is materially better, for system scripting-type of issues. What am I missing?
I'm not saying Python is some pinnacle of language design. I'm learning Rust, because it's very obvious how it fills gaps that Python cannot cover. What's that gap for Janet?
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.
I would opt for Nushell instead: https://www.nushell.sh/
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.
The only big thing to learn with Julia is the broadcasting syntax, other than that, Julia has a good macro system, so sometimes you see syntax that doesn't make sense without knowing what the macro does.
Strange as that is one of the reasons why Julia exists - fast Python.
> and the hodgepodge of syntax I see when I look at Julia samples is nauseating.
I honestly like the syntax. OTOH I dislike Pythons syntax somewhat.
Now, if only Crystal can make for a strong NIF language for BEAM...
* 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.
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.
I probably wouldn't use a fork that is 2x as fast and has 10% of the package coverage.
hello := 9
world := "world"4. crystal for ruby
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.
That would be Perl actually.
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.
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.
This leaves Python in a space similar to JavaScript, where there isn't a really solid way to build a successor.
Seems like an easy win for them to improve the structure of the guides/docs to get more users.
Other than that, it's powerful.
https://crystal-lang.org/reference/latest/syntax_and_semanti...
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?
(Basically the programmer has to figure out how discrimination works - you’re kinda on your own).
Thanks team !
Other than that Crystal is fantastic and I hope to use it more in the future