Hacker News Reader

One issue is that with GC, you lose prompt finalization of resources. A lot of code is written with this assumption in mind (e.g., file buffers are flushed if the last reference to the file is dropped—which is arguable incorrect due to the lack of error checking). And the borrow checker is the only thing that keeps everything from being mutable in place in Rust today. Having GC would open the possibility for alternatives to the borrow checker without compromising memory safety, but even Pony-style reference capabilities probably won't lead to a language where abstractions compose much more easily than in Rust today.

Maybe a language with a similar syntax, traits, monomorphization, and macros would still be interesting to many people? Would people prefer traits and macros over ad-hoc polymorphism (in the style of C++, which could subsume the macro use cases, too)?

An issue only in some GC languages that don't provide the constructors for deterministic resource handling.

Unfortunately people keep placing all GC languages on the same basket.

And before anyone mentions that it is easy to forget, well those languages have their own "Clippy" to take care of it.

I don't think constructors are the challenging part. It's about lexically scoped destruction. Certainly there are languages that have that and permit garbage collection, however those constructed values are necessarily second-class citizens and behave somewhat differently than ordinary values. There's probably some reasonable middle-ground, like constructors returning an owned reference that explicitly can be turned into an unowned reference, thus opting out of deterministic destruction.

And those languages do offer lexical scoped destruction.

They are only second class in the context people put all GC languages on the same basket, and rather go for the X rewritten in Y blog posts.

Because apparently adding newer languages to CV is cooler than mastering the one they have.

> but I still think that there's a space for a higher-level language with most of what people like from Rust that has a (tracing) garbage collector and is slightly more relaxed with trying to design a way around every marginal heap allocation

I dream about a Rust subset that's exactly that. What would be even better is if you could just use Rust packages directly with it. Since these libraries already do compile, correctness has been verified.

A web framework doesn't need GC, it just needs some ability to express the idea that per-request code should get its own allocator, with knowledge of said allocator propagating down through function calls.

Jai solves this by having a "context", which includes an "allocator" member by default, whose default value is a standard heap allocator. You can override this allocator member to point to your own allocator, so it's easy and straightforward to have the main server procedure allocate a pool of memory, create a new context with a new allocator that uses this pool of memory, then "push" this context for the duration of the request resolution, then free (or mark for reuse) the memory pool afterward.

There definitely is some void!

I gladly take the whole rust "package" because overall it's just so good, at least for opensource / hobby stuff. I wish there was an equivalent but with GC, to use for work.

> How did a language that's supposed to be so hard get popular to the point where people view its fans as pushing it aggressively?

