The labs still have performance as a differentiator for coding usages and similar, and for other things there's still all the same reasons people switched cloud hosted stuff in the first place. AWS & friends didn't get popular because the hardware was out of reach, after all.
Golang gives you none of nice features of a modern language while being about the same performance tier as Scala or Java, so there's basically no reason not to use Scala.
It's sad - I spent a good 12 years writing Scala every day and it was the ideal language for my brain. Until it wasn't - sbt got too complex for it's own good, everything became "very smart" developers over-using implicit conversions, you couldn't find a project that wasn't an opinion war on cats vs whatever. It collapsed on the weight of it's own smugness.
go and kotlin aren't it, gleam scratches the itch but I can't justify writing code that would impossible to hire for.
Every job I've has has used different languages so I don't really understand the need to find a dev for a specific language. I went from network firmware in C to banking application servers in Scala and it took like 2 weeks to ramp up. Not a big deal. Now I write lower level networking stuff again in Go, which seems like its just worse than e.g. C-with-templates (and occasional classes) style C++ so I don't really understand why people like it.
I think it used to be common to just look for smart people and assume they can run with whatever stack. Wasn't that the point of abstract algorithm questions etc. (basically an IQ test)?
>I think it used to be common to just look for smart people and assume they can run with whatever stack. Wasn't that the point of abstract algorithm questions etc. (basically an IQ test)?
Lots of companies where software isn't the focus see it as a cost center, so they'd prefer to hire lower-IQ specialists instead of higher-IQ generalists, because the latter are more expensive/have more options.
Java is almost always significantly faster than Go because the Go runtime does a poor job of exploiting large memory page, doesn't support text-on-huge-pages, and barely supports profile-guided optimization. With HotSpot you get all of this and more for free. Go is fine but Java is peak.
I ported a moderate sized java project to golang. Test suite runs order of magnitude faster now. There isn't much change in terms of the architecture. Pretty much the same algos and data structures. The whole dev tooling runs on a 16 gb mac without swapping now. I used vs code for both
IME they're both in a place where Rust is maybe ~40% faster for a decent CRUD web application server, but with go you need to write much lower level code to get there (e.g. using composable generic iterators will ruin your allocations, so it's all manual for loops). You can write idiomatic high level Scala and get the same performance. Which could be as simple as the go compiler offers no ability to force inlining and has way too low of a complexity threshold, but that basically makes reusable code unusable in high performance situations.
The whole go team's philosophy tends to also revolve around assuming their users don't know what they're doing, which is annoying. Like an inline keyword: thinking you know better than me doesn't mean I'm not going to inline it; it means I'm going to manually write it inline myself in the code, and then think the language sucks because it's tedious, error-prone, and verbose. Or they tend to mark lots of stuff private for no reason, and e.g. with TLS 1.3 they just ignore your config because they think they know better, etc.
Isn't this mostly about java cold start costs? It might be that other people are optimizing for steady-state performance, not transient startup performance.
One particular test was running for 20 minutes, doing repetitive calculations, hopefully enough to get jitted. It finishes much much faster now. I could have profiled to check what was going on but the test was simple and the dev tooling and the ram usage was a major concern for me. Also gradle upgrades were painful.
Java tooling taking up a lot of ram was a major motivation for me. I have done a lot of Scala as well. I don't think either Java or Scala in the real world beat go on performance for most cases. I don't doubt that in some cases jvm can do better but at least before Valhalla delivers all the promises, in real world, I am doubtful.
I have been a Java/Scala user almost for the majority of my career. I doubt I would pick jvm over golang going forward though. Also not having to deal with OOP is a plus.
I am not sure I understand your point. It's a meaningful comparison based on my situation. But even if it isn't, what are you arguing for? I change my use case rather than the tool/lang? Sorry if I misunderstood.
> First off, Oracle are doing versions at approximately twice the cadence
Is that actually a good thing?
But Oracle started playing a game, for better or worse, where they decided to couple the "language version" with a single specific runtime's release schedule. For example, in "Java 27" there are exactly 0 language changes and 1 minor feature addition to the TLS library.
Everything else is OpenJDK runtime internals which don't impact the language or how you use it. So if you don't use OpenJDK (such as if you use Oracle's other runtime, GraalVM), then Java 27 basically doesn't even exist at all. Skimming the past couple of C# releases, it doesn't look like Microsoft is playing that game, so the release cadence will of course be different.
The Java language and runtime have been co-designed as a unified platform for many years now. Virtually every significant feature has language, library, and VM people working on it, and we often don't even know when we start how much of the feature would be in the language, library, or VM. Consequently, there is no "language version" or a "runtime version". There's only a platform version, which is defined in a single spec approved by the JCP (https://openjdk.org/projects/jdk/27/spec/). This also makes things easier with regards to compatibility and evolution.
And of the 4 non-preview JSRs in the Java 27 release, only 1 of them is actually part of the "platform version".
The other 3 are strictly changes to Hotspot internals with no platform involvement at all. They did not change any aspect of any Java platform in any way whatsoever. That is what I'm referring to. I'm not referring to the fact that the core library, language syntax, and runtime specs are all part of the same version. I'm referring to the fact that Hotspot specific behaviors and adjustments are also branded as being part of the platform release.
Like there's no Java 27 platform spec that says that G1 is the default garbage collector. That would of course be an absurd platform spec change. But that is still somehow a "feature" of the Java 27 release according to Oracle.
Right. There's a "Java SE" (platorm spec) version, and a JDK version that corresponds to it, but not everything in the JDK affects or is dictated by the spec.
BTW, Java is developed "code first", which means that we first work on the implementation in OpenJDK, and then extract the relevant spec changes from it.
> But that is still somehow a "feature" of the Java 27 release according to Oracle.
It's a feature of the OpenJDK JDK, which is, indeed, the Java implementation done by Oracle (with contributions from others). The language is very careful, as you can see in the announcement: "JDK 27, the reference implementation of Java 27". The Java SE 27 spec is here: https://www.jcp.org/en/jsr/detail?id=402
I wish there was a canonical write up on the governance of "java" and its history, it has changed a lot over the years (not just once I guess) and has a lot of fine prints. I find it hard to understand the hidden reasons and behind-the-scenes conflicts/compromises. There could probably be a whole book about this I guess.
One of the more prolific opensource projects, but apart from the JEP process not very open access (which is a fair choice the contributor('s employer) can make).
You’re only counting JEPs, which are only for more involved features. There are lots of changes to the JDK apis that are used by other runtimes. See, for instance: https://javaalmanac.io/jdk/27/apidiff/26/.
Admittedly, the terminology here is almost designed to be maximally confusing, and I’ve never read a good post that laid out how everything relates.
There are also bug-fixes and performance improvements that are not going to show on the page I linked.
I do think it’s plausible this is a smaller release. Not that this was the real point of the discussion, but I think it’s still just a good idea to have more than one release a year. It keeps things moving smoothly, and lowers the cost of missing a release, which has beneficial effects.
I started programming when Java 6 was relatively new. Back then it was about 3-4 years in between releases. Although I don’t write much Java any more, I’m happy to see changes shipping more frequently now.
There's not really a second C# runtime. Java has several, some based on the Openjdk, but a few that are completely new like OpenJ9 and Graal.
The closest C# has is mono.
This sort of thing is bound to happen with that situation. Heck, it happens with C++ whenever a new C++ version comes out. Some C++11 features took years to make their way into all the compilers.
Graal is based on OpenJDK. OpenJ9 while using a separate JVM and JIT leverage the openjdk class path as well as the build environment and various other things.
I don’t think there’s a single alternate implementation that doesn’t leverage a good chunk of openjdk somehow
For the simple reason that class files with JVM bytecode are the standardized intermediate representation. Therefore, duplicating the frontend is wasted effort.
IMHO, Dex is a historical artifact. In the past it was thought that the format provides benefits for JIT compilation because it's register based, which turned out to not be case.
Lots of "improvements" on Dalvik over J2ME was Google's marketing to sidestep Sun, speaking as ex-Nokia, coupled with the experience of Java on Symbian devices and Sony Ericson.
All these years afterwards it quite clear that there is just similar fragmentation, and implementation differences between all OEMs selling every kind of devices, and as you say the format doesn't really provide that much benefits.
What ART has going for it, are all the improvements they started on Android 7 and later, by having a mix of handwritten interpreter in Assembly, JIT compiler with cache, AOT compilation with the device on idle, and sharing of PGO metadata via the PlayStore across devices.
Ironically Windows Phone did it first, with MDIL on Windows Phone 8 followed by .NET Native on Windows Phone 10, using compilation via the Windows Store, but Microsoft fumbled the delivery.
Historically, Java had a real habit of delaying new major versions for years as features hardened. Some of those features even lost relevance before their first shipping version.
So now they have a precise release cadence that features can fall into. If it is a large feature, it better get worked in incrementally (via feature previews) because it is unlikely to be able to land completely within the release window.
One could pessimistically say the faster release cadence partially serves to provide more opportunities for extended support revenue, though.
>Starcraft 2 was over 6 million sales before its final expansion even came out.
GTA 6 preorders beat that in like a week and the game isn't even out and no gameplay footage was even show.
>That seems like the obvious player base for a Starcraft 3
A lot of that player based has aged out of the game or will stick to playing SC2 instead of spending 80-100$ on buying the same game over again. RTS have reached diminishing returns. There's not much more you can add to SC2 to improve it and convince people to spend on buying a new game. SC2 is feature complete.
> GTA 6 preorders beat that in like a week and the game isn't even out and no gameplay footage was even show.
Really? That's going to be your measuring stick? So anything that isn't as successful as GTA 6 is a failure that shouldn't ever exist again? In fact any genre that isn't as successful as GTA 6 should just be wholesale cancelled?
A game is successful if it makes a profit. Other games making more profit doesn't suddenly make them failures. This isn't a zero-sum game.
> A lot of that player based has aged out of the game
What does this even mean? Gamers don't "age out". We're long past the era of pretending Nintendo is a children's toy...
I don't really get why people just assume RTS means it's going to fail? Like what major RTS games have come out since Starcraft 2 (which was not a critical or commercial flop) that resulted in cementing the genre as being dead & guaranteed to be a commercial failure? Starcraft 2 and it's 2 expansions all broke 1 million sales in less than 24 hours. SC2 was at 6 million sales after 2 years. Yet we're all supposed to just take it as obvious that a SC3 would be a commercial flop? Why the fuck should we assume that?
Meanwhile how many AAA hero shooters and extraction shooters have we watched get released and been massive commercial flops? Yet we don't consider those to be dead genres?
why not just configure Windows to mirror the displays? That seems a lot cheaper and more flexible than pass through. And you wouldn't need to worry about matching resolutions and refresh rates
In that case I’d need a 1080 physical display on the machine mirrored to the KVM. For the type of stuff I’m doing that’s a bad use of monitor / desk real estate.
it doesn't seem like Windows makes it easy, but it's not really required that mirror'd displays must have the same resolution. Sure can throw fancier and more powerful hardware at it, but this is something software could rather easily do
Otherwise GPUs typically do context "pre-emption" by basically being cooperative and just injecting yield statements in the command queue or on things like tile boundaries for tile based renderers. So the smallest chunk of work they can yield between ends up actually being quite large, and with a full user-supplied program in the middle
Well this is easy to detect and kind of intentionally so, but the broader issue is quite a bit harder. Replace "infinite loop" with some very difficult program that simply takes 30+ seconds to finish and you're back to the same problem.
It doesn't even need to be computationally difficult, you can also slam the memory bus with "far away" fetches that are randomly distributed, ensuring each fetch doesn't share a cache line with any surrounding fetches. There are popular UX effects with basically this workload, even, that's a naive implementation of a large radius gaussian blur basically...
Reporters who only capture pictures on an iPhone and not a "real" camera, and who also never need to edit the photo to crop off or obscure identifying information, innocent bystanders/victims, gory violence or nudity, etc...
The problem is real, but this solution seems to not really solve it in any practical sense.
Reporters who only capture pictures on an iPhone and not a "real" camera, and who also never need to edit the photo to crop off or obscure identifying information, innocent bystanders/victims, gory violence or nudity, etc...
So, 90% of photojournalism outside of the major cities, then.
You want to do all that, then still can prove the picture is authentic. The editing history show what had been changed compare to the previous version, from the color adjustment to blur areas... it's not about preventing editing, it's about proving the authenticity when needed.
> The editing history show what had been changed compare to the previous version, from the color adjustment to blur areas...
That's not a thing. Straight from Apple:
"When a photo is taken in the new Reference mode, the camera captures signed sensor data that Private Cloud Compute develops into an unalterable reference image. Reference images can be viewed in the Photos app alongside the main image"
So this only helps prove anything if you can share the original, unedited image. You can share it alongside an edited one, but you must also be comfortable sharing the unedited original if you want to prove you own an iPhone 18 Pro. Er, I mean prove it's "authentic"
Now I think C2PA had allowances for what you're talking about, but that also ended up resulting in it being easier to break.
You don't need to share the original image with everyone, just like how journalists don't share their audio recordings from interviews with everyone. You share with an editor. Or a court.
Yes, which is why this doesn't really do much. Readers still have to primarily rely on trust for whether or not they believe the news and who is reporting it.
Pixel Fold has had it for a few years, it's called "tabletop mode". Beyond just the keyboard "mini laptop" style, different apps also have special UIs for it, too. Like youtube puts playback controls on it.
reply