pron

11 ms·

91.
by pron 2mo ago
That some specific kinds of GCs, specifically moving GCs (of the kind used in Java and .NET, but not the kinds used in Python or Go, which are also very different from each other) can be highly efficient, at least in principle, has been w
92.
by pron 2mo ago
Of course GC is not inherently slower than other memory management strategies. Not only because GC is not a "memory management strategy" but a wide spectrum of them, but also because some GCs are used to speed up memory management
93.
by pron 2mo ago
> Running a GC takes time Yes, but for a moving collector that's less time than it takes to run malloc and free. The interaction of a moving collector with most object is bump allocation when they're allocated (similar to s
94.
by pron 2mo ago
> Go, Java, C#, and Python use garbage collectors. This makes them easier to use but slower and less predictable. It does not. The term "garbage collectors" covers a whole spectrum of algorithms, some might slow you down (thoug
95.
by pron 2mo ago
Yes, I would have said JNI (and JNI still exists). But FFM is much more than a wrapper. In most situations it offers a significant performance boost over JNI. E.g. see https://github.com/Glavo/java-ffi-benchmark , which
96.
by pron 2mo ago
It's not so easy. The pattern you'd want to try and match or beat moving collectors is arenas, and they're really not trivial to use in C++ (or Rust). The only low-level language that supports them well is Zig. But even then,
97.
by pron 2mo ago
One thing we C++ programmers know, though, is that direct control over instructions helps performance in small programs but can hurt it in larger programs. E.g. it is really hard to enjoy the performance benefits that moving collectors and
98.
by pron 3mo ago
The JVM goes for performance, too, only with an emphasis on the performance of larger programs. It's designed to address some of the serious performance issues that large C++ programs tend to suffer from (I originally made the switch t
99.
by pron 3mo ago
I think you've misunderstood, because not only would this have been the right design if it had been in Java since day one as it's in line with the philosophy of the platform, it's also simpler than in other languages. The ide
100.
by pron 3mo ago
Yes, but only in the programming sense of productivity, not in the economic sense. When prices stop being subsidised and the novelty wears off, this will boil down to the question of how much money is that worth? We're already seeing a
101.
by pron 3mo ago
> Not very different from Java or C# It will be significantly worse than Java, at least in some important situations (don't know about C#). I've been programming in C++ for many, many years, and I find it increasingly hard to e
102.
by pron 3mo ago
You can, and indeed that's what we JDK developers do. But even aside from the fact that writing the code is only a very small portion of the effort in this particular project (you can see that the volume of code making its way into the
103.
by pron 3mo ago
What spyware is there in the JDK? It's open-source, so you can look for yourself.
104.
by pron 3mo ago
Because, as the FAQ section clearly states, the technical and management aspects are not the only ones. There are also legal issues, and until they are clarified or resolved it's best not to let code in that has the potential of causin
105.
by pron 3mo ago
> You don't find it useful that use after free, double free, uninitialized memory, and many kinds of race conditions are just impossible in code that compiles? Sure, but memory safety by itself is not the reason to pick Rust because
106.
by pron 3mo ago
That depends on what you mean by GC. There are refcounting GCs, there are mark-and-sweep tracing GCs (like the one Go uses), and there are moving GCs (the last ones are the ones used in Java, V8, and .NET). Moving GCs win in many situations
107.
by pron 3mo ago
> The borrow checker is a good idea independent of memory safety. In fact, I would say that if you think that the borrow checker is a tool to ensure memory safety and it is getting in the way of flexibility, you probably don't under
108.
by pron 3mo ago
> This is incorrect. You can write those data structures in safe Rust just as easily as you can in Java. You'd write them using the safe primitives that the Rust stdlib provides to you, just like how Java does it. Such collections c
109.
by pron 3mo ago
> I don't know a moving GC crate for Rust, but I do know that building a safe moving GC crate for Rust is possible, using the same principles as existing GC crates. But those pointers would not interoperate easily with code that doe
110.
by pron 3mo ago
They find it immensely useful in practice only when the safe subset is useful. In C, you could say that the same definition of memory-safety exists, only the safe subset is empty, and in that case people don't find the fact that C coul
111.
by pron 3mo ago
> safe Rust is actually more memory safe than Java, since it guards against data races No, it isn't. First of all, data races in Java are memory-safe, as guaranteed by the Java memory model. Second, even if that were safer in some s
112.
by pron 3mo ago
With FFM you can do unsafe things, such as call native code and directly manipulate memory read from or written to by native code.
113.
by pron 3mo ago
> No, you really can. You can use GC crates and the performance will be like Java It won't be anywhere near Java's. Those GCs are mark-and-sweep collectors. Java uses moving collectors. Moving collectors are used to avoid the h
114.
by pron 3mo ago
You can't get the same semantics (e.g. no leaks) and you certainly can't get the same performance.
115.
by pron 3mo ago
> This is a fundamental misunderstanding of how "unsafe" code relates to a platform's trusted computing base. Rust could move all of those unsafe data structures out of the standard library and into the compiler itself, th
116.
by pron 3mo ago
No, I was replying to imtringued. But to answer your question, I reach for a low-level language when I need the one and only thing low-level languages are designed to do best, which is give me full and precise control over the hardware. In
117.
by pron 3mo ago
P.S. And that brings me back to the universality point, that you're actually repeating, so let me explain it again. All programming languages bring a certain aesthetic that appeals to some and repels others within their intended domai
118.
by pron 3mo ago
What makes a JVM a good fit for a low-level language is the need/utility for precise control over the hardware, but that's always the reason to want a low-level language (why would you use a low-level language if you don't wa
119.
by pron 3mo ago
> Stack allocation by default, Value types and direct embedding of values in data structures. This used to be the big one, but not anymore: https://openjdk.org/jeps/401 (so Valhalla is integrating in JDK 28; it&#x27
120.
by pron 3mo ago
> To him, the entire code base might as well be unsafe. Not at all. I would very much like the code to be safe, it's just that I reach for a low level language to get the thing that low-level languages are designed to offer me, whic

More ›