debug-desperado

Maybe it is. They're definitely reducing footprint for satellite offices: https://www.statesman.com/story/business/real-estate/2022/11...

Instruments of Destruction, still in Early Access: https://store.steampowered.com/app/1428100/Instruments_of_De...

I seem to get unpredictable, if infrequent, hard crashing when playing the PhyX-enabled game Control unless I set the Nvidia control panel option to run the physics on the CPU. System event viewer pointed to a failed assertion in the Nvidia driver. I'm not 100% sure this has fixed the problem but I haven't seen a crash since the change.

Since gfx benchmarking is stable and MemTest86 never found anything, the only other culprit would be power transients. I'm using a relatively modest 200 watt RTX 3060 ti so I hope it wouldn't be that.

Just wanted to bring this up because I'm not the only one that has experienced this, it was a recommendation from a Steam discussion. And by hard system crash I mean full system reboot.

I think at the end of the day it was about forcing CSP-style concurrency on the majority of Google services. You can make a pretty good argument that CS programs don't do a great job at teaching multithreaded programming (even though it's pretty dang straightforward on the JVM and CLR). Race conditions are often painful to track down. Exceptions are also tough to get right, and many services require several hardening updates because of missing catch blocks or overly thoughtless "catch and log" behavior. Multi-return, despite the verbosity, may be a win on the operations side here.

Like you, I wish Google was more ambitious with their language design though. Honestly I'd rather stick to the JVM, especially with Virtual Threads now in preview.

When you add in the fact that it’s the only Intel desktop chip that supports AVX-512, Rocket Lake is pretty uniquely situated.

The overclocking crowd may have turned up their nose (to be fair Comet Lake can have excellent memory latency and speed with some tweaking), but folks who like to tinker with software and not worry about which thread scheduler the OS is running are well served by Rocket Lake.

Jetbrains products have started prompting if you'd like to open a new project in "safe" mode that disables the build tooling until you've had time to evaluate the project.

So at least some IDEs are more cautious about this these days.

Seems like we will need this sooner rather than later too with 500hz screens on the horizon.

Strange since the new frame interpolation in DLSS 3 might bring us much closer to smooth motion on sample-and-hold displays.

If you have a small team of engineers and you need the added productivity of a more ergonomic language, then go ahead with Kotlin. In particular it's good for "lite-functional" style with OO mixed in, and your engineers get to keep all the familiarity they have with the JVM ecosystem.

It's not some panacea though, and at the end of the day Java is the system language of the JVM. New VM features are not built to cater to the guest languages. In the case of virtual threads we have a directly competing "async" solution to Kotlin coroutines. So you may see further ecosystem split between libraries catering to Android and those catering to backend work.

This is the correct answer to tackle power draw. Use Vsync/Adaptive Sync for fixed refresh monitors, or FreeSync/GSync for variable refresh monitors.

For variable refresh rate monitors, it's best to use framerate limiters as well: either in-game or in the Nvidia control panel. Set the cap at least a few fps lower than your monitor's max refresh rate. Even better, aim for 90-100 fps cap, beyond which diminishing returns kick in and power bills continue to creep up.

"I like Odin" - me too, just discovered Odin last week. The syntax is just about as perfect as a procedural language can get.

I don't do C professionally and really only used for standard uni classes for algos, data structures, system programming, OS, etc. But seeing Bill's streams highlighting the clarity of the Pascal pointer syntax has been eye opening. A C spiral seems so utterly unnecessary compared to how simple it is to read Odin left-to-right. It's good to have a physicist take on a programming language. Thanks for the hard work!

Wow, that's the exact opposite advice I got doing an internship for an oil company a decade ago. They emphasized shorter (and hidden + animated bullet) points so that audience has to listen and engage with you, the presenter. Otherwise they just read your slides and put their brain in park.

I'd take the oil companies suggestions to heart, not Oracle's.

Everything in the feature-list for Gorm is bog-standard for C# and Java ORMs. Do they support any special query languages comparable to OData, LINQ, or JPA?

Not wanting to get in a debate on whether you should use an ORM, but I just don't see anything really special about Gorm that makes the other frameworks "ancient".

When I look at this page: https://gorm.io/docs/advanced_query.html I see the same exact crap that makes me wary of JPA Criteria API.

"I laugh every time Google's multibillion dollar AI shows me the same ads ..."

So much this! I see 10 Google Fiber ads a day on YouTube even though I'm on their service and have an IP address they've assigned, lol.

I wouldn't. Sony has a track record of fostering creative excellence with their studio purchases. Microsoft can barely get their studios to release anything within a reasonable timeframe, and most releases tend to be good-but-not-great. Something about the Redmond management just doesn't deliver here despite the exorbitant budgets.

Of course, my perspective is a bit different because I own both consoles.

