> IT Runs on Java 8 using Go
> IT Runs on Java 8 using Rust
> IT Runs on Java 8 using Tensorflow
Still makes sense
IT Runs on Java 8
351–360 of 556 posts
Re: IT Runs on Java 8
#352Earlier quoted context omitted.
Kotlin uses the same VM and API, so it makes no difference in this regard. It's not a big change – it's fully interoperable with Java. You can easily take a single class in a Java application and rewrite it in Kotlin, and everything continues working just as before. Google adopted it because, as they more or less said in the announcement, it was already being adopted by the community and it hugely improved developmen…
but you splitting your developer base. * There will be people better at kotlin * There will be people better at java. This is a problem when you are looking at hiring new people etc . This fragmentation is going cause issues just because people are hedging against Oracle future decisions. In a perfect world Google should have bought Sun and the current version of Java would look at lot like Kotlin.
Kotlin is a light syntax for a coding style. It's as easy for a Java dev to learn Kotlin as it is to learn Spring or Hibernate or whatever library or framework the team at your new job uses
Re: IT Runs on Java 8
#353Earlier 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…
> and there is a reason that the startup world stays away from Java in droves. You may have your own case of tunnel vision. I mean, sure, there are "droves" of startups that stay away from Java (many only to turn to it later), but there are also "droves" that adopt it from the get-go.
Why don't we look for some concrete information?
According to the statistics reported by https://www.codingvc.com/which-technologies-do-startups-use-..., Java looks like the fourth most commonly used language in the startup world, and its usage is not particularly well correlated with success.
Both Ruby and Python are more popular than Java, AND are better correlated with how good the company is. Your odds of being in a successful startup are improved if you are in those languages INSTEAD OF Java.
What about from the individual programmer level? Triplebyte did an article about how programming language and hiring statistics correlate. My impression is that their programmers are mostly being hired into relatively good startups, so it is a pretty good view of the startup world. That article is at https://triplebyte.com/blog/technical-interview-performance-....
Long story short, Java was the #2 language that programmers chose. Behind Python. Not so bad. But choosing Java REDUCED your odds by 23% of actually getting to a job interview. And for those got to a job interview, it reduced your odds by 31% of actually getting hired. By contrast Python IMPROVED those same odds by 11% and 18% respectively.
Apparently the startup world doesn't like Java developers either. You'd be far better off with Python.
Now I'm sure that you can trot out every successful Java startup out there. And there will be quite a few. But based on available data, not opinions, I did NOT express tunnel vision when I said that the startup world stays away from Java in droves.
Re: IT Runs on Java 8
#354Earlier quoted context omitted.
It's a bit disturbing how much people in this industry are focused on tooling. That strikes me as such an odd critique, and I can't make it work for any other industry; you certainly wouldn't apply it to something like dentistry, or oil refinery, or plumbing. If I went in for a root canal and the dentist said "We're gonna kick it old school today, sniff this rag of ether, I'm bored with all these tools!" I would grab…
>>That strikes me as such an odd critique, and I can't make it work for any other industry; you certainly wouldn't apply it to something like dentistry, or oil refinery, or plumbing. A software developer's job is to create software. Almost like an author. Some more than others. At the end of the day, no matter how good your pen is, it will not write a great book for you.
I see your point, but I think you can't ignore the power of tools.
Most software created itself is a tool, a tool which typically leverages the speed of computing to perform a task hundreds, thousands, or millions of times faster than a human could. Think making a bank transfer - I can do this in 5 seconds on my phone now, which would take me over an hour to physically head into a branch and do it in person, and even then we are relying on computing power at the branch itself.
Why would we, as software developers, act like we aren't going to use tools ourselves? For productivity, for a more pleasant (or even just less frustrating) experience?
I initially was a vim + printf debugging stalwart, but having been in a Java environment grew to realise the immense power of an IDE like IntelliJ and how beneficial it is. You can detect errors in the code almost immediately, so spelling mistakes and missed semicolons aren't a thing. You can fix them in a fraction of a second. If I write a function that could be written in a clearer way, or I'm not sure what type I should write for a variable, it will suggest it immediately and I can follow that suggestion with a press of a key.
Yes, it cannot write great software for me. But if you have worked with software where there is no autocompletion, poor debugging and profiling tools, then I find it hard to believe that you don't think that the addition of these tool can help you write at the least MORE software, and probably even BETTER software.
It is not the same as writing a novel, as much as I would like to romanticise that it is. It is about organising and coordinating components to work together, and for this tools can be a tremendous help.
Re: IT Runs on Java 8
#355Earlier 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…
Is a value type different from a value class? https://github.com/google/auto/blob/master/value/userguide/i...
Yes, those value classes are still heap/GC allocated objects.
Value types are a generalisation of `int`, `long`, `float` (etc), where values are stored inline, not allocated on the heap. For instance, a `Pair` that isn't a pointer, but is instead the exactly the size of a long plus a double, and is the same as writing `long first; double second;` inline.
Re: IT Runs on Java 8
#356The 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…
I think everything you mention here is actually related to the JVM and not Java specifically, and while I agree the work is impressive, it’s also true that languages such as Kotlin and Scala benefit from that work while also offering some very nice modern improvements.
Re: IT Runs on Java 8
#357It's a bit disturbing how much people in this industry are focused on tooling. It's a biproduct IMO of working on boring problems or supporting morally ambiguous corps. That thing that you need to keep yourself busy and keep going in the rat race.
The more experience I have, the more I appreciate good tooling. Why? Because the tooling is what ends up being used every day in so many ways. A minor improvement in tooling can lead to drastically better quality of life. It's like getting a fancy but expensive office chair - no, I don't need it, but my back will thank me at the end of every day . The catch here is that this applies across the board. For example, man…
I use great software with subpar tooling all day long, and it is not a good feeling. It feels like sawing of your own arm to feed your hungry customers.
Re: IT Runs on Java 8
#358Earlier 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.
https://wiki.openjdk.java.net/display/loom/ which is superior to async/await, if I may say so myself (I'm the project lead)
> Fibers are user-mode lightweight threads that allow synchronous (blocking) code to be efficiently scheduled, so that it performs as well as asynchronous code
Sounds a lot like Erlang BEAM processes.
Re: IT Runs on Java 8
#359Earlier quoted context omitted.
JDBC is not JEE - it is core Java. Servlets are the original web-container Java spec, independent of JEE. Both are great specs supported by several stable and performant implementations - rock solid tech compared to a lot of the flaky stuff you find advertised today.
How are Java programmers implementing RESTFUL APIs these days?
I use javalin.io which was written by one if the maintainers of sparkjava (not to be confused with Apache Spark).
I'm a big fan.
Re: IT Runs on Java 8
#360Earlier quoted context omitted.
but you splitting your developer base. * There will be people better at kotlin * There will be people better at java. This is a problem when you are looking at hiring new people etc . This fragmentation is going cause issues just because people are hedging against Oracle future decisions. In a perfect world Google should have bought Sun and the current version of Java would look at lot like Kotlin.
Kotlin is a light syntax for a coding style. It's as easy for a Java dev to learn Kotlin as it is to learn Spring or Hibernate or whatever library or framework the team at your new job uses
It's a whole other domain of things to learn, and now we're stuck with context switching all of the time.
Even if Kotline were 'better' (And I don't think it is), it'd have to be quite a jump better.
It's a little nicer for getting ideas down quickly, but beyond that to me it's just 'different' and now a whole other bag of things to support.
If I have to chose between Kotlin+Java or just Java I'll take just Java.
Going back to Java from Kotlin there's really nothing I miss.