miffy900

This is still some code, as opposed to no code. It does seem to model everything in the research paper.

Aside from the original research paper needing to be included in the repo, it definitely does not need anything more than what's already there. It all builds and compiles without errors, only 2 warnings for the library proper and 6 warnings for the test project. Oh and it comes with a unit testing project: 59 tests written that covers about 73% of the library code. Only 2 tests failed.

Even having a unit testing library means it beats out like 50% of all repos you see on GitHub.

Anyone here arguing that we should just let Intel fail in the market needs to understand that Intel is struggling right now partly because Asian nations like South Korea and Taiwan have for years subsidized their own chip making companies because they knew that in the long term, it was going to be an important strategic industry that would eventually be worth the effort and trouble. Now look where we are. Their long term strategy has paid off. Only TSMC is at the cutting edge, and Samsung is a fairly distant, but still reasonably close, secondary player.

Maybe there are better ways to prop up Intel besides the government taking a stake, but losing Intel would be a huge blow to American manufacturing interests. There's been a failure of strategic vision, both at Intel and in the American government. I think as a short term measure, taking a stake isn't the worst thing the government could do at this time.

Also to go off on a tangent a bit: this is one of the benefits of having a Trump-like character as President; he's clearly not beholden to any ideology and is extremely flexible when it comes to making policy decisions, even when a certain policy might be more at home with the opposing party or side of politics.

So, the one bad thing that sticks out about what Trump is doing now, is that he's adding more conditions to the money that has already been legally disbursed by Congress. Under the CHIPS act, Intel is already eligible to receive the money; Trump is illegally adding more conditions for Intel to receive the money, after the fact. To do this legally, the act needs to be amended. As simple as that. Anything more than that is illegal.

> I’m saying that in actuality, you won’t be able to see any damage if somebody drank a beer once, because there isn’t any.

Which, again, is not a claim that was ever made in the article. You are literally making things up and arguing against your own made up arguments, and framing it as if the article originally made them. No where in the article does it say that.

It's also weird that you would have a such a vehement reaction towards the quote

> "recent research indicating that any level of alcohol consumption may negatively affect health"

to the point of making things up. How on earth is such a statement even at all remotely controversial?

Nope. On closer inspection, it's a tablet resting on a stand; it's not mounted with a VESA clamp or arm like most monitors would be. You can see the USB charging cable is plugged into the side of the tablet as well. When you compare it to the keyboard and headphones next to it, it must be about 11-13 inches in size, so it's unlikely to hold a mini PC on the back as it wouldn't be heavy enough to prevent toppling over. The stand would be bigger too if it could hold a mini PC.

Actually it wasn't too long ago, in the early-2010's, that Microsoft was promoting SharePoint for internet sites; I think at one point some Europoean car manufacturer (BMW? Ferrari?) had their global marketing site on SharePoint. Of course that didn't last long, as Microsoft licensed it at a crazy price ($40k per site or something like that).

The article itself is evidence. There are many more links in it to other stories that report on basically the same or similar incidents. There are also several names in the article itself that you can research or probe on your own to tell if it's coming from a trustworthy source.

Consider also the author: it's written by an actual journalist/editor with a large body of pre-existing work in the field, and many of the claims written are backed up by quotes from a named source. It's not like they're writing all this and hiding it behind the weasel phrase 'according to a source close to the matter'.

The register too is actually UK founded, so it's not even American.

Your reaction is just so typical of people nowadays - just assume it's all 'made up' without any effort in debunking or picking apart any specific claims.

True, but at that point it's still not too late to prevent paying money that will ultimately end up in the NK government hands.

> Unlikely. Frosted glass blur was introduced almost twelve years ago in iOS 7, and was supported all the way down to the iPhone 4. Many apps like control center have used a full screen blur without any performance issues for a long time.