Probably a lost cause at this point since most GUI toolsets are too object-oriented to comfortably wrap and call with Rust. Do a web view with Tauri instead.

Seems like the feedback would need to be reviewable in a "skip level" fashion for that to work.

I waited over two years after signup, but they finally delivered in 2021.

Yeah between 900 mbps hard wired and 600 mbps over wifi, it actually might be possible to use all of your connection with 2+ machines in use.

Good old cat5e can actually do 2.5 gbps these days with newer network cards (Intel Z590 and Z690 mobos) and switches (kinda pricey though).

That's my point, we don't have much more than that. Even a 2-arg function is missing. You can supplement with something like Vavr or just write your own, but even then it's not pleasant to read "Function3<A, B, C, D>".

Typescript, Kotlin, and Scala all do this way better. Here's an example from Kotlin (it's an extension function, but focus on the combiner lambda):

  fun <T, R> Collection<T>.fold(
    initial: R,
    combine: (acc: R, nextElement: T) -> R
  ): R {
    ....
  }

“going to war against its own key staff members”

What happened here?

"Static generic types are lies" yes, and it doesn't matter that much. You got the safety at compile time and if you didn't do an unsafe cast then you preserved it.

The issue with primitive types and boxing is certainly noted. Hopefully Valhalla will address it and more.

The problem with reified generics is that the same variance model must be adopted by all guest languages on the runtime. Hence you basically don't see any guest languages on the CLR, and efforts by languages such as Scala to port to the CLR failed due to problems interoping with C#. I think one of the JVM engineers "pron" has discussed this multiple times.

C# interfaces with methods, properties, and events is just so nice from a readability standpoint.

I know we like to pretend that Java now has first-class functions since Java 8, but without easier to use functional signatures they're just too much of a chore. Who the heck wants to write a new interface in a separate file to do this.

I'm grateful for the JVM and think it's probably better than the CLR for targeting a high level language (as evidenced by the continued existence of Scala, Kotlin, and Groovy). But Java, even post-Loom and post-Valhalla, will never be the promised land for quick-to-read-and-grok code.

Agreed - I hoped my parenthetical would get that across but it's worth making it clear that Carmack isn't against different programming languages. He rather feels that being forced to use multiple languages on the same project brings extra pain.

The thing is, he also complains about a time at Oculus where he needed C++ experts to right the ship but Facebook didn't have the talent base for it. Since he says 99% of code should be written in GC'ed languages, it shouldn't be surprising there's a talent vacuum in C++ among modern programmers.

Here' the flamewar money quote:

(in reference to the pain of using multiple languages on a project) "At Meta we have a lot of projects that use React frameworks, you've got javascript here, and then you have C++ for real work, and you may have Java interfacing with some other part of the Android system, and those are all kinda horrible things."

Of course just a few minutes later Carmack says that garbage collection is unequivocally a good thing for most programs, so C++ pros shouldn't puff up their chests too much!

That’s what I was getting at. I hope they get some real feedback from Nvidia, AMD, Intel, Qualcomm, etc before making something that is really only useful at Google.

Not a C++ programmer, but I'd like to ask: Are Carbon's goals for interop here sufficient for most libraries and frameworks, or will bridge code be required in most cases?

I see this about exceptions, for instance:

"Carbon may not provide seamless interoperability support for C++ exceptions. For example, translating C++ exceptions to or from Carbon errors might require annotations or bridge code, and those translations may have some performance overhead or lose information. Furthermore, if Carbon code calls a C++ function without suitable annotations or bridging, and that function exits with an exception, the program might terminate."

https://github.com/carbon-language/carbon-lang/blob/trunk/do...

You hit the out-of-pocket maximum for the year and then no longer pay anything on the bills.

Most upper middle class jobs offer different plans with different maximums and monthly payments.

Seems cool for tweaking layout and styles on the fly, thanks for pointing this out.

I think many devs underestimate how important the JS world's Hot Module Replacement has become for frontend dev velocity. Live reload just makes visual work so much better.

Of course we all know the scourge that is Electron apps. Maybe now that native web view is becoming more available across desktop OS's we will see apps move to leaner frameworks. Tauri (which hit 1.0 yesterday) allows native system access, notifications, app tray, auto updates, polyglot backend via sidecars, and HTML/CSS/JS/TS frontend. Not native controls that many of us love, but much better than where we're at now.

Tauri just hit 1.0 yesterday too. Looking forward to this saner future for packaged up web applications!

Neat trivia: Intel recently backported a microarchitecture to a bigger node to cope with fab issues at the time. The 11th gen "Rocket Lake" parts are a 14nm backport of the 10nm Ice Lake processors.

From what I understand, doing so was no small effort and is considered a strong triumph for the team that accomplished it.