291–300 of 437 posts
Earlier quoted context omitted.
Java version updates typically change GC behavior. If one has highly tuned setup there is no guarantee that a newer version would not regress. Another problem is crashes. Java runtime is highly reliable, but still bugs happens.
Are you talking about performance or behaviour? I’ve never seen an issue caused by a GC.
Earlier quoted context omitted.
Let's revisit past conversations: - https://news.ycombinator.com/item?id=43226624 - https://news.ycombinator.com/item?id=43584056 - https://news.ycombinator.com/item?id=36736326 And more. I'm not sure what you found in (checked) exceptions. If you'd like explicit error handling, we have holy grail in the form of Rust which beautifully solves it with implicit returns, error type conversions and disambiguation between…
> I'm not sure what you found in (checked) exceptions. I could copy/paste the entire article here... but it would be easier if you could take a gander: https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex... Summary: Crashy code: You have no compiler-enforced way to know what exceptions might be thrown from a method or library. More crashy code: If a method starts throwing a new exception, you might not reali…
Earlier quoted context omitted.
Python can be tricky with the big differences between 2 and 3.
Python 3 came out in 2008. If the 2 vs 3 differences are still biting you you probably have bigger problems to solve (deprecated, insecure, unmaintained dependencies for example).
Earlier quoted context omitted.
funny. java is known for its stacktraces where you need 3 vertical monitors stacked together to see the whole thing and it still doesn't tell you anything useful about why the app crashed.
Compared to Go where I always have to remember to print the stack trace in every goroutine’s panic handler or use a custom error type that includes the stack trace or I get nothing? And I have to do this very basic thing for every service I spin up? This might not matter for pet projects or CLI applications, but it matters a lot in large scale mission critical servers.
Using "fmt.Errorf" is lean and painless compared to defining custom errors.
Earlier quoted context omitted.
In my 20+ years using java, not once have I used strace or gdb. Java itself has fantastic debugger support, and IDEs have built in step through capabilities. Mentioning Java and Python in the same way in the context of performance is really odd. Python is nowhere near the JVM when it comes to performance
It sounds like you've only ever written code without dealing with it in production. You can't always plug your code into an IDE when your debugging someone else's JVM app on a remote server.
I strongly urge reading some elementary tutorials to educate yourself.
See https://www.baeldung.com/java-application-remote-debugging for CLI based remote debugging
But most people use IDE's.
See https://www.jetbrains.com/help/idea/debugging-your-first-jav...
and https://www.jetbrains.com/help/idea/tutorial-remote-debug.ht...
Java's debugging experience is better than any language out there - with the possible exception of Common LISP. I always cry when I need to debug a project written in another language after so much comfort using Java.
Earlier quoted context omitted.
I am not sure. C# came long after Java already made inroads into the Enterprise space. It was a different time. I would say that many things in IT are not chosen on technical merits alone. You have people that do not want to accrue any blame. Back then, by choosing what IBM endorses or what Microsoft endorses, you absolve yourself of fallout from if and when things go wrong. Back in the 90s, it felt like IBM, Redhat,…
Right. Before Microsoft created .NET and C# they first tried to play their "embrace, extend, extinguish" trick with Java. They released a JVM and "Visual J++" language which was sort of Java, but had incompatible proprietary extensions to lock customers in to Windows. Eventually they were forced to stop that for legal reasons so they completely dropped all Java support, and built their own replacement virtual machine…
Earlier quoted context omitted.
If you want linux support, .net is not what you want. Linux support is an afterthought and it shows. And you never know if it might be dropped next year.
Wrong. Linux support is first class in .Net just like Windows. We are strictly running our .Net code on linux servers and have encountered 0 problems over the past 5 years.
Earlier quoted context omitted.
Just implement concurrency with actors and u save up on some locks and mutexes... The patterns are available, its up to the community to apply proper concurrency patterns.
The only replacement for locks/mutexes is a lock free data structure. Locks are not what make concurrency possible, they are what makes it data-safe. You can use platform threads, user-space threads, language-provided "green" threads, goroutines, continuations or whatever you wish for concurrency management, but that's almost orthogonal to data safety.
Earlier quoted context omitted.
Just implement concurrency with actors and u save up on some locks and mutexes... The patterns are available, its up to the community to apply proper concurrency patterns.
Actors are implemented using locks.
Earlier quoted context omitted.
Modern stacks (as in go and rust) are largely editor agnostic - it is Gosling who lives in the past, thinking that an IDE is still required(and a very weak one, in case of abandoned Netbeans). One of the reasons, btw, why I would take Go over Java in a heartbeat.
There is hardly anything modern about Go, a rebranded Limbo with with anti-intelectuals mentality. As for Rust, there is a reason the large majority is either on VSCode or RustRover.
> the large majority is on VSCode
Here, fixed it for ya. But since when is VSCode an IDE? It is just an extensible editor, not very far from Emacs or neovim. We’ll see how it plays out, but I assume that IDE is a dead concept. No one develops new IDEs anymore, besides the usual money-milking with “Idea + plugin=>new ${name}ide” from Jetbrains.