Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IT Runs on Java 8

veekaybee.github.io

Post reply on HN
Print view View original

361–370 of 556 posts

Re: IT Runs on Java 8

#361

Post by js2 »

willbw wrote: post #337
js2 wrote: post #329

Earlier quoted context omitted.

I use TextMate (!) to maintain an Android SDK that's a mix of Java, C and C++ avoiding Android Studio like the plague, to maintain an iOS SDK that's mostly Objective-C, similarly avoiding Xcode's editor, and to maintain the backend written in Python that these SDK's talk to. I've got enough going on in my head w/o having to deal with the complexity of two different IDEs. Anyway, for me Java-the-language is fine. The…

I've not done any Android development but how is IntelliJ for it? While it can be slow on big codebases and obviously never as responsive as vim in a terminal, I think the tooling is excellent. But again, you have to spend a month or so learning the shortcuts.

I haven’t used IntelliJ, only Android Studio which I know is based on IntelliJ but don’t know how much they differ. I find it to be a klunky UI and it easily eats all the CPU on a 2015 3.1 GHz MBP doing things like self-updating, downloading newer SDK versions, re-indexing a small repo, etc. I personally find it pretty unusable. There’s also parts of the UI you can’t even access (like the SDK manager and the AVD manager) unless you have a project open. It’s pretty obviously not a Mac native tool. I assume (hope anyway) it’s much better on Linux.

Re: IT Runs on Java 8

#362

Post by munchbunny »

sporkland wrote: post #348
pron wrote: post #280

Earlier quoted context omitted.

> .NET has both of them I'll give you value types, but reified generics in .NET were a mistake. It really makes interop and code sharing among languages hard, in exchange for a rather slight added convenience. This means that if you're a language implementor and you're targeting .NET, you'll get much less from the platform than you would if you target Java, which makes .NET not a very appealing common language runtim…

Dumb question. Why do reified generics make interop challenging? Or is it reified generics plus value types that don't inherit system.Object? Couldn't the language implementations basically pass around ICollection in .NET somewhat similar to how they do in Java?

The problem is that your GenericClass and GenericClass are really more like GenericClass_T1 and GenericClass_T2 with their own distinct type definitions and interfaces. From the perspective of a different runtime/language trying to interop with these types, you have to somehow understand and work with this mapping game. It's much easier from inside the .NET runtime than outside.

The general solution is, like you suggested, to avoid using reified generics in the module interface where the interop happens.

Re: IT Runs on Java 8

#363

Post by pabl0rg »

jacques_chester wrote: post #335
sl1ck731 wrote: post #307

Earlier quoted context omitted.

