I’m afraid setting a version lower than the one you’re using means you have to setup a CI of some kind to verify compilation does indeed work for previous versions of go.
Maybe that’s why some author do not bother and put the version they are using (though I do agree it is a bad practice indeed).
IMHO MCP is the AppleScript/Shortcuts part of the internet. Never really took on Apple platforms (except for some hardcore fans); not sure it will ever actually take on the internet…
> I would go for a 2 or 3 hour walk with my phone using the remote control feature looking every 5 - 10 minutes to make sure it doesn't need human help.
Nightmarish?! In comparison to the average person's actual job? I'm pretty sure that many people out there would sign up for a battle royale for a chance at such a job.
Tech industry folks have been so coddled for decades that many think their astonishing intellect has earned them a cushy life rather than being in a field with high labor demand. It’s one reason tech workers are often considered arrogant and out of touch… and that’s why people think they can get paid to lightly orchestrate agents to do their jobs. Oof.
If efficiency gains create an oversupply of tech labor, even the bestie BFF bosses will notice the hoards of more qualified people who will kill for any job that pays more than CVS or Uber— so a lot less than most developers make now. The tech world regularly, shamelessly cuts higher-earning higher-skill workers for cheaper “good enough” replacements. Best of luck.
Even many of the folks that see the writing on the wall have fanciful visions of using their astonishingly capable genius developer brain to maintain or quickly re-achieve some of their high status in the trades. As a union tradesman, I’d find that misconception hilarious if I didn’t feel so bad for them. A lot of folks are going to have a lot of bitter medicine to swallow.
My clients have been burned before. Once you set up the battle royale with a trusted third party validating that there'll be an assured good job at the end, I promise I'll have enough candidates for you to fill up the first 10 competitions.
That nightmarish scenario is what T.S. Eliot was describing in "The Wasteland" which "portrays deep, existential ennui and boredom as defining symptoms of modern life following World War I."
Later this boredom was described by the Stones, "And though she’s not really ill / There’s a little yellow pill / She goes running for the shelter of a mother’s little helper".
It is a nightmare. Mostly what I'm thinking about while the agents are running is how bored I'm going to be. That is the joke, my deep thought on T.S. Eliot are about the wasteland this thing is going to create.
It can request with a JS call. It can't passively collect it without you approving first. The article is written like calling that JS function will turn on location tracking without consent.
That would allow you to see the local network IP (not actually sure you even get that, tbh). To get more detailed information about IP configuration, you need Location permission. Been there, done that. Most Android network information calls provide degraded information if you have not been granted Location permissions.
Completely tangential, but can we please stop putting one million files at the root of the project which have nothing to do with the project? Can we land on a convention like, idk, a `.meta` folder (not the meta company, the actual word), or whatever, in which all of these Claude.md, .swift-version, Code-of-Conduct.md, Codeowners, Contributing.md, .rubocop.yml, .editorconfig, etc. files would go??
I _can_ do the same with Rust, doesn't mean it's "the language I reach for" for making e.g. a website. Because the tooling, ergonomics, hireability factor, etc. are still very harshly against it.
Same with Swift, but I'd call that more of a wasted opportunity because Apple, unlike Rust Foundation, has a mountain of money to make it happen, and yet they don't seem to care.
I don’t believe that’s true. Things are moving constantly, and in the right direction. Then again it would help if you cited particular grievances, because being a regular (cross-platform/cross-target) Swift user I am not sure what you are talking about…
I did not choose ClearSurgery’s example randomly. I was at a conference recently where the CTO was here, and he explicitly told us they were moving fast thanks to the Swift ecosystem. (I am not working there personally, nor am I affiliated.)
if they really want me to use this lang for everything, they'd have to 1. massively improve compilation speed, 2. get the ecosystem going (what's the correct way to spin up an http server like with express?) and 3. get rid of roughly 150 of the 200 keywords there are
especially w.r.t. the last one, of course everyone frets at huge breaking changes like this, so it won't happen, so people won't use it
> 3. get rid of roughly 150 of the 200 keywords there are
I don't understand this point. Could you explain?
The new keywords enable new language features (ex: async/await, any, actor), and these features are opt-in. If you don't want to use them, you don't have to.
What are they keywords you think should be removed?
> these features are opt-in. If you don't want to use them, you don't have to.
Using a language is more than just writing it with a pre-established knowledge of what subset of features you think is worth the tradeoffs. More keywords/features means when you try to figure out how to do something new, there may be 15 different ways and you need to analyze and figure out which is the best one for this scenario, which ones are nonstarters, etc.
That's was more or less the whole design goal of Go. It was made by C++ programmers who were fed up with how many features were in the language, so they kept the feature set limited. Even the formatting is decided by the language. You may not agree with every decision, but what matters is decisions were made and they're standardized, so everyone is on the same page. You can read anyone else's code, and you know exactly what's going on.
besides it being almost impossible to understand what "the right way of doing stuff" is with Swift (or any bloated language), i absolutely _do_ have to use the keywords.
reading someone else's code is part of working with the language (as is understanding LLM output nowadays). i can't just make others not use the keywords i don't know/beed/like. especially if working within teams, or using OSS.
Not just uber slow to compile, because as a Rust dev I could take that. But it rejects correct programs without telling you why! The compiler will just time out and ask you to refactor so it has a better shot. I understand that kind of pathological behavior is present in many compilers but I hit it way too often in Swift on seemingly benign code.
Did that happen recently (the compiler just bailing out)?
Because they got much better at that, and it’s been a long while since that happened to me. Like “I don’t even remember when was the last time it happened” long.
I don't know why anyone would want to use Apple tools if they are not developing for Apple platforms. Apple barely maintains compatibility for their own platforms, using Swift on a non-Apple platform is setting yourself up for doubule pain.
Why are you interpreting this comment as "never receives updates"? It takes great effort to maintain API compatibility, some things aren't improved or are implicitly deprecated.
In a way it still is true. Swift works on Windows and Linux until it doesn't. It's taken until a couple years ago for other build systems to get swift support (which I suppose is the fault of said build system, but Swift taking so long to be cross-platform contributed to that), and even now it (still) doesn't quite work right. C interop is a mess requiring hacks to generate clang modules to actually get Swift to see them (and CMake for example provides no easy way of doing this, or last time I checked it didn't). Oh and Swift tends to take over the linker and compilation pipelines when you enable it, at least with CMake, because... Reasons? I honestly don't know why. It causes very weird errors when I integrated Swift code into my C++ project that were a pain to actually diagnose. I eventually got it working, but still, it wasn't simple or seamless.
> Plus Swift is arguably too unnecessarily complex now.
I would argue the allegations of complexity against Swift are greatly exaggerated. I find the language to be very elegant and expressive in syntax, high in readability, and fairly terse. Other than that, Swift feels near identical to every other OoP language I have used.
- Comments as directives[0]. Nobody finds this intuitive. I've never met anyone that saw what directives were doing and thought to change a comment.
- Comments as commands for the compiler[1]
- The state of go linting[2]. There are 30 different formatting tools that all frequently conflict with each other. It got so complicated that one project exists to manage installations of all the other ones (golangci-lint). Only difficulty is that most IDEs use gofmt and if your golangci-lint uses a different gofmt version than your IDE, you end up getting different formatting when you save vs. when you commit. This is only a problem because golangci-lint can't be installed using the go toolchain[3], so you can't just have dependency resolution solve this for you.
Maybe that’s why some author do not bother and put the version they are using (though I do agree it is a bad practice indeed).
reply