411–420 of 437 posts
Earlier quoted context omitted.
When you need to debug across the entire system and into the kernel, I'd use dtrace which has had java stack frame support since... I don't remember anymore, but closing in on 20 years.
No one uses dtrace anymore. bpftrace is integrated into the kernel and can extract btf type information embedded into the kernel binary.
Earlier quoted context omitted.
Is data access in such a project purely from in-memory sources? I suspect most people shun it because database access- especially if the DB itself is over the network on a different machine- already slow enough that ZGC / zero allocation won't be noticed.
> Is data access in such a project purely from in-memory sources? yes. > I suspect most people shun it because database access- especially if the DB itself is over the network on a different machine- already slow enough that ZGC / zero allocation won't be noticed. Database access, if you're talking network latency query/transaction processing time, is essentially irrespective of the language being used, so that's not…
If you have the extra network latency from external services, you need some pretty outrageous traffic for GC to become a problem, I would think.
Earlier quoted context omitted.
The language has/had some rough edges that have been improved over the years, but the developer experience of using a strongly-typed, object-oriented language within a sturdy IDE like Idea is just second to none. The debugging process is so very straightforward. Java became synonymous with enterprisey bloated systems for good reason, but there is no pile of mud Java system that can't be stepped through cleanly with a…
> javadoc Indeed. Many languages have something similar to Javadoc, yet somehow I haven't encountered anything quite as good as Javadoc, and I can't explain why or exactly how it's better. I admit I haven't tried that hard either. But I suspect it's down to the nature of the language and how, with well designed libraries at least (and not all are, certainly,) there is a nice decomposition of modules, packages, classe…
Earlier quoted context omitted.
>My other issues with the JVM is how much of a black box it is from a platform perspective, which makes debugging a PITA Java has one the greatest debugging capabilities ever. dynamic breakpoints, conditional breakpoints, hell you can ever restart a stack frame after hot deploying code without a restart. You can overwrite any variable in memory, set uncaught exception breakpoints, and even have the JVM wait for a deb…
> dynamic breakpoints, conditional breakpoints, hell you can ever restart a stack frame after hot deploying code without a restart. You can overwrite any variable in memory, set uncaught exception breakpoints, and even have the JVM wait for a debugger to connect before starting. There is no equivalent in any other language that does _all_ of these things .NET + C# can do all of these things.
Earlier quoted context omitted.
Why do I need to? Why can't I let the garbage collector deal with it? Rust's macros on the other hand are excellent, and more languages should have expressive macros like that.
You need lifetimes in order to make the affine types ergonomic to use through borrowings and aliasing mechanics. You want the affine types to prove all kinds of things about resource management, beyond just freeing allocations, which we generally call RAII. You model file and network handles as RAII, mutex locks as RAII. Other languages use constructs like context managers or try-with-resources to capture this, but t…
Earlier quoted context omitted.
You need lifetimes in order to make the affine types ergonomic to use through borrowings and aliasing mechanics. You want the affine types to prove all kinds of things about resource management, beyond just freeing allocations, which we generally call RAII. You model file and network handles as RAII, mutex locks as RAII. Other languages use constructs like context managers or try-with-resources to capture this, but t…
Since you're mentionning it : i was surprised to find no golang "context" equivalent in rust's axum. How do you manage cancelling a long-running operation triggered inside an http request handler when the connection closes ? is it via RAII ?
Earlier quoted context omitted.
Clojure is around and still going strong! I mean the IDE experience is probably not what you're describing, but you can use the JVM with a mature, productive Lisp language.
Fair point. To me, Clojure is an "almost-lisp" because of its lack of cons cells, its use of all the brackets on the keyboard, and its dependence on the JVM which can't do tail jumps. I love Common Lisp because it compiles down to the metal and you can write code with it that starts instantly and runs very fast. But all the above is more about personal taste than anything else, so maybe I should try Clojure again.
I've been working in .NET/C# for the past few years, and while I'm happy with it, I still think the JVM/Java are the best ecosystem overall I've worked in. It's amazing how many things the Java ecosystem gets right that .NET gets wrong. For instance, Java introduced the fork/join pool for work stealing and recommended it for short-lived tasks that decomposed into smaller tasks. .NET decided to simply add work-stealin…
[flagged]
https://news.ycombinator.com/item?id=43009383 (Feb 2025)
https://news.ycombinator.com/item?id=43009374 (Feb 2025)
https://news.ycombinator.com/item?id=41121266 (July 2024)
https://news.ycombinator.com/item?id=40979059 (July 2024)
Earlier quoted context omitted.
Since you're mentionning it : i was surprised to find no golang "context" equivalent in rust's axum. How do you manage cancelling a long-running operation triggered inside an http request handler when the connection closes ? is it via RAII ?
Yeah due to the design rule that "futures do nothing unless polled", it's enough to simply drop them and it cancels the whole tree of work. That doesn't necessarily cancel other tasks that were spawned that the future might have been waiting on. That's really easy to build if it's needed, since we do have RAII. This is part of why Rust's futures compose really well in ways that goroutines just do not and JS promises…
Edit: isn't that the case for all "async" systems, in every language ?
Earlier quoted context omitted.
Doing what? Benchmarks aren’t all that useful since usually the bottleneck is File IO, external api calls, db calls, user latency or a combo of the 4. Go’s main advantage in this matchup would be conciseness. Go code looks so clean and nice, Java doesn’t. I personally don’t care for Java, but I have bills so it’s always in my back pocket. Things happen , sometimes you need to write Java to eat. “Fred, you really shou…
> I personally don’t care for Java, but I have bills so it’s always in my back pocket. Things happen , sometimes you need to write Java to eat. I write Java to pay bills and my eyes and fingers thank me everyday for sparing them from a sea of if err != nil. I won't even go(!) into the iota stupidly compared to Java's enums.
I built a small phone app with it. The best way to describe it is incomplete. I think the philosophy is to make things more minimal?
A lot of frameworks don’t exactly do everything they need to.
I’ll still pick it over Rust, which seems to like punishing the developer.