I was never super into Java development. I started working in 2014 and was introduced to Weblogic, Jenkins, huge Maven POMs and all the rest, then went into Cloud consulting. When I sit down to do anything I get so wrapped up in all the stuff that comes along with Java and feel like I have to use some huge IDE like Eclipse (I hate) or IntelliJ (I If I could just write code and have a simple package manager like NPM o…

> What I really want is to get a "lite" Java project like this up and running with all of the smart people's opinions in place that I can develop entirely in a lite editor (preferably without XML anywhere). That's pretty much the original value proposition for Spring Boot. "I just want to get to work". I used Spring Boot before encountering a Spring 3 project. The difference is phenomenal. Disclosure: I work for Pivo…

Spring boot still requires gradle, which is much more complex than naive use of npm or python pip.

In the long run java build tools are better, but due to the learning curve a lot of folks balk (leave) and use a different stack.

Whoever is in charge of openJDK should just adopt kotlin as java 14 even if it was Not Invented Here.

Re: IT Runs on Java 8

#364

Post by btilly »

gliop wrote: post #347
btilly wrote: post #332

Earlier quoted context omitted.

Your opinion is your opinion. My opinion of the company and its products is more consistently negative than any other large company. And while you think that the non-Java world is suffering, I think you have some tunnel vision. Let's just say that I am personally happy with my decision to stay away from Java. And the brief periods where I had to work with Java were misery. Languages have personalities as well as comp…

Startups don't use Java because Java is for large-scale stable long- lived enterprises, not for prototyping simple small web apps that might be thrown away in a couple of years.

You often hear this, but what does it actually mean? Why is Java for one but not the other.

Here is my understanding.

Java was designed to limit the damage that any developer could accidentally do, rather than maximize the potential for productivity. Which is an appropriate tradeoff for a large team.

It is hard to get good statistics on this, but the figures that I've seen in books like Software Estimation suggest that the productivity difference is around a factor of two.

This matters because it turns out that teams of more than 8 people have to be carefully structured based on the requirements of communication overhead. (A point usually attributed to The Mythical Man-Month.) This reduces individual productivity. Smaller teams can ignore this problem. The result is that measured productivity for teams of size 5-8 is about the same as a team of 20. But the throughput of large teams grows almost linearly after that. An army does accomplish more, but far less per person.

Limiting damage matters more for large teams. Which are more likely to be affordable for large enterprises. However being in such an environment guarantees bureaucracy, politics, and everything negative that goes with that.

By contrast startups can't afford to have such large teams. Therefore they are better off maximizing individual productivity so that they can get the most out of a small team. And using a scripting language is one way to do that.

Re: IT Runs on Java 8

#365

Post by wikibob »

pron wrote: post #321
endymi0n wrote: post #282

Earlier quoted context omitted.

Funnily enough, Go just chose to solve the problem the other way around: While JVM tackled GC with the code equivalent of lightsaber-equipped drones, Go‘s GC is almost embarrassingly simple in comparison (although it‘s pretty decent by now). The major difference is that the whole Go language and stdlib is simply written around patterns that avoid allocations almost magically. The simplicity of the Reader and Writer c…

I agree it's impressive that Go manages to be not all that much slower than Java while having a much simpler runtime, but much of the simplicity is gained from lacking features that are very important in many cases of "serious software" like deep low-overhead continuous profiling and ubiquitous dynamic linking.

I’ve seen you mention the superior operability of Java and the JVM in high load production environments and I think this is a really important, often overlooked, and commonly misunderstood point.

Would you be up for writing a short post or blog post going into some anecdotal comparisons and sharing some resources?

Re: IT Runs on Java 8

#366

Post by nemothekid »

gerbilly wrote: post #268
tomohawk wrote: post #265

Earlier quoted context omitted.

It takes a lot of power to push something that large. A lot of brain power to grock the ecosystem. Outside of the Java bubble, the view is quite a bit different. All that sophistication looks like a wasted effort. Take something as simple as admining the garbage collector. Java has a big selection of GCs, and each has their bunch of knobs for tuning. And you have to pay attention to that stuff. After working with Go…

> Java has a big selection of GCs, and each has their bunch of knobs for tuning. And you have to pay attention to that stuff. You never have to touch them in the Java world either, unless you like making performance worse that is. I've never ever seen a case where fiddling with garbage collection parameters didn't make things slower. I worked with a guy who worked on a popular java compiler, and he says the same thin…

Cassandra has benefitted from so many GC tweaks that I find this view hard to believe.

i can only imagine someone having this view if they have never cared about latency. How have you never experienced a multi-second GC pause on default CMS settings?

Re: IT Runs on Java 8

#367

Post by jscholes »

syjer wrote: post #287
MaxBarraclough wrote: post #262

Earlier quoted context omitted.

> the actual language & core libraries are incredibly slow to react to anything. async/await being the obvious example. Still no sign of it in the Java language, nor any expectation of it, unless I missed something.

I think that the approach done in https://wiki.openjdk.java.net/display/loom/Main is better than the async/await infrastructure.

Well, other than the fact that it only supports Linux and MacOS.

Re: IT Runs on Java 8

#368

Post by pron »

arcticbull wrote: post #338
pron wrote: post #85

The funny thing is that from a purely technological point of view, Java (even the 5-year-old Java 8 and certainly recent versions) is far ahead of most other stuff hyped on HN (as well as less hyped stuff). Virtually no other platform comes close to that combination of state-of-the-art optimizing compilers, state-of-the-art GCs, and low-overhead in-production profiling/monitoring/management. And much of the cutting-e…

Respectfully I'm not sure that's true. > State-of-the-art optimizing compilers. LLVM provides coverage for many of the new languages that are hyped these days (with the notable and truly unfortunate exception of Go). LLDB provides an excellent debugger infrastructure. > State-of-the-art GCs. True, there's some good work there but I'm excited about languages that don't need GCs at all, so that we can finally stop tric…

As I said in another comment, there can be more than one thing that's cutting edge, especially as the JVM and LLVM operate at completely different levels. Never mind GCs -- LLVM isn't even safe, and neither is WASM; and that's good at that low level. In fact, LLVM is employed by Falcon, the Zing JVM's JIT, and OpenJDK's HotSpot is compiled to LLVM on Mac.

> I'm excited about languages that don't need GCs at all, so that we can finally stop tricking the memory wizard into complying with our workloads and focus on determinism, power efficiency and memory efficiency.

That's fine, but it seems like giving up GCs comes with its own non-negligible costs, so much so that the two hardly compete in the same domains.

> Correct me if I'm wrong but a lot of that is available in dtrace is it not?

They have similarities (closer analogs would be https://github.com/btraceio/btrace and http://byteman.jboss.org/ than JFR), yes, but operate at different levels with somewhat different capabilities.

> This is actually why I'm so excited by LLVM. I think it's the biggest advancement in computer science in ages and ages.

LLVM is popular, extremely useful, and quite cutting edge in its domain, but there isn't much of a "computer science" advancement as there is, e.g., in Graal/Truffle.

> It allows them to leverage the years of work and bundles of PHDs worth of research that went into the rest.

It certainly does, but there's a lot that LLVM doesn't give language designers that a JVM does, like GCs and high-level language interop.

> Over time the delta between what Java has and what LLVM has will shrink which in turn narrows the gap between Java and every other LLVM based language.

I don't know if LLVM wants to operate at Java's level or vice versa. While LLVM may offer some basic GC and Java may offer "safe" LLVM with things like Sulong, I believe their main focus will be their own respective levels.

Re: IT Runs on Java 8

#369

Post by dragonwriter »

sanderjd wrote: post #313
dragonwriter wrote: post #291

Earlier quoted context omitted.

> Great points, but it's actually much simpler than that: if you want static types, you have already eliminated the majority of HN darlings (JS, Python, and Ruby). Well, if you ignore mypy and consider TypeScript distinct enough from JS to not count, sure, though TS is if anything more of an HN darling than bare JS (Really, none of those languages has been an HN or developer community darling in years, though Python—…

>> Most developers [from context: who want static types] turn to C++, Java, or C# > I'd be surprised if more than half (most) developers using static typing use those languages and not others outside that set. Really? I'd be surprised if it was less than 90%. What is the competition? Go, TypeScript, Swift, Scala, Kotlin, Rust (in rough order of my gut sense for how widely used they currently are)? These are all still…

> If you argue that C has static types, then I guess you're probably right.

C (like C++) is both statically and weakly typed; strong and static typing are orthogonal axes (dynamic but strongly typed languages are common.) If you mean strong and static when you say static, you need to take C++ off your list.

Re: IT Runs on Java 8

#370

Post by sidlls »

pron wrote: post #85

The funny thing is that from a purely technological point of view, Java (even the 5-year-old Java 8 and certainly recent versions) is far ahead of most other stuff hyped on HN (as well as less hyped stuff). Virtually no other platform comes close to that combination of state-of-the-art optimizing compilers, state-of-the-art GCs, and low-overhead in-production profiling/monitoring/management. And much of the cutting-e…

Java itself is fine. It's very popular--and that's the biggest problem. Not the language as such but the developer ecosystem around it. I am dead tired of seeing 80-character camel-case function and variable names, annotations that hide critical functionality of the code, stack traces dozens or hundreds of lines long because of the amount of indirection and poorly conceived configuration "languages" used to support dependency injection so developers can save a few characters of typing or mask dependencies and complexity, etc.

The language may be fine, but it has been appropriated into the worst sort of terrible programming paradigms one might imagine.

Post reply on HN