That's standard in the games industry as well. Plus many others like no rtti, no huge dependencies like boost, no smart pointers, generally avoid ctors / dtors, etc.
I also enjoy my morning ritual of preparing the grinds and brewing a fresh pot. But I'll be honest, at the end of the day it doesn't really matter where I get it -- brunch at a nice restaurant, Starbucks, McDonalds, a cheap hotel buffet, lukewarm from a flight attendant ... as long as I get it. Sounds healthy, right?! ;)
At the very least, modern cars are much heavier and ultimately mass wins. For example, a 2005 Honda CRV weights 3400 lbs while a 2025 is 3900 lbs.
Plus they have tons more auxiliary safety features like lane departure warning, forward collision warning, blind spot detection, better visibility, etc. And they are roomier, have more power, get better gas mileage, and have backup cameras and Apple CarPlay!
A dozen eggs is up over 350%, but a 6-pack of Budweiser is only up 60ish% since 2000. So you know, it all balances out. Maybe drink a few extra cans of Bud with your next meal.
I was really excited about the idea of a modern statically typed language with green threads ala Erlang / BEAM. I lost interest when Rust moved away from that direction and became focused on zero-cost abstractions instead.
I’m not OP, but IMO go cannot be called a “modern language”. The go ideology seems to be that such basic “modern” ideas as sum types are just pointless intellectual games, akin to Haskell type astronaut behavior, or that they’re too advanced for most programmers to understand.
Not parent, but I think there is certainly space for a Typescript-esque language for Go. If the parent commenter was looking for a static type system, the implication is they would probably want a more functional language inspired type theory. Go’s runtime is not the BEAM, but it is usable for many of the tasks Erlang is pitched for.
I can readily see a Haskell inspired System F derivative the compiles down to valid Go, or a more flexible, special cases type theory that encompasses all of Go like Ts->Js. Likely a ‘transpiler’, I hate that term, to Go implemented in Go and you have a self-contained language with more advanced type features and Go’s green thread runtime.
I applaud the work that’s been done on Dingo (I also really like the name and inspiration, i.e. Dingo is a language that broke free from Google’s control). However, I don’t think Dingo is Typescript for Go, because it is too limited in scope.
Dingo adds Sum types and associated pattern matching elimination thereof, it adds a ‘?’ syntax for propagation of Optional types, and exhaustiveness checking for those pattern matching statements. There is no type system expansion, or syntax alterations that would make the Typescript comparison more appropriate.
I think Dingo probably addresses a lot of the common complaints with Go, but it is not nearly as far from Go as a baseline as I would assume a language positioned between Go and Rust.
As a person who actively uses Elixir, Rust and Go (in that priority order) to me there is a maddening gap between Rust and Go.
While Go has the goroutines and they have made concurrent and parallel programming accessible to many, they are a rather raw material that's easy to abuse and use wrongly (leaks, deadlocks, and don't even get me started on writing to a closed channel -- instant panic and program abort).
Rust async is also too raw but in another way: gets wordy / verbose and too implementation-oriented way too quickly -- I never wanted to care about Pin<Box<???>> or what must this or that Future implement in order to be eligible for usage in `select` and whatnot. Those things should have been hidden behind a DSL much like `select` and `async` itself are a DSL / macros / state-machines of sorts. Rust's async just seems... I don't know... unfinished. Zero disrespect is intended (and I do recognize you by your username), I love Rust and I never pass an opportunity to whip up an internal CLI tool with it and my most consulting engagements have resulted in teams highly appreciating such tools, but I can't shake the feeling that Rust's async could be more... polished.
Both Rust's and Go's async mechanics leave me with the impression that somebody thought that they gave the devs enough LEGO building blocks and called it a day. I don't judge. I understand. But as a user of the languages I also have the right to find their async facilities less than ideal.
Erlang / Elixir / Gleam / LFE on the other hand stand on a runtime that has exhaustively analyzed a ton of async scenarios and cover them very well (minus stuff like filesystem operations being centralized through a singleton runtime agent, something you can opt out of, thankfully).
So I'd say both Rust and Go are ripe for either disruption or courageous backwards-incompatible modifications. Their async implementations simply did not go far enough.
And don't get me wrong, I love both and do my best to use them regularly. But it's a sad reality that their "unfinishedness" led to a plethora of footguns that became a badge of honor if you get to know most or all of them, as in: know how to avoid them. Which I don't know why many see as a desired state of affairs. Job security, I suppose.
I would kill for something as terse and explicit as Go but as super strict as Rust but that also has 100% finished async semantics, and has a faster compiler than Rust but optimizing as aggressively as it as well. Yeah, I know: what color do I like my dragon?
All that being said, Rust is the closest we have to a perfect language currently. And that's kind of sad because it has a few things that it really needs to fix if it wants to keep gaining mind-share. I personally find myself reluctant trying to build a career with it. But I'll not digress further.
I bought a Dell XPS M1210 laptop in 2007. About a year later the laptop died. From what I could gather, the soldering on the NVIDIA 7400 graphics card had failed. Some people were apparently able to reflow it but I had no such luck.
In my opinion Dell laptops have never been good. But I never bought another one since that happened, so maybe I've missed out.
Had the same thing with an HP DV7 (IIRC) and nvidia 7600go. Baked it in the oven, and it booted up a handful more times, but ultimately died long before it should have. And I LOVED the more squarish form factor it had.. I got some $$ back from a credit card company (it died before 2 years were up), but I could only find 16:9 replacements..
What are the odds it's a forgery? Couldn't find any details on their grading method and how it was "positively identified to originate from the first print run of the issue" [0].
For how they could tell it was from the first run, it says in the article you referenced:
> For decades, Allen says, nobody knew of a way to distinguish which copies came from that initial run. Then a grader noticed a key difference in a small in-house promotional spot advertising the upcoming Action Comics No. 14. In the first run, those ads included text reading “On sale June 2nd.” Subsequent print runs had updated it to “Now on sale.”
> Multiple Supreme Courts have also made it clear several times that they believe you do not have a right to privacy in public spaces. So all the traffic camera databases do is automate and make easier something that is currently definitively legal.
I propose we streamline things and augment your cars license plate with a placard stating:
First and Last Name
Address and Phone Number
Drivers license number
Age and net worth
Prior convictions
Maybe there's a few more factoids we could add on there? I'd really like to know who is parked next to me. I mean, you're in public and have no expectation of privacy afterall.
I love how programming discussions du jour have basically devolved into "really? my socks definitely smell better after using 2 scoops of last month's soap. what spin cycle are you using?"
reply