Crystal 1.9.1(crystal-lang.org)
crystal-lang.org
Crystal 1.9.1
https://crystal-lang.org/2023/07/17/1.9.1-released/
11 comments
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.
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 :)
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 :)
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.
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.
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.
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.
It's interesting you say that because looking at large calculations in Python using numpy can be pretty nauseating.
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.
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.
I know Python since 1.6, and use it as main scripting language when on UNIX platforms, as if Python 3.11 versus 1.6 isn't full of featuritis as well.
> I never wanted or needed my convenience language to try to be a C++ replacement
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.
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.
For Glue, Janet is probably the biggest one right now. I am working on something, but it will take a long time.
I remember looking at Janet and quite liking it, clean neat and small.
...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?
...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?
It has package management that works.
Elixir, elixir, and elixir?
This, I still think myself as a Clojurist mainly but Elixir's Nx/Bumblebee, Elixirscript ability to use Mix.install per script file, and calling into NIF/FFI codes (as seen in Nx itself) is really strong story IMO.
Now, if only Crystal can make for a strong NIF language for BEAM...
Now, if only Crystal can make for a strong NIF language for BEAM...
> 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/
There are enough of them, even if HN isn't paying attention,
https://juliahub.com/case-studies/
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.
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.
PowerShell is my glue language of choice. Works cross platform and I get all the power of objects and the .NET Framework.
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/
I would opt for Nushell instead: https://www.nushell.sh/
Nushell is a great project and I’ve taken it for a spin, but it isn’t developed enough yet to even come close to rivaling PowerShell. The PowerShell ecosystem is robust, and I can import a module for just about anything I need to do. I’ll be keeping an eye on Nushell though…
Nu just isn’t as exciting imo. You lose the C# standard library and all of the amazing tooling that Microsoft has built for it.
https://nim-lang.org/ for #3 probably
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.
* 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.
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.
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.
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.
Of course goals can vary, for many, myself included, the fact that for most things you can _imagine_ there is a quality package on PyPI is a major draw of the language.
I probably wouldn't use a fork that is 2x as fast and has 10% of the package coverage.
I probably wouldn't use a fork that is 2x as fast and has 10% of the package coverage.
Why keep the syntax? It's one of the least impressive part of Python
I disagree! I think it's one of the better parts of the language
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.
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.
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.
Ah, good to know. I hadn't checked out the async story in Nim at all.
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.
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.
Oh nice, didn't know nitter was built with Nim, that's awesome
[deleted]
Mojo is one to keep an eye on for #3.
https://docs.modular.com/mojo/
https://docs.modular.com/mojo/
3 doesn't exist,if I have to pick one maybe nim
4. crystal for ruby
4. crystal for ruby
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/
(1) https://lbstanza.org/
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.
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.
> Honestly I think the best explanation for python is for when you want something "quick and dirty".
That would be Perl actually.
That would be Perl actually.
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.
This leaves Python in a space similar to JavaScript, where there isn't a really solid way to build a successor.
Mojo for when you want python.
https://www.modular.com/mojo
https://www.modular.com/mojo
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.
Python moves too fast and breaks things too often, though. It's why I went back to Perl.
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.
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.
IMO Java is still at least 5 years behind C#. It's hard for me to take Java seriously without project Valhalla.
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.
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.
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.
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.
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.
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.
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.
> 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.
Since we are still playing this game.
> 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.
> 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.
Well, this is quite unfortunate but turns out our conversation was a pure waste of time. GUI and GUI-adjacent applications isn't even an area where C#/.NET is the strongest, unlike back-end applications.
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?
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?
I had the impression, the Python people have basically given up and ported everything remotely performance demanding to C/C++.
Given up? That was the plan all along.
Python was never supposed or planned to be a high performance language, at least not comparable to C or C++, AFAIK.
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"No. Way too few abstractions in go.
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.
[deleted]
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.
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.
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.
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)
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.
Seems like an easy win for them to improve the structure of the guides/docs to get more users.
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.
Other than that, it's powerful.
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...
https://crystal-lang.org/reference/latest/syntax_and_semanti...
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?
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?
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).
(Basically the programmer has to figure out how discrimination works - you’re kinda on your own).
But eh, that is not the case in crystal. You are not on your own - the language knows what a variable is during runtime and you have plenty of ways to dispatch between the types.
I'm liking crystal more and more. I'm only dabbling with it, writing small improvements, but it gives me back that sens of joy and happiness when I started programming with ruby.Not a mystery, really.
Thanks team !
Thanks team !
Keep growing Crystal, I am proud of you!
I really like Crystal but until the devtools improve, it's a bit of a pain to write Crystal without a fully function LSP. Crystalline does an amazing job, but there are still some shortcomings that need to be taken care of by the main language devs to help the LSP come along better.
Other than that Crystal is fantastic and I hope to use it more in the future
Other than that Crystal is fantastic and I hope to use it more in the future
"The changes are fixes for minor regression bugs in the standard library and library."
1.9.1 was a version of Ruby that I used for awhile. Does this have some connection to that version, or is it an homage, or is it just a coincidence?
[deleted]
[deleted]