ponyc VS falcon

For example, the actor's model is not used by a lot of languages, Pony (https://www.ponylang.io/) and Elixir are the only ones that I know, but they address the concurrency problem quite well, while it's a pain to deal with in other languages at large scale.

And that last point is critical. If the language flatly can't represent some concepts it uses, they have to be implemented somewhere else. I had a similar discussion with a proponent for Pony once- the language itself is 100% safe, and fully dependent on C for its runtime and data structures. One of Rust's core strengths is being able to express unsafe concepts, meaning the unsafe code can expose a safe interface that accurately describes its requirements rather than an opaque C ABI. Vale doesn't seem to do that.

"Exterior iteration. Iteration used to be by stack / non-escaping coroutines, which we also called "interior" iteration, as opposed to "exterior" iteration by pointer-like things that live in variables you advance. Such coroutines are now finally supported by LLVM (they weren't at the time) and are actually a fairly old and reliable mechanism for a linking-friendly, not-having-to-inline-tons-of-library-code abstraction for iteration. They're in, like, BLISS and Modula-2 and such. Really normal thing to have, early Rust had them, and they got ripped out for a bunch of reasons that, again, mostly just form "an argument I lost" rather than anything I disagree with today. I wish Rust still had them. Maybe someday it will!"

I remember that one. The change was shortly after I started fooling with Rust and was major. Major as in it broke all the code that I'd written to that point.

"Async/await. I wanted a standard green-thread runtime with growable stacks -- essentially just "coroutines that escape, when you need them too"."

I remember that one, too; it was one of the things that drew me to the language---I was imagining something more like Pony (https://www.ponylang.io/).

"The Rust I Wanted probably had no future, or at least not one anywhere near as good as The Rust We Got."

Almost certainly true. But The Rust We Got is A Better C++, which was never appealing to me because I never liked C++ anyway.

Pony or bust.

If you have a value in mutable storage, and want to treat it as an immutable parameter without copying it first, you will need to provide some way to guarantee that it won't be mutated while being treated as immutable! There doesn't seem to be a definitive best way to do that (although the likes of Pony make a try at it).

The love child of Erlang and Rust exists already: Pony.

https://www.ponylang.io

It really is the best of both languages... unfortunately, the main supporter of Pony seems to have stopped using it in favour of Rust though :D.

But if that's really what you want, Pony is your language. It definitely deserves more love.

You can actually try to have a magic language which "does not ignore decades of PL research" but you are likely to get either something broken or a project that is likely not going to release in our lifetime.

Never a bad time to plug Pony lang[1] - a safety-oriented actor-model language. In addition to the numerous safety guarantees, you also get a beautiful syntax and automatic memory management. Really a great language that often gets overshadowed by Rust's hype-turfing.

[1]: https://www.ponylang.io/

Could you command on any projects within Shopify that are helping Ruby's concurrency story? I'm aware of Ractors (https://docs.ruby-lang.org/en/master/ractor_md.html) and Fibers, but it's unclear to how feasible these primitives currently are to build the necessary abstractions on top of them that would make Rails more concurrent.

https://github.com/socketry/falcon is an interesting project, but again, it's not clear how difficult it would be deploying a Rails app on top of this.

There's a lot of really great projects happening and plenty to be hopeful about, but when that stuff will land or the changes the rest of the community and ecosystem should think about making still isn't clear.

HOWEVER HAD, not all of these problems (in Java) are due to some corporation going bulldozer-mode. Several problems seem to come primarily from bad technical decisions. The import-situation annoys me in Java. I think it is really bad that I can not easily require add-ons or files, without being forced into a specific, nonsensical directory structure. In ruby I just do require, or load (I could do require_relative but this is a pretty pointless addition; It even leads to bugs such as the author of https://github.com/socketry/falcon assuming that everyone uses a hardcoded filesystem, so code such as https://github.com/socketry/falcon/blob/main/bin/falcon at: require_relative '../lib/falcon/command' not working unless the assumption that the directory BELOW the bin/ one must contain a lib/ which is not always the case. I am not sure he understood the problem domain though. If he would have simply used require instead, that would not be an issue, but no, he thinks one has to use hardcoded path assumptions into require_relative, which means it'll break when you relocatethe bin/ executable file there. It's trivial to fix of course, just replace the require_relative with require, but I think he did not understand the explanation so ...)

This doesn't have much to do with Rails, more with the web server that serves the Rails app. Take a look at Falcon.

You can use the Async gem and the Falcon web server to take advantage of this capability. And starting in Ruby 3.0, async I/O is even more automatic because inside the Ruby runtime, all socket operations will automatically yield the current fiber by default. It’s fully transparent to the developer. Your I/O calls appear to be blocking so they are easy to understand, consistent with Ruby’s “programmer happiness” philosophy.

There seem to a lot of ruby pieces falling into place for Rails 7.

The Achilles Heel of Hotwire apps has previously been the low number of supported websocket connections and high memory usage when using ActionCable and Puma but I have high hopes that Falcon[1] will take care of that.

That along with Github's View Components[2] and Tailwind make me really please with the way Rails is heading right now.

1. https://github.com/socketry/falcon

2. https://github.com/github/view_component

This is all new to me as well, but the project mentioned the Falcon web server(https://github.com/socketry/falcon).

The documentation for Falcon mentions using it with rails: https://socketry.github.io/falcon/guides/rails-integration/i...

I imagine something more "native" to rails will happen eventually though. But would need to be after this makes its way into core ruby(which has not happened yet apparently).

Welcome back.

It's still the best choice in the Ruby world, well maintained, responsive and new features added. Shopify and github use it, you might want to look at the Rails 6 annoucements what these companies added for scalability features. There've been changes to the asset pipeline since version 3 but you'll still recognize it. You can run Rails as API-only and there's subprojects/tutorials for combining a frontend-heavy React,Vue with a Rails backend. You can still ignore the webpack based asset setup unless you use React,Vue I think. Ruby-3 works fine though I'm still waiting for some less-maintained gems to finally merge PRs, maybe you want to use Ruby-2.7 first.

I use https://puma.io/ , that scales well enough for me. https://github.com/socketry/falcon#readme is faster with build-in HTTP/2 support but harder to setup in my opinion, e.g. requires SSL certificate even on localhost.