They do say "live a little", and it strikes me now that perhaps I've completely misinterpreted that phrase. For some reason I've always thought it to be a call to live a lot, or at least more.
But now I see that my interpretation is almost opposite of what the words mean... Huh...
This creates some very uncomfortable cultural clashes sometimes. I remember way back when I was signed up for a service provided by Ms. They did not, as far as I could tell, provide a way to cancel the service, other than to stop paying. Since I had provided them with automatic payments, my bank did not allow me to simply stop paying their invoices, I had to cancel with the provider. I talked to my banks customer service, they refused to help. So I cancelled my account with that bank and moved all the money to a different bank.
Rather more complicated to cancel that service than I would've wished, but hey, I got a better banking service out of the deal, so it's not all bad I guess
Being unable to tell how to cancel something is a different thing. You can contact their support. If they don't have support, or the support refuses, then you contact your bank, with evidence, because it's now an unauthorized payment.
This is separate from the cultural norm that you can only cancel with a certain notice period or by fax.
Not to argue myself out of a job, but I cost around $20k/month, all costs considered(taxes, social fees, PTO, healthcare, benefits). If my efficiency is tripled(which it absolutely is, even before fable) for a mere 6k/month(in reality, 1k is more than enough though), that's ~10x ROI.
This... Confuses me profoundly. My entire career I've worked with Java, and it's mostly a pretty decent language, imo. I think my biggest gripe with Java is the JVM. It's limiting, doesn't really provide any value(the proposed value is portability, but we always run apps in docker containers anyway, so what is it really doing for us?)
I (kinda) get why someone might want to write Haskell rather than Java, but I'm just not sure why you would want to run Haskell on the JVM?
Wow, I think I have almost the exact opposite opinion here.
Java is an ok language, but what really makes it shine is the JVM. It's one of the fastest VMs out there and is one of the most customizable ones as well. For example, pretty much all other languages with a GC have just a GC and that's it. Java allows you to pick and choose your GC based on the workload.
It is one of the least limiting VMs out there because any knob you might want to tune, can be tuned. It's a huge value add.
I think the only part of the JVM that's not great is the fact that objects are bulky and the lack of value classes. Which ultimately means every struct like object you want can have a pretty hefty price in terms of memory. But otherwise, it's best in class basically for everything.
I do agree that as far as VM's go, the JVM is not bad. I guess my recent fascination with rust is kinda shining through here, but I've begun questioning the need for any sort of VM: even the best ones add overhead, and since in practice we always deploy to a very specific environment anyway (when was the last time you deployed a non-dockerized jvm app?), why not just build native executables and skip the overhead?
I dunno, I feel like I'm deploying a VM in a VM in a VM, and at some point they cost more than they taste.
Nope. Quite the opposite. You can precompile Java to a static runtime using the likes of Graal or even android. That actually makes these applications slower, not faster.
Part of this comes down to the Java language design. For Java, there is a lot of dynamic dispatch involved. In rust terms, it's as if almost every parameter was a `Box<dyn Foo>`. In Java, it's pretty natural to have a method like `void foo(List<Bar> baz){}` which can be called by any concrete list type. In fact, compiled down, this actually looks like `void foo(List baz) {}` in the bytecode.
The JVM is able to capture runtime information and realize "Oh, `foo` is always called with an `ArrayList`. And that `ArrayList` always emits a `Bar` element." That allows it to optimize and directly call the `ArrayList` methods rather than having to always do a "Ok, determine the type, look up the method table, call the method". Which is exactly what rust has to do with a `Box<dyn Foo>` signature. To do something similar with Rust you have to do a more complex PGO compilation.
Now, don't get me wrong, rust is smart. That's why they've designed the language such that `foo: Box<dyn Foo>` just isn't as ergonomic as `foo: &Foo`. The language pushes you to use the concrete structs when possible and to avoid doing dynamic dispatch. It supports it, but it requires a lot more ritual.
Weeeelll, I'm definitely getting into dubious nitpick territory, but I'm not sure we can draw the conclusion that the JVM has negative overhead just because Java happens to be slower without it. That's mostly because Java wasn't designed to run without the JVM and, while you can do it, it kinda sucks. I think you have shown that Java is rather out of its element without the JVM, which is fair enough.
Comparing performance with a performance focused systems language such as rust wouldn't be fair either, and the borrow checker is Def cheating compared to GC, so this is also not good grounds to conclude that the JVM has a positive overhead either.
I think probably Go offers the fairer comparison, but my experience with it is so limited I can't really be sure. But unless I'm mistaken it's also GC'd, like Java, and runs without a VM, which is the difference we're trying to isolate.
Ergonomics wise my understanding is they're comparable too, but like I said, I have very little experience with go.
The performance analyses I've seen comparing the two seem to indicate a 10-15% performance increase in go compared to java, depending mostly on which report you read.
It's definitely not clear-cut, I probably wouldn't put much weight to such an argument if it didn't align so well with my intuition. I'm not free of bias. Maybe I just want something different after nearly 15 years of Java? I mean I definitely do, but maybe it's affecting my judgment more than I think?
But that's performance: the other limiting factor is that you need to install Java to run java apps(unless you go against nature and build sluggish native Java, but we covered that).I find I fairly often just don't want to have that requirement. Native executables have their charm, I find.
Would it surprise you to learn that Rust does the same thing that Java does?
The main difference is that rust drives the VM all the way to the point of generating machine code while java generates the machine code at runtime.
Rust does a translation of the syntax to a high level bytecode, then a mid level bytecode, then to LLVM IR, and finally it lets LLVM do the translation of the IR to machine code. The way LLVM uses "VM" is exactly the same way Java is using "VM".
Javascript is similar. In fact, v8, the engine that powers node and chrome, was initially written by Java hotspot developers.
The current performance initiatives that Python and Ruby are taking are doing exactly what the JVM and Javascript does. In fact, the pypy JIT and LuaJIT are learning from and implementing what the JVM does. It's a proven mechanism to getting more performance and better optimizations.
Even GCC does the same thing under the hood.
It really is clear cut, more than you might expect.
This project isn't for running Haskell on the JVM, it's for writing a compiler that produces JVM bytecode. You'd use it if you wanted to implement your own JVM language in Haskell or maybe if you wanted to have some kind of JVM-backed domain-specific language embedded in Haskell.
The reason most "serious" or important software is written for the JVM these days is because it gives you an unparalleled combination of performance, productivity, and observability. There's almost no competition if these things are what you need. The problem isn't so much why pick Java among the alternatives, but that there are hardly any alternatives.
You have to put on some very narrow lenses to argue that "most" serious software is written for the JVM. Operating systems, compilers, browsers, databases, planes, cars, the transaction processing for at least one major payment processor, major cloud services, etc predominantly use other languages.
I don't think there's any single language that most serious software is written in.
C, C++, and C# are obviously also major players in "serious software", but you can estimate the volume of software through the number of people involved (e.g. https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...). If Java doesn't have an outright majority, it has an obvious plurality. And again, there aren't many alternatives.
I was wondering if I was the only one who noticed the AI prose of the tool. It's honestly depressing to know that I have to be this suspicious about content from the first glance
Skip the AI slop calculator and go straight to this recipe.
This recipe is war-hardened.
Yields: Approximately 5 6 in/6cm pancakes (Serves 2–3)
Ingredient | Measurement
All-purpose flour (type 00 flower works well) | 210 g (1 ½ cups)
Sugar | 50 g (¼ cup)
Baking soda/backnatron | 5–10 g (2 tsp)
Butter | 55 g (¼ cup), plus extra for the pan
Vanilla sugar (preferably) or extract | 5–10 g (2 tsp)
Large eggs | 2
Whole milk | 245 g / 240 ml (1 cup)
Fresh berries | As desired (blueberries, raspberries, blackberries)
Instructions
Prep: Preheat your frying pan over medium heat. Grease the surface lightly with butter or oil.
Combine: In a bowl, whisk together the flour, sugar, and baking soda. In a separate container, whisk the eggs, milk, melted butter, and vanilla. Gently stir the wet ingredients into the dry until just combined.
Cook: Ladle one soup ladle of batter into the hot pan.
Add Berries: Drop a few fresh berries onto the top of the cooking pancake.
Flip: Cook until bubbles have popped and stopped forming, then flip.
Adjust heat if necessary: If the pancake is slightly burnt, reduce the heat. Cook until golden brown.
I had Claude build a private podcast station for me. It integrated with Gemini to create a script for the show, based on a topic of my choosing, each talking segment ends with a presentation of the next song, which is played via Spotify, and is selected to have some sort of tie-in with the previous discussion. A tts model generates audio files based on the script, and a playlist is generated to play local file audio segment, then Spotify track, then the next segment etc.
An AI made a program integrating with 2 other AI, it's AI all the way down! and the result is great! I'm learning so much by having my own private radio host speaking about topics that interest me.
I've seen this sentiment a few times on HN recently I wonder where it comes from?
The only thing I can think of is that if the protected files are on a unencrypted drive, then you could boot from a live-usb(or similar) where you have root and read anything. But that's completely irrelevant as we're talking about a piece of software running on a system without root. In this scenario Unix user permissions are safe, barring user error (such as accidentally granting root, like in this instance)
Of course security holes happens, such as copy-fail, but it's pretty rare in the grand scheme of things, and tend to get patched quickly(like copy-fail was)
In my experience, and as someone who has technically been a professional copy editor before (in the sense that I got paid by someone to perform line/copy editing of some material or other, but definitely not who or what you would think if I only said I used to be a copy editor), the uses of "not only, but also" that didn't have anything wrong with them (or didn't deviate from convention, if you like) were in the minority by far. Assuming people in the last few years haven't all become suddenly interested in that particular construction and skilled in its use, the presence of an improperly implemented NOBA should remain vaguely reliable as an indicator of authenticity :D
But now I see that my interpretation is almost opposite of what the words mean... Huh...
reply