3 ms·

> 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 real

> 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.

smolder 2y ago
Rust makes an '.exe', Java makes a '.jar'. I think people want to write programs that run on an OS rather than an interpreter.
- kaba0 2y ago
  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.
  - immibis 2y ago
    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.
    - pjmlp 2y ago
      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.
  - smolder 2y ago
    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.
- pjmlp 2y ago
  Java compilers have been producing '.exe' for about 20 years now, it is a matter to actually care to learn about their existence.
  - saghm 2y ago
    > 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.
    - pjmlp 2y ago
      I know learning is a chore, nothing like jumping into it without thinking. /s
      - saghm 2y ago
        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.
  - smolder 2y ago
    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.
- mike_hearn 2y ago
  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.
saghm 2y ago
> 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.
- mike_hearn 2y ago
  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/graalpy/graalpy-openai-starter/src/main/java/com/example/App.java 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 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.

smolder 2y ago

Rust makes an '.exe', Java makes a '.jar'. I think people want to write programs that run on an OS rather than an interpreter.

kaba0 2y ago
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.
- immibis 2y ago
  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.
  - pjmlp 2y ago
    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.
- smolder 2y ago
  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.
pjmlp 2y ago
Java compilers have been producing '.exe' for about 20 years now, it is a matter to actually care to learn about their existence.
- saghm 2y ago
  > 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.
  - pjmlp 2y ago
    I know learning is a chore, nothing like jumping into it without thinking. /s
    - saghm 2y ago
      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.
- smolder 2y ago
  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.
mike_hearn 2y ago
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.

saghm 2y ago

> 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.

mike_hearn 2y ago
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/graalpy/graalpy-openai-starter/src/main/java/com/example/App.java 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 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.