In terms of demand, anecdotally-speaking I can certainly see this influencing some decisions when other circumstances permit. Many people I know are both excited for new and better games, and equally exited about running LLM/SD/etc models locally with Comfy, LM studio and the like
Hmm well I certainly inferred the same from their comment: it casts “big tech” as the victim of the government, because the latter forced as “overpriced and shitty solution”
It’s possible they’re not a capitalist and just extremely sympathetic to Apple and/or Google specifically, but that seems more of a stretch than what that commenter (to whom you’re replying) has inferred IMO
Your assumption is equally incorrect, because the poster factually did not say anything like that. You can be upset at the EU for making performative regulation without addressing "real issues" or writing the regulation well, and yet still support strong regulation. The implication that criticizing the EU is equivalent to being a "hyper-capitalist" is such an insane belief that it borders on being farcical.
Assumptions like this are what lead to political polarization. Don't do it. Read what the poster wrote, don't try to read their mind, and use your brain responding.
Reading my previous comment, anyone with decent reading comprehension can tell that I'm describing a possible interpretation. I'm clearly not assigning it as fact, as echelon is.
I can also explain exactly why echelon's interpretation is unfounded, yet you cannot make any coherent argument and are forced to resort to allusions and baseless accusations stemming from a failure to read what I wrote. Although, that's consistent with a failure to read what ralph84 wrote, too.
Every single place I’ve stayed in Europe had no shower door, and nothing to prevent the water from spilling out. Occasionally I get lucky and the floor is constructed sufficiently concave so at least the water flows into the drain
If they’re in a team similar to some I’ve worked with, engineers are barely getting comfortable with the shift away from .NET Framework (!)
There are legions of developers for whom Visual Studio on Windows is the only place they have ever been comfortable. And upgrading between versions of .NET is a point-click exercise between the various UIs (Visual Studio Installer, “Get New Components or Features”, and the NuGet package manager)
The advent of .NET Core happened to coincide with initiatives to adapt:
* toward the cloud and away from IIS and Windows Server
* toward Git and away from TFS
* toward remote CI/CD and away from “drag my files into inetpub”
* toward SPAs and away from ASP.NET XAML programming (Blazor notwithstanding)
* toward a broader toolkit where the familiarity with OSS and open specs is advantageous, and away from Visual Studio as the center of the universe (though it still arguably reigns supreme in its class of IDEs)
Coming from the Linux/Docker world before going deep in .NET, I was both resented and leaned on heavily for these teams’ transitions. Most of my teammates had never read the contents of their .csproj or .sln files, or run a build command from a terminal and read its log output. They were annoyed by my requests to do so when helping them troubleshoot; some just rejected the idea outright (“there’s no need to look at VS internals here”, “we shouldn’t need to run DOS commands in today’s world, VS should hable this!”)
I can definitely sympathize with developers who were sold on what seemed like a promise that deep VS/IIS/etc knowledge would be the rock-solid foundation for business software for the rest of their careers. During the uprooting process, other promises like “netstandard2.0 will be forever for your core libraries and all future .NET runtimes!” end up with asterisks the following year.
I am 100% in agreement that .NET dev team is doing an amazing job, but it’s precisely because of their continued shakeups when they see major opportunities to improve it from the ground up, and probably the same reason that others feel wary of it
Anyways, I work with .NET Framework and .NET. Being a developer is a joy where you can learn daily new tricks and satisfy your curiosity.
So to me this reads so alien that people fail to learn new tricks within .NET world. For me it's like a stream of amazement: Ohh, this is so much better with new language features. Ohh, this code is so much more clean. Woa, logging is so simple with ILogger and I can plug whatever underlying log engine I want! Configuration via JSON files, niice. I can override with Env variables out of the box? Amazing. This all follows particular rules and patterns. Ohh, I can customize the way I read configuration any way I want if I need it so. Ohh, I can build and run from CLI using simple commands! Ohh, I can package in docker and run on Linux. Oh, wow, .csproj is so much more clean, gotta use SDK-style project for my .NET Framework projects too!
I love it! And yeah .NET Framework is still critical for some workloads, most notably C++/CLI and WCF for certain apps where deep win32 APIs make their net8.0+ alternatives too much of a headache :)
To temper my comment, the resistance I faced as the new guy brought in to modernize is natural for these engineers who knew their tools and systems well, in their defense. Eventually they warmed up from full pushback to friendly banter “Mr. Linux and command line over here” and accepted that running my little scripts helped address the confusion/frustration of Visual Studio disagreeing with Jenkins/GitHub Actions automations and runtime behavior in Kubernetes.
Funny... I actually kind of hate ILogger... at least the output implementations I've seen. I really like line-delimited JSON for standard logging with a pretty-printed version for local dev. With say a node project, I will usually attach a few bits of context as well as a details object with the simple log message... this is easy enough to ship to another system, or say with AWS, the built in logging platform handles it brilliantly.
I haven't seen a good logger implementation for .Net that does a similar good job without a bunch of byzantine configurations.
You're totally right on all those changes, and I think all of those things were the bane of .NET development. Getting rid of all the cruft in one swift operation was life-changing. Finally being able to junk IIS and deploy web apps to Linux running their own tight little web server (Kestrel) is fantastic.
As someone who has actively pushed in the direction of containerized deployments, VS Code with the integrated terminal over VS proper, etc... I love the direction .Net has taken in general. I have worked in a few environments where most of the devs and projects themselves feel stuck in concrete. I've left a couple places like that in the past few years just because they are painful environments to work in.
I couldn't even tell you how to do certain things in the VS gui at this point... I've got Rider and VS installed only because Rider is nicer for refactoring and I've had to fix VS launch issues a couple times (VS backend, vite/react frontent).
Prior to .Net core I had one foot out the door, mostly towards Node... Now, I'm fine with either/both... though all my shell scripting is now with Deno/TS.
Police that I’ve spoken to will readily confirm this. They consider profiling, not necessarily racial, an important part of patrolling. If they decide you look the part, they will find a way within several minutes/miles of watching.
As a fellow former grocery store employee, I can agree about the “break up the monotony” concept from the narrow POV of the bored worker.
It is an inconvenience though, even if as insignificant as an eyesore for others, or the landscaper who may need to remove shopping carts from the planter to do their work.
You could apply similar logic to people who carelessly throw trash in the recycling bin or on a sidewalk where it’s someone else’s job to clean up after them. I’ve seen people go as far as to say they are graciously “providing a job” for someone else when they throw their refuse in the recycling bin.
The fact that the shopping carts are such an inconsequential thing to shrug off is what makes them a great litmus test — will you do the right thing simply because it’s the right thing to do, even when there is so little at stake
> I’ve seen people go as far as to say they are graciously “providing a job” for someone else when they throw their refuse in the recycling bin.
The great thing about the “job creation” theory of antisocial behavior is that it justifies all kinds of things, from graffiti to dumping to stealing decorative plants from the local park. Why bother following implicit (or even explicit) rules if there is no consequence? Surely it won’t have any consequences in the long run!
Not to mention that, at least on the iOS app, the button to close an ad is in a totally different place than the rest of the UI screens, which is always in the top-left of the screen. A small “X” is placed in the middle-left of the ad image, to make you spend an extra second finding it, which I would assume they are happy to report as a user engagement metric to their advertisers.
These are great and succinct, yours and your teammate’s.
I still find myself debating this internally, but one objective metric is how smoothly my longer PTOs go:
The only times I haven’t received a single emergency call were when I left teammates a a large and extremely specific set of shell scripts and/or executables that do exactly one thing. No configs, no args/opts (or ridiculously minimal), each named something like run-config-a-for-client-x-with-dataset-3.ps1 that took care of everything for one task I knew they’d need. Just double click this file when you get the new dataset, or clone/rename it and tweak line #8 if you need to run it for a new client, that kind of thing.
Looking inside the scripts/programs looks like the opposite of all of the DRY or any similar principles I’ve been taught (save for KISS and others similarly simplistic)
But the result speaks for itself. The further I go down that excessively basic path, the more people can get work done without me online, and I get to enjoy PTO. Anytime i make a slick flexible utility with pretty code and docs, I get the “any chance you could hop on?” text. Put the slick stuff in the core libraries and keep the executables dumb
I see a similar problem in infra-land where people expose too many config variables for too many things, creating more cruft. Knowing what to hardcode and what to expose as a var is something a lot of devs don't seem to understand; and don't realise they don't understand.
Oh definitely, many headaches untangling massive “variables.tf” files where the value is identical in 100% of the target environments, and would be nonsensical to change without corresponding changes in the infra config resources/modules as well.
My favorite are things where security policy mandates something like private networking and RBAC, and certain resources only have meaning in those contexts, for heavens sake why are we making their basic args like “enforce_tls” or “assign_public_ip” or “enable_rbac” into variable params for the user to figure out
Yes I feel that when to apply certain techniques is frequently under-discussed. But I can't blame people for err-ing on the side of 'do everything properly' - as this makes life more pleasant in teams.
Although I think if you squint, the principle still applies to your example. The further you get from the 'core' of your platform/application/business/what-have-you, the less abstract you need to be.
For me, it would be because the term AGI gets bandied about a lot more frequently in discussions involving Gen AI, as if that path takes us any closer to AGI than other threads in the AI field have.
