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

Java is fast, code might not be

jvogel.me

Post reply on HN
Print view View original

101–110 of 259 posts

Re: Java is fast, code might not be

#101

Post by runroader »

xigoi wrote: post #99
philipwhiuk wrote: post #86

Earlier quoted context omitted.

ORMs are a caching layer for dev time. They store up conserved programming time and then spend it all at once when you hit the edge case. If you never hit the case, it's great. As soon as you do, it's all returned with interest :)

The question is why we don’t have database management systems that integrate tightly with the progmming language. Instead we have to communicate between two different paradigms using a textual language, which is itself inefficient.

We tried that in 90’s RAD environments like Foxpro and others. If it fits the problem, they were great! If not, it’s even worse than with an ORM. They rarely fit today since they were all (or mostly) local-first or even local-only. Scaling was either not possible or pretty difficult.

Re: Java is fast, code might not be

#102

Post by ivan_gammel »

xigoi wrote: post #99
philipwhiuk wrote: post #86

Earlier quoted context omitted.

ORMs are a caching layer for dev time. They store up conserved programming time and then spend it all at once when you hit the edge case. If you never hit the case, it's great. As soon as you do, it's all returned with interest :)

The question is why we don’t have database management systems that integrate tightly with the progmming language. Instead we have to communicate between two different paradigms using a textual language, which is itself inefficient.

The answer is simple: model optimized for storage and model designed for processing are two different things. The languages used to describe and query them have to be different.

Re: Java is fast, code might not be

#103

Post by brabel »

spankalee wrote: post #89

Avoiding Java's string footguns is an interesting problem in programming languages design. The String.format() problem is most immediately a bad compiler and bad implementation, IMO. It's not difficult to special-case literal strings as the first argument, do parsing at compile time, and pass in a structured representation. The method could also do runtime caching. Even a very small LRU cache would fix a lot of commo…

Yeah, Java is pretty fast despite the fact that it still has these kinds of obviously suboptimal things going on.

I love how Zig, D and Rust do exactly what you say: parse the format string at compile time, making it super efficient at runtime (no parsing, no regex, just the optimal code to get the string you need).

I say this but I write most of my code in Java/Kotlin :D . I just wish I could write more low-level languages for super efficient code, but for what I do, Java is more than enough.

Re: Java is fast, code might not be

#104

Post by Shorel »

xigoi wrote: post #99
philipwhiuk wrote: post #86

Earlier quoted context omitted.

ORMs are a caching layer for dev time. They store up conserved programming time and then spend it all at once when you hit the edge case. If you never hit the case, it's great. As soon as you do, it's all returned with interest :)

The question is why we don’t have database management systems that integrate tightly with the progmming language. Instead we have to communicate between two different paradigms using a textual language, which is itself inefficient.

Because every single database vendor will try to lock down their users to their DBMS.

Oracle is a prime example of this. Stored procedures are the place to put all business logic according to Oracle documentation.

This caused backslash from escaping developers who then declared business logic should never be inside the database. To avoid vendor lock-in.

There's no ideal solution, just tradeoffs.

Re: Java is fast, code might not be

#105

Post by latchkey »

When they say that AI will replace programmers, I think of this article and come to terms with my own job security.

Most of this stuff is just central knowledge of the language that you pick up over time. Certainly, AI can also pick this stuff up instantly, but will it always pick the most efficient path when generating code for you?

Probably not, until we get benchmarks into the hot path of our test suite. That is something someone should work on.

Re: Java is fast, code might not be

#106

Post by ivan_gammel »

cmovq wrote: post #70

When you're using a programming language that naturally steers you to write slow code you can't only blame the programmer. I was listening to someone say they write fast code in Java by avoiding allocations with a PoolAllocator that would "cache" small objects with poolAllocator.alloc(), poolAllocator.release(). So just manual memory management with extra steps. At that point why not use a better language for the tas…

TBH, I do not see how Java as a language steers anyone to use one those shotguns. E.g. the knowledge about algorithmic complexity is foundational, the StringBuilder is junior-level basic knowledge.

Re: Java is fast, code might not be

#107

Post by cogman10 »

Shorel wrote: post #104
xigoi wrote: post #99

Earlier quoted context omitted.

The question is why we don’t have database management systems that integrate tightly with the progmming language. Instead we have to communicate between two different paradigms using a textual language, which is itself inefficient.

Because every single database vendor will try to lock down their users to their DBMS. Oracle is a prime example of this. Stored procedures are the place to put all business logic according to Oracle documentation. This caused backslash from escaping developers who then declared business logic should never be inside the database. To avoid vendor lock-in. There's no ideal solution, just tradeoffs.

> Because every single database vendor will try to lock down their users to their DBMS.

I mean, that already happens. It's quite rare to see someone migrate from one database to another. Even if they stuck to pure SQL for everything, it's still a pretty daunting process as Postgres SQL and MSSQL won't be the same thing.

Re: Java is fast, code might not be

#108

Post by brabel »

vbezhenar wrote: post #79
looperhacks wrote: post #24

Earlier quoted context omitted.

You can create a native executable with GraalVM. Alternatively, if you want to keep the JVM: With the ongoing project Leyden, you can already "pre-train" some parts of the JVM warm-up, with full AoT code compilation coming some time in the future.

GraalVM is terrible. Eats gigabytes of memory to compile super simple application. Spends minutes doing that. If you need compiled native app, just use Golang.

I used to be really excited about GraalVM but this, together with limitations in what Java code can run (reflection must be whitelisted - i.e. pain) made me run away from it. I do use Go, but my favourite substitute for Java is actually Dart. It can run as a script, compile to a binary or to a multiplatform "fast" format (a bit like a jar), and performance wise it's par on par with Java! It's faster on some things, a bit slower on other... but in general, compiling to exe makes it extremely fast to start, like Go. I think it even shares some Go binary creation tooling since both are made by Google and I remember when they were implementing the native compiler, they mentioned something about that.

Re: Java is fast, code might not be

#109

Post by jandrewrogers »

brabel wrote: post #103
spankalee wrote: post #89

Avoiding Java's string footguns is an interesting problem in programming languages design. The String.format() problem is most immediately a bad compiler and bad implementation, IMO. It's not difficult to special-case literal strings as the first argument, do parsing at compile time, and pass in a structured representation. The method could also do runtime caching. Even a very small LRU cache would fix a lot of commo…

Yeah, Java is pretty fast despite the fact that it still has these kinds of obviously suboptimal things going on. I love how Zig, D and Rust do exactly what you say: parse the format string at compile time, making it super efficient at runtime (no parsing, no regex, just the optimal code to get the string you need). I say this but I write most of my code in Java/Kotlin :D . I just wish I could write more low-level la…

> Zig, D and Rust

Also C++, which works the same way.

Re: Java is fast, code might not be

#110

Post by Seattle3503 »

liampulles wrote: post #21

Understanding algorithmic complexity (in particular, avoiding rework in loops), is useful in any language, and is sage advice. In practice though, for most enterprise web services, a lot of real world performance comes down to how efficiently you are calling external services (including the database). Just converting a loop of queries into bulk ones can help loads (and then tweaking the query to make good use of inde…

> I'm hopeful that improvements in LLMs mean we can ditch ORMs (under the guise that they are quicker to write queries and the inbetween mapping code with) and instead make good use of SQL to harness the powers that modern databases provide.

Maybe we can ditch active models like those we see in sqlalchemy, but the typed query builders that come with ORMs are going to become more important, not less. Leveraging the compiler to catch bad queries is a huge win.

Post reply on HN