"Without any performance issues"? Entirely false - reviews at the time noted iOS 7 dramatically reduced battery life - all across the board for Apple devices, even for the then latest iPhone 5S and 5c (https://arstechnica.com/gadgets/2013/09/ios-7-thoroughly-rev...).

The abuse of transparency/translucency in the UI was the primary reason - you could go to Accessibility settings and disable animations + transparency/translucency and get notable increases in both runtime speed of the OS UI and battery life.

I tried seeing how it ranks on the 2025 tech empower benchmarks: https://www.techempower.com/benchmarks/#section=data-r23&l=v...

And up against C#, Go and C++, Vapor could not make the top 70.

Even just compare Swift vs PHP and its a really poor showing for vapor: https://www.techempower.com/benchmarks/#section=data-r23&l=v...

To be fair, LLVM wasn't an Apple-initiated project, but one Apple noticed and decided to adopt later on (they hired Chris Latner in 2005; LLVM began in 2000, and had its first public stable release in 2003).

Unlike Swift, there was never a period of time where LLVM only worked exclusively on Apples own OS's or hardware. From the get go, you could run early versions of LLVM on Windows. In Swift's case, Linux support came in 2016, 1.5 years after Swift's initial release in 2014, then Windows support came 6 years later in v5 (2020).

If Apple didn't want to let Swift suffer the reputation of being an Apple-only language they should've invested more into cross platform support much earlier on. Yes, today Apple and everyone else can say, 'Swift is cross-platform', but dig deeper into the history of Swift and its clear that from the get go, Apple treated non-Apple OS support as an afterthought.

Yes this exactly. People are also conveniently ignoring or forgetting that Apple kept changing the ABI for Swift binaries - it wasn't until 'v5' did they lock it down. Objective-C is 30+ years old and only once had this issue with the ObjC 2.0 release. Really, Swift v5 was the real v1.0 release because it was at that version Swift was truly ready for primetime.

Well kinda; even in a tracing GC language like C# you have things like WeakEventManager (https://learn.microsoft.com/en-us/dotnet/api/system.windows....) to prevent memory leaks when using callbacks as event handlers. It is definitely not exclusive to ref counted languages.

In C#, these aren't the exact same as a reference cycle, but the end result is the same, a memory leak: https://learn.microsoft.com/en-us/dotnet/desktop/wpf/events/...

I'm going to call it now: Swift on the backend is pointless for everyone but Apple, and trying to make it takeoff as a backend service language is as pointless as porting Xcode cross platform and trying to lure non-Apple devs into using it over say VSCode, any JetBrains IDE or Visual Studio.

The choices that already serve the market are just too numerous and the existing tooling is already far greater in features, functionality and capability than anything that Apple can provide. What's funny is that they actually have the money to dedicate resources to this space to compete with C#, Java, go or Rust, but they're not going to because it's just too far afield of their core business. Any backend service written in Swift is not going to be running on a Mac in the cloud, and probably won't be serving just iPhone/iPad clients exclusively, so why bother when we know Apple leadership will treat it as an afterthought.

If it does takeoff, I'm betting it will be because the open source community provides a solution, not Apple and even then it will be in a tiny niche. Indeed, this entire project is enabled by Vapor, an open source Swift project that I'm guessing the team only chose because Vapor as a project finally reached the requisite level of maturity for what they wanted. It's not like Apple went out on their own and built their own web framework in Swift, like Microsoft does with C# and ASP.NET. All of this makes me feel even more skeptical about Swift on the backend. Apple won't do anything specifically to give Swift a legup in the backend space, beyond the basics, like porting Swift to linux, but will avail themselves of open source stuff that other people built.

Many of their SaaS offerings are, but many infrastructure offerings are running Windows Server underneath. Rent out any Azure VM, and regardless of guest OS, it's using Hyper-v underneath as the hypervisor.

Or it could be Canva, which is Australia-based.

From the wikipedia article:

> Curtis Yarvin began constructing the basis of the ideology in the late 2000

Ah yes of course this dude is involved. The more I read about Curtis Y, the more I believe he suffers from some sort of undiagnosed mental illness.

That's probably overstating it; it is definitely true that his redesign of iOS 7 (2013) was truly awful - he really should not have been anywhere near software, and was able to take advantage of Scott Forstall's then bad reputation and recent dismissal to insert himself in an area he had no real qualifications for. Before that, he was purely a hardware guy and it was clear from the outset he was in over his head with software. Apparently he had no idea what 'HCI' (human computer interaction) even meant; wasn't even familiar with the abbreviation itself. Now with the benefit of hindsight, we can judge that iOS 7 had some truly terrible design decisions that ended up making the iPhone much harder to use (very light, unbolded text everywhere, removal of borders on everything especially buttons, over use of color tints on text).

What I always found crazy was that Ive seemed to just take design ideas from then Windows 8 and Windows Phone more than trying to create his own thing. It showed that he had no original ideas of his own; even just iteratively improving on iOS 6 would've been better.

On Mac hardware, he definitely needed some sort of editor to stay his hand post Jobs. The era of crappy butterfly Macbook keyboards is still something I remember that was clearly his responsibility, driven by obsession on thinness and it seemed for a while that Apple was in denial about the issue.

Still, the Apple Watch is a definite hit for Apple now and it's clearly his baby, so his legacy isn't all bad.

I was able to open F12 dev tools on desktop on their website and all content is being rendered inside a <canvas> element, which explains why you can't copy and paste.

> allowing you to Code Once, Run Everywhere

May I suggest that everyone just drop this whole 'develop/program it once, run it everywhere' slogan that just gets repeated endlessly when people try to promote their new platform/framework/library or whatever? I've never seen it work out that way in practice. Never. All individual platforms have their own features, unique quirks and distinct, platform specific bugs and trying to abstract over all the platform specific stuff means you end up with either low-quality, or low-feature implementation that comes close to being usable, but still never quite USEFUL.

Even the web browser, the only one that ever came close to fulfilling that promise, still requires fixing or accounting for browser-specific implementation bugs or quirks or non-standard feature additions/omissions. The closest you can get is just ignore Firefox, Safari and just target Chromium-based browsers, OR just use a subset of the latest web standards.

Considering how scrolling itself is entirely broken on the cogentcore website itself (I'm on desktop Chrome and my mousewheel and 3rd button scrolling doesn't work), it's not inspiring that they couldn't get something basic like scrolling to work. Is it not possible to just delegate scrolling behaviour to the browser?

Rewriting those commits would effectively allow them to erase their mistake, which kind of lets Microsoft off the hook in a way.

This is probably exactly what happened. I bet he used Chrome as well. It doesn't really help that Google Chrome keeps history basically forever (on the order of months), even without signing into a Google Account.

I don't think C# would've been a good fit for flutter in its early days, but definitely Flutter should no longer be tied to a single language like Dart. I think you should definitely consider stronger cross-language support.

It's much much more complicated than that. Sun refused to add many language features that Microsoft (then a cautious but also genuine user of Java) wanted. Such as refusal to add delegates/closures:

https://benhutchison.wordpress.com/2009/02/14/suns-rejection... https://stackoverflow.com/questions/1973579/why-doesnt-java-...

J++, which was Microsoft's Java implementation in the 90's added a few language extensions that were clearly not Sun-approved, but driven by internal engineering feedback at MS. C# having struct and class keywords, allowing you to define your own value types, is clearly a result of that missing in Java, which still in 2025 has no such equivalent yet.

Also Java's then native code interop solution, JNI, was and still remains complete garbage, and it's flaws were a huge guide for Microsoft when they deveoped .NET and it's native interop equivalent, PI (platform invoke).

Thankfully, Java now have FFM [foreign function and memory APIs](https://docs.oracle.com/en/java/javase/21/core/foreign-funct...) APIs (and also JNA which is community driven), which are much better than JNI.

> First things first, let’s establish some ground. Go is a good language for writing servers, but Go is not a language for writing servers. Go is a general purpose programming language, just like C, C++, Java or Python

Really? Even years later in 2025, this never ended up being true. Unless your definition of 'general purpose' specifically excludes anything UI-related, like on desktop, web or mobile, or AI-related.

I know it's written in 2017, but reading it now in 2025 and seeing the author comparing it to Python of all languages in the context of it's supposed 'general purpose'ness is just laughable. Even Flutter doesn't support go. granted, that seems like a very deliberate decision to justify Dart's existence.

Can you elaborate on why it was so bad?

The Lumia series of phones had solid hardware but Windows Phone OS was crap, so the product line itself could never be competitive enough; I mean Nokia singlehandedly died at the braindead decision to go with Windows Phone and not Android. So if you're talking about phones, then I'd say it was Windows Phone OS that was the biggest flop, not the hardware.

It's entirely possible the disk images were just duplicated multiple times to get to 30M.

> "but it feels like a lost art to build effective web applications using the core JS language."

Yeah it is getting lost, more and more lost each year - you know why? The core JS language is bad. Note how the author uses the word 'core' instead of what they really mean: 'subset'. Use a subset or a small portion of the language, because if you use the whole breadth of language features, you will litter your application with so many landmines that you will eventually scrap it and re-write due to how awful most of the 'features' in JS are. Even using a subset you have no choice to resort to syntactical verbosity to get around bad language design, like === over ==, or const & let over var.

I wonder what the ultimate point of posts like these are; it's like someone trying to light a fire during a flood; and to what end? To pointlessly champion a bygone era of when people didn't know better? Let's be clear here, JS is popular because it is the only language shipped by default in browsers, since 1996. That's it; it's not popular because it's good; we're not using it in 2024 because it won out in a contest of merit. It's design phase was rushed and even its name betrays how stupidly conceived it was; 'JavaScript' - as if superficial association with an already trendy tech during the 90's was somehow enough to paper over it's obvious flaws as a language. Just laughable.

Seriously, it's 2024, we know better now - use TypeScript. It's actually kind of amazing how Microsoft released TypeScript only in 2012 and not years earlier.

I think their study is flawed as it ignores what I think is the biggest reason: and that's the courts, or specifically judges.

There's been centuries of legal disputes, in both civil and criminal cases, and judges have over time through their rulings have influenced what is the acceptable wording to enforce whatever it is legislators intended for a particular law. When judges render a verdict, it becomes case law, and although that itself is regarded as part of the law, where there's ambiguity, over time, legislators have been prone to abrogate laws with more exact wording.

This is reflected in the tendency for judges to fall in groups that favour one way of interpretation over another, like Intentionalism, Purposivism, Textualism etc. The fact that statutory construction is something that is almost exclusively driven by judges themselves seems also pretty important when studying the language of the law and it's kind of absurd they ignore it in this study.