Earlier quoted context omitted.
Afaik, a malloc is not guaranteed to return fast. With those requirements it's hard even in C.
Right but you would typically use a preallocated arena.
Don’t call it a comeback: Java is still champ
441–450 of 557 posts
Re: Don’t call it a comeback: Java is still champ
#442Java was actually not bad for me in class when learning software design and data structures, but soul-crushing to work with in the real world. Mindless, unnecessary use of getters/setters, interfaces, and AbstractFactoryImpls. Hiding almost every piece of functionality behind 10+ layers of indirection. Dependency Injection with Spring. They all make it feel like Java draws folks who actually __enjoy__ writing bloated…
FizzBuzz Enterprise Edition [1] is an oldie but a goodie worth a re-mention. 1. https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
Re: Don’t call it a comeback: Java is still champ
#443Earlier quoted context omitted.
Sorry, but the popularity of tools which generate boilerplate for you is, in my opinion, one of the biggest indictments of the whole ecosystem.
agreed. every time I see static code generation I think "this is why people invent and use properly powerful languages".
Re: Don’t call it a comeback: Java is still champ
#444Earlier quoted context omitted.
Imo Erlang's scalability benefits are oversold. Unless you're a national carrier the performance of Java far outweighs Erlang's scalability. Instead, Erlang's undersold killer feature is its robust support for hot code reloading. It enables almost any part of the system to be upgraded without affecting running processes. Other languages and VMs can't do that because they optimize call frames differently and rely on m…
I feel like Erlang somewhat missed its timing window on this, though. With platforms like AWS, GCP, and Azure, you don't really worry about upgrade downtimes, because you just roll out a new fleet of servers (or new fleet of pods, if you're using something like Kubernetes), and then drain the traffic from and decommission the old fleet. Certainly there are a lot of companies managing real physical servers, where this…
If your application require a persistent connection (e.g., you're a real time streaming service, or video), you will have to write some application specific code to migrate the current state over to the new cluster being provisioned. This is actually quite hard to get completely right, and quite application specific (i mean, a very simple method would be to store some sort of identifying token, and when the new connection re-establishes, you reload the state back from when the disconnection happens).
Erlang lets you do this for "free".
Re: Don’t call it a comeback: Java is still champ
#445Earlier quoted context omitted.
It's hard to see how C# will ever find wide usage outside of the MS ecosystem. It's so intrinsically tried to MS.
.Net 6 runs on Linux with, for example, PostgreSQL so how is that tied to M$?
Re: Don’t call it a comeback: Java is still champ
#446Earlier quoted context omitted.
I’ve tried that and it didn’t work reliably for me. The jet brains runtime release works but it’s a bear to figure out which download to use. Regardless, it’s ridiculous that at this point Java doesn’t have full hotswap. All the hooks are there (as is apparent from the error messages when a hotswap fails) and the dcevm is being maintained by jetbrains employees. It needs an internal champion at oracle/sun.
What should happen when you remove an existing field, remove a method already used, change its initial value, etc? You will quickly get some incorrect state by blind hot swapping, and it is not trivial to do in a mutable object graph. Clojure (and other lisps) can do it well because their scope of changes can be really small. Nonetheless, method hot-swap is well-defined and is implemented by OpenJDK.
Re: Don’t call it a comeback: Java is still champ
#447Earlier quoted context omitted.
Old school xml based Spring is horrible and if that was your only exposure, I understand your aversion. But spring-boot has an almost zen like quality once you get that it favor convention over configuration. When I was a Java developer, I'd usually use spring-boot with the following dependencies to make the experience better: - lombok: to generate the boilerplate: constructors, getters, setters, equals, hashcode...…
Spring Boot is still Spring with its annotation madness. Take parameter validation, for example. Crazy, full-screen-width multiple annotations stuffed inside the method parameter list. What on earth is wrong with doing validation as other frameworks do, ie. in the method body?
Just as ridiculous is the HttpSecurity method chaining “DSL”.
Re: Don’t call it a comeback: Java is still champ
#448Earlier quoted context omitted.
I mean, I agree. The static warnings will generally steer you away from the bad cases. From a source-language standpoint, if you don't consider the second-order effects of this design choice, it accomplished a fair fraction of the original goals. But more complex patterns I've seen people try to pass around java.lang.Class objects as a reification. That doesn't really work, because it's skin deep. With significant ex…
I would be interested in your paper. What I find strange in these erasure-reification “wars” is that so many other languages get a pass. And I sort of understand that, languages without a runtime seldom have reflection, or only in some primitive form, and most language on top of a runtime are dynamically typed. So outside of guest languages, Java and C# are unique in this aspect, and Java does use reflection very hea…
Virgil doesn't have reflection, so not a lot of metadata needed at runtime. It does full monomorphization (like MLTon), so you can't have polymorphic recursion. Of course that could go exponential, but in practice I see something like 20%-30% space overhead. I have a tendency to use polymorphism for really generic datastructures, like lists, vectors, maps, but I use tuples a ton and now I added algebraic datatypes. It's a lot of fun and the compiler generates pretty good code and compiles fast--full optimized bootstrap in Of course everyone worries about exponential code blowup. I have a slightly broken implementation of specialization-up-to-machine-rep, but that's not turned on because of some bugs. I think that's the way I'll go in the future.
It is certainly possible to do a type-passing scheme. The built-in interpreter can interpret polymorphic code using dynamic type environments, but can also run monomorphized code. The interpreter is slow.
Re: Don’t call it a comeback: Java is still champ
#449Earlier quoted context omitted.
I think people dislike XML precisely because it's so flexible and unopinionated. It means that when you're parsing a new XML source, you have to look for data that might be encoded in two or three little niches. God help you if it's encoded in each of them, and if the data therein is contradictory. Basically, it's easy to "hold it wrong" in a way that harms consumers.
A schema can be written in 15-30 mins to make XML as opinionated as you want it to be.
Re: Don’t call it a comeback: Java is still champ
#450Earlier quoted context omitted.
My problem with Java is that C# exists which does huge portions of the stuff Java excels at just… better. Before, .NET only ran on Windows which disqualified it from many serious applications server deployments. Today, this is no longer the case for everything but cross platform GUI libraries, and even those are an option if you're okay with not having Linux support. It's more akin to the old car you had just before…
What stuff does C# objectively do better than Java?
- Mature support for async/await since 2012. Yes, Project Loom is coming, a decade later..
- Support for generic-aware value types (struct vs. class) and low-level features like stackalloc: very valuable for high-performance scenarios and native FFI. See for instance https://github.com/ixy-languages/ixy-languages. In comparison, Java doesn't even have unsigned integers. Yes, Project Valhalla is coming someday.
As well, debatable to some folks, but: properties (get/set); operator overloading; LINQ > Java streams; extension methods; default parameters; collection initializers; tuples; nullable reference types; a dozen smaller features