I'm bit puzzled, isn't VRR more for low powered hardware to consume less battery (handhelds like steam deck)? How does it fit hardware that is constantly connected to power?
Variable refresh rate is nice when your refresh rate doesn't match your output. Especially when you're getting into higher refresh rates. So if your display is running at 120hz, but you're only outputting 100hz: you cannot fit 100 frames evenly into 120 frames. 1/6 of your frames will have to be repeats of other frames, and in an inconsistent manner. Usually called judder.
Most TVs will not let you set the refresh rate to 100hz. Even if my computer could run a game at 100hz, without VRR, my choices are either lots of judder, or lowering it to 60hz. That's a wide range of possible refresh rates you're missing out on.
V-Sync and console games will do this too at 60hz. If you can't reach 60hz, cap the game at 30hz to prevent judder that would come from anything in between 31-59. The Steam Deck actually does not support VRR. Instead the actual display driver does support anything from 40-60hz.
Go was originally designed to make life easier for googlers and make software engineering easy. In 2025, I can attest to the fact that Go is simple. Go is easy. Whether you can accomplish what you want in Go is another story. However, Go has a very basic structure and easy flow. Complexity comes from not understanding the go philosophy.
Yes - Go is both a simpler language than Java which does not lend itself to (nor does the ecosystem tolerate) the kind of architectural malpractice that enterprise Java typically becomes.
Its type system is miles better than Python and it has some basic stuff Python doesn't have like block scope. Functional programming is also intentionally kind of a pain in Python with the limited lambdas.
If TypeScript had the awesome python stdlib and the Numpy/ML ecosystem I would use it over Python in a heartbeat.
Typescript also has significantly better performance. This is largely thanks to the browser wars funnelling an insane amount of engineering effort toward JavaScript engines over the last couple decades. Nodejs runs v8, which is the JavaScript engine used by chrome. And Bun uses JSC, written for safari.
For IO bound tasks, it also helps that JavaScript has a much simpler threading model. And it ships an event based IO system out of the box.
you can define a named closure in python, i do it from time to time, though it does seem to surprise others sometimes. i think maybe it's not too common.
Typescript is a really nice language even though it sits on a janky runtime. I’d love a subset of typescript that compiles to Go or something like that.
Typescript is ubiquitous in web, and there are some amazing new frameworks that reuse typescript types on the server and client (trpc, tanstack). It's faster (than python), has ergonomic types, and a massive community + npm ecosystem. Bun advances the state of the art for runtime performance (which anthropic just bought and use for Claude code).
Those are both valid reasons to use both languages. The "only" (whether true or not) is what the argument hinges on. It is roughly the same as saying that the only advantage of X is that it is popular, but Y is also popular and has additional advantages, therefore, Y is better than X. That is a valid argument, whether the premises are true or not.
I do not disagree but if you are going to say that "X" is only used because of "Y", maybe if you are pitching "Z" instead of "X" do not start with the "Y" :)
But it comes from Javascript and inherits its issues, and is used mostly because there is no other option on the web and that makes it popular, not its quality, but lack of options. So a closed ecosystem with just one language - Javascript, and any other languages that can be compiled to it. And Typescript is a bandaid to make sensible type system on top of Javascript, and it still leaves option open to use Javascript lack of rules.
Concurrency in JS also looks junky.
And on readability Python also wins (if we prohibit stupidities like PEP 572)
Typescript is a lot nicer than Python in many ways. Especially via Deno, and especially for scripting (imports work like people want!).
There are some things that aren't as good, e.g. Python's arbitrary precision integers are definitely nicer for scripting. And I'd say Python's list comprehension syntax is often quite nice even if it is weirdly irregular.
But overall Deno is a much better choice for ad-hoc scripting than Python.
I agree, but bigints are missing from json because the json spec defines all numbers as 64 bit floats. Any other kind of number in JSON is nonstandard.
JavaScript itself supports bigint literals just fine. Just put an ‘n’ after your number literal. Eg 0xffffffffffffffn.
There’s a whole bunch of features I wish we could go in and add to json. Like comments, binary blobs, dates and integers / bigints. It would be so much nicer to work with if it has that stuff.
Handling JSON as a basics for language? Really?
null restricted type will come with valhalla, string templates had a try, but people complained and they withdrawn them after 2 preview iterations. Not sure what issue people had with them and what issues maintainers noticed.
What do you mean by broken exception system?
Java is not a small language that you can throw features around, they have to take into consideration final goal of it and decades of development.
> Yes I agree, but it shouldn't take YEARS to ship anything. 11 years for a JSON api?! Come on.
Anything? Or maybe something that you specifically want?
It added records when I wanted them, it added streams and lambdas. I don't care for string templates (I thing those are ugly in any language).
null-restricted types would be nice but you have to understand that designing a language is not throwing every possible feature on top of it (like kotlin and resulting lack of readability it has and hard time updating to newer JDK), you have to design it, think of the possibilities, what users really want etc.
Valhalla type system results in addition of null-restricted types, as a natural evolution of the language.
> Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads.
Well, frontend and backend always need to agree on every scenario, that's why I prefer to do validation on backedn and frontend to just display it and not do any validation.
That makes for some nasty debugging and unsafety. Both sides should parse both times, unless you're encountering real (not imaginary) performance issues.
As someone who's been parsing everything entering the system from 2018, I don't believe you can have performance issues by parsing the data entering the system, the only exception I can name in a decade was real time trading app where the data coming in all time was just gargantuan that parsing it all the time was impacting UX and even then there should be an argument for the backend insisting on sending whole data instead of the latest value.
Frontend and backend will always diverge and 90% of your bugs will be around that. Mitigating the divergence is the primary goal of every web framework, both backend and frontend, when you sit back and think about it.
I wonder how easy it would be to prepare a query in osm to find all such cases.
reply