I think Rust is especially popular with a demographic that was not previously exposed to lower level programming. Meaning younger programmers (because modern languages are higher level) and web centric programmers (because we're in a boom of web development).

This demographic had a hard time entering systems programming, because while fascinating, its exposure is lower (less jobs, less projects), and entry cost (learning C, or C++<11) is harder.

Rust made systems programming more accessible, and systems programming, just as anything related to how things work under the hood, is fascinating.

Now Rust is hard, as you noted, but not hard in the same sense than C is hard.

C is hard because low level stuff bites you immediately. You can't quite easily just use a random library in C if you don't understand your build system, linkage, etc. If you mess up in C, the compiler will not tell you either, you will have to debug your way out of it.

Rust is different, in the sense that its difficulty is limited to the compiler saying "nope". If you can get the compiler to say "yep", then you're 99.9% of the time safe. Now getting that compiler to say "yep" may take time, indeed, but all in all you most often can just get away with sprinkling unwraps, clones and Arcs all over the place until it works.

In that sense, I think Rusts popularity essentially lies in the fact that it is a way to do low level stuff with a barrier of entry limited to being stubborn in learning it.

Having learnt C in high school, and doing Z80 Assembly prior as a 12 year old kid, only with a bunch of books from the local library, it is kind of interesting to read about fear and hard regarding C.

Yes it does corrupt memory, there are some crashes, I usually bash C, nonetheless it seems we have too much "safety playground" regarding learning processes nowadays.

> How did a language that's supposed to be so hard get popular to the point where people view its fans as pushing it aggressively?

Popular languages don't really have evangelism or fans pushing it aggressively. Those are traits of smaller languages that don't interop well with other ecosystems so they need a lot of evangelism to build out the library ecosystem.

> there's a space for a higher-level language with most of what people like from Rust that has a (tracing) garbage collector

What non-memory management related things is it people like from Rust that is missing from, say, Java or Kotlin? Because those have great web frameworks that address all the features requested in the article and a whole lot more, there's good first class support for all major platforms, lots of documentation etc. These languages are also famously developer friendly with good error messages.

Rust makes an '.exe', Java makes a '.jar'.

I think people want to write programs that run on an OS rather than an interpreter.

For the majority of executing code, there is no fundamental difference when it comes to a JIT compiler.

Besides, GraalVM can produce a native executable for pretty much any JVM language/program.

The problem is friction. To run a rust app you can just run it. To run a java app you need to install java first. This is no problem for backends running on servers, but client apps (like Minecraft) have to include their own JVMs to reach a wider audience, and this solution still introduces a bunch of complexity.

Not a thing since Java 9 and jlink introduction, or since those commercial AOT compilers exist, for 20 years now.

And if free beer is your thing, GraalVM native image or OpenJ9 also produce a regular executable.

Last I checked there was a significant disadvantage to using rather basic Java JIT code in a cloud environment: slow startup time and poor initial performance in terms of requests per second & latency meant scaling on demand didn't work very well. I suggested we move to GraalVM and AOT compilation on that project but we just ended up over-provisioning by a significant factor to smooth things out.

Java compilers have been producing '.exe' for about 20 years now, it is a matter to actually care to learn about their existence.

> it is a matter to actually care to learn about their existence

That's kind of the whole point I was trying to make above; if one language makes something super easy to do without having to look for instructions compared, that makes a difference in terms of how people will decide whether to learn it. Individually, lots of small quality of life things add up and can make a language that otherwise would be unapproachable way easier to get started with than languages that don't prioritize that sort of thing.

I know learning is a chore, nothing like jumping into it without thinking. /s

If someone has two choices that can provide the same output, and one of them makes it more effort to figure out how to do, then people will do the other one more often. There's no inherent virtue is spending effort to do something equivalent. It's not clear to me why you seem to think that pointing this out deserves a sarcastic response.

Yeah, sorry. I was aware of that but was being loose with words. I do think that part of the appeal is rust feels more bare metal and direct to people even if they're using heavy abstractions as compared to Java/kotlin or C# programming.

You're behind the times. Write a web app using a framework like Micronaut, Spring Native or Quarkus and you'll get a native Linux EXE out of the build system that starts faster than a C program would (due to pre-initialization).

Not that installing Java is all that hard. apt-get install openjdk is sufficient.

> Those are traits of smaller languages that don't interop well with other ecosystems so they need a lot of evangelism to build out the library ecosystem

> What non-memory management related things is it people like from Rust that is missing from, say, Java or Kotlin?

I'd argue that Rust has better interop with C, C++, JavaScript, Python, Ruby, and probably almost every other non-JVM language than Java and Kotlin. I'm not sure why you think that getting people to write more libraries is the goal of evangelization; if anything, I think Rust is somewhat notorious for people writing lots of libraries but comparatively fewer full applications.

Independent of interop (which I'm not really sure is as important to understanding why languages are or aren't popular as you seem to imply it is), I don't think the tooling in Java is nearly as beginner friendly as Rust. It's not just about the code itself; handling dependencies and building an application that you can run outside of an IDE are not nearly as straightforward in Java as plenty of other languages nowadays.

My point isn't that Java is bad or that doing things in it is hard in the absolute sense, but that "it's possible to do this in language X" is not the same as "it would be easy for a beginner to figure out how to do this in language X". I think there's an inherent lossiness in trying to distill what people like in a programming language into a bullet-pointed list of features, and it's an easy trap to compare those lists and conclude that one language doesn't have anything novel to offer based on that rather than the entire experience of working in a language.

Does Rust really have better interop? At minimum you're going to have to think about the gap between manual lifetimes and GCd allocations, bindings generation, ensuring the target language runtime is installed and so on.

You can call into JS, Python, Ruby and other such languages from Java like this:

https://github.com/graalvm/graal-languages-demos/blob/main/g...

It's very easy and requires no build-time bindings generation or Python/JS/Ruby runtimes to be installed. You can add Pip dependencies via the Java build system you use, as if they are regular libraries. It will also JIT compile the different languages together as one so the boundaries are optimized, you get transparent exceptions, callbacks work transparently as the whole heap is GCd as one, you can using a debugger in a unified way across languages and so on.

But this is sort of beside the point. Java once had lots of evangelism, partly to help build out the library ecosystem, but that was done years ago and now there are lots of libraries to meet most needs. So as a consequence you don't hear about it as much. This thread is a case in point. Lots of people suggesting rarely used languages like O'Caml or Zig, nearly nobody suggesting more obvious candidates that are used for this task, every day by nearly every big company in the world.

> I'm not sure why you think that getting people to write more libraries is the goal of evangelization; if anything, I think Rust is somewhat notorious for people writing lots of libraries but comparatively fewer full applications.

Wouldn't that be expected then? Rust has had lots of evangelism which has successfully yielded lots of libraries?

> handling dependencies and building an application that you can run outside of an IDE are not nearly as straightforward in Java as plenty of other languages nowadays.

I think this may be based on an outdated idea of how things work nowadays. I have my beefs with Java build tools but if you just want to build and distribute a web app it's easy. Using the stack I'm most familiar with:

1. Starting from a blank computer, install IntelliJ or other IDE of your choice.

2. Go to https://micronaut.io/launch and use the little wizard to pick whatever languages and features you want to start with.

3. Download the generated project, open it in your IDE. All the dependencies are now downloaded automatically including the build system and the Java runtime itself. Likewise if you picked features that use JavaScript.

4. Tweak it, run it. To ship it you have several options, but an easy approach is to add this to your build.gradle file (if you're using Gradle):

    dockerBuild {
        images = ["[REPO_URL]/[NAMESPACE]/my-image:$project.version"]
    }

and then invoke the dockerPush build target, either from the CLI (./gradlew dockerPush) or the IDE. You can also compile it to a standalone Linux executable with another build target. That's all there is to it. I don't think Rust improves on this situation. Note that the above instructions work on any computer in the same way, including Windows, with no additional work required.

Scala 3? It has the vast Java ecosystem available and state of the art GCs (plural), with either a focus on throughput or low-latency. Also, it can exclude the null value from the type system, marking it explicitly with a union type.

I think all NVM langs claim interoperability with Java ecosystem. The situation on the ground is never as nice as sold in my XP.

Scala is a great example where I've seen the "best" option being rewrapped libs with scala calls and types rather than a native solution and the dev XP just isn't as good overall.

You can hardly get higher quality code than what is generally available in Java, especially with their stability. Wrapping it to use the language conventions seems like a pretty solid choice to me.

The dev xp, I sorta agree on, but it has improved a lot.

Fast also means more CPU Ressource efficient.

I am all in for not wasting more and more resources.

Strongly agree, yet debates about improving the ergonomics of the language, for which there clearly "is a market", seem to be hindered by those zealous activists. A minority, I'm certain, but vocal nonetheless.

It really can be small stuff too, like hiding that nested generic "GC adjacent" type salad to be accessible only if you need it, via a type alias. Yes, I can define that myself, but the point is that a lot of people need it often, given its widespread use.l, so why not provide one?

I'm sure there's reasons not to do the above example, but that's not the point. It feels like Rust is at 95% of being amazing, and that the remaining 5% is attainable if we want to.

I used to think that it was more likely that Rust would "expand upward" to provide the higher level syntax that people want in a language like I describe above, but it does seem like the language development has vastly slowed down in terms of big new features. I don't necessarily think this is a bad thing; plenty of people didn't like how much churn there was in the first several years after Rust 1.0 came out. I personally didn't mind since I never ran into any significant breakage in what I worked on, but I definitely noticed a change in how open companies seemed to be to use Rust in any capacity coinciding with Rust's releases growing smaller on average; I think "frequency of major language features" is often used as a proxy for "language maturity".

At this point, I think a new language is more likely to provide this niche than Rust, and I also don't think that has to be a bad thing. Having Rust scoped more to lower-level programming where you're more worried about things like minimizing heap usage and avoiding copying strings or whatever rather than trying to be all things to all users might end up with a better experience in the long run.

Lol, and there are the downvotes