VSCode Swift 1.0(forums.swift.org)
forums.swift.org
VSCode Swift 1.0
https://forums.swift.org/t/vscode-swift-v1-0-0/62668
11 comments
I wonder how big the market is for this. Despite being an actually nice language, Swift is not that popular outside Apple's ecosystem, so I guess most developers would use XCode for it's integration (with Apple Developer, SwiftUI/preview etc).
I don't think XCode is exactly popular or viewed as anything other than necessary evil by many Swift app developers. Like a sibling comment mentioned, many people already use other IDEs to write the code and just use XCode to compile stuff because it is just so ass. Get the compiler invocation experience and maybe even the Apple Developer integration to a decent enough shape in a VS Code extension and XCode can start counting its days methinks.
> many people already use other IDEs to write the code and just use XCode to compile stuff
I've never met anyone who actually does this. JetBrains is even discontinuing AppCode, which as far as I know was the only real alternative IDE (and it had a lot of holes in its functionality).
Xcode lacks decent refactoring tools but otherwise it's a perfectly fine IDE, and has some really powerful debugging abilities. Don't get me wrong, I don't think Apple is giving it the attention it deserves, but in my experience most people hate it just because it isn't IntelliJ or VSCode.
I've never met anyone who actually does this. JetBrains is even discontinuing AppCode, which as far as I know was the only real alternative IDE (and it had a lot of holes in its functionality).
Xcode lacks decent refactoring tools but otherwise it's a perfectly fine IDE, and has some really powerful debugging abilities. Don't get me wrong, I don't think Apple is giving it the attention it deserves, but in my experience most people hate it just because it isn't IntelliJ or VSCode.
My issue with Xcode isn't a lack of features, its the fact that the features don't reliably work. And not the advanced stuff, the very basic features. I routinely have issues with stuff like clicking through classes or syntax highlighting.
Another thing thats highly annoying is that compile errors don't get properly cleared on builds, so if there are multiple errors, it might just be that one of them is a real error, but the others are stale.
Lately I've been working with Swift Packages, and now restarting Xcode many times a day is part of my workflow - otherwise compile errors persist.
Ive been in iOS for a decade now, so mostly I don't get hung up one these issues, I know how to clean the "derived data" folder, I know how to jiggle it "just so" to get it to do what I want. But still its frustrating that the most important tool in my job is doomed to be moderately broken forever.
It might be a "grass is greener" scenario, but whenever I hop to IntelliJ, I don't encounter any of these kinds of problems.
Oh, and BTW, if you want to check Xcode out for yourself and have trouble downloading it, its not you - Xcode is like 20GB big. I guess you need lots of space for the world's most broken syntax highlighting algorithm...
Another thing thats highly annoying is that compile errors don't get properly cleared on builds, so if there are multiple errors, it might just be that one of them is a real error, but the others are stale.
Lately I've been working with Swift Packages, and now restarting Xcode many times a day is part of my workflow - otherwise compile errors persist.
Ive been in iOS for a decade now, so mostly I don't get hung up one these issues, I know how to clean the "derived data" folder, I know how to jiggle it "just so" to get it to do what I want. But still its frustrating that the most important tool in my job is doomed to be moderately broken forever.
It might be a "grass is greener" scenario, but whenever I hop to IntelliJ, I don't encounter any of these kinds of problems.
Oh, and BTW, if you want to check Xcode out for yourself and have trouble downloading it, its not you - Xcode is like 20GB big. I guess you need lots of space for the world's most broken syntax highlighting algorithm...
> compile errors don't get properly cleared on builds, so if there are multiple errors, it might just be that one of them is a real error, but the others are stale.
Oh wow, I opened it about once to compile something, had this issue and had to clear a bunch of caches. I thought I was holding it wrong. Signing to get an ios-on-mac app to run was also a hellish experience; I think I ended up using the iPad emulator to preview the thing.
It felt a lot like they don't want you to develop things and I guess that fits with their general perceived disdain for general purpose computing (download the big-corp SaaS app from the App Store and shut up).
Oh wow, I opened it about once to compile something, had this issue and had to clear a bunch of caches. I thought I was holding it wrong. Signing to get an ios-on-mac app to run was also a hellish experience; I think I ended up using the iPad emulator to preview the thing.
It felt a lot like they don't want you to develop things and I guess that fits with their general perceived disdain for general purpose computing (download the big-corp SaaS app from the App Store and shut up).
Well I do it. Or did till App Code was killed. I still do some Swift in CLion.
Here’s my reasons:
- Xcode has many failure cases for refactoring or is slow at finding symbols across extensions. Jetbrains handled it effortlessly. God forbid something crosses a target boundary.
- Xcode is really terrible for multi language projects. If you’re sticking to ObjC and Swift, it’s fine, but the C++ support is really poor. If you need to throw in Python or anything else, good luck. Jetbrains handle multi language super well.
- extensibility is a big deal. Xcode isn’t extensible (well only in a very limited way) and there’s many plug-ins that I either use or create for myself to speed up my work.
If Xcode supported LSPs, it would honestly change the equation greatly. But today myself, and several other devs I know, edit outside Xcode and build via the command line tools instead.
Here’s my reasons:
- Xcode has many failure cases for refactoring or is slow at finding symbols across extensions. Jetbrains handled it effortlessly. God forbid something crosses a target boundary.
- Xcode is really terrible for multi language projects. If you’re sticking to ObjC and Swift, it’s fine, but the C++ support is really poor. If you need to throw in Python or anything else, good luck. Jetbrains handle multi language super well.
- extensibility is a big deal. Xcode isn’t extensible (well only in a very limited way) and there’s many plug-ins that I either use or create for myself to speed up my work.
If Xcode supported LSPs, it would honestly change the equation greatly. But today myself, and several other devs I know, edit outside Xcode and build via the command line tools instead.
To be fair Objective-C and Swift are really the languages Apple wants everyone to use.
C++ official support in OS frameworks relates to IO and Driver Kit, LLVM and Metal Shading Language.
Whatever works for Objective-C also works for C.
C++ official support in OS frameworks relates to IO and Driver Kit, LLVM and Metal Shading Language.
Whatever works for Objective-C also works for C.
Fair enough. My point wasn't that literally no one does it, but more that it's pretty uncommon. You can't get live errors/warnings in Swift or ObjC outside of Xcode, right?
you can since those are a property of clang itself not Xcode. Xcode does some analysis on top of clang but you can use clangd in an LSP.
What you leave behind though are any of the interactive bits like live previews, storyboards, all the core data utilities.
What you leave behind though are any of the interactive bits like live previews, storyboards, all the core data utilities.
I’m curious what refactoring tools are missing? I don’t use many other IDEs so would be interested to hear about them. I’ve used Xcode’s existing refactoring tools quite a bit, but haven’t felt I was missing anything, probably because I don’t really know what else is available. (They were terrible for many years, supporting only Objective-C, but they now support C, C++ and Swift as well.)
My experience is limited to using it with Swift and Objective-C. Xcode has been getting better recently but tools like IntelliJ have support for a bunch of useful things that Xcode doesn't. Off the top of my head:
* refactoring functions/methods: adding and removing parameters, renaming parameters, etc.
* safe-deleting symbols
* advanced search tools. Not just "find selected symbol in workspace", but "find places where this variable is being written to"
Also, the refactoring tools that Xcode does include are very unreliable. Even simple renaming will often fail, even on small projects, or will mistakenly rename unrelated symbols.
* refactoring functions/methods: adding and removing parameters, renaming parameters, etc.
* safe-deleting symbols
* advanced search tools. Not just "find selected symbol in workspace", but "find places where this variable is being written to"
Also, the refactoring tools that Xcode does include are very unreliable. Even simple renaming will often fail, even on small projects, or will mistakenly rename unrelated symbols.
Oh, AppCode absolutely kicked ass in 2013-2014 when Obj-C had been somewhat modernised but wasn’t changing too fast, and Swift was yet to be announced. Xcode was an even worse editor back then too.
It was always a struggle for JetBrains to keep up with Apple dropping new stuff with no notice though, and I can’t remember when I last tried AppCode
It was always a struggle for JetBrains to keep up with Apple dropping new stuff with no notice though, and I can’t remember when I last tried AppCode
I’ve only started learning Swift, so I don’t know how it performs on bigger projects, but so far I’ve been loving playgrounds, if not for the dog-slow compilation, but that’s in-character for all LLVM-based compilers, so maybe not exactly XCode’s fault.
this is what I do with visual studio for unreal engine as well. I only use it to compile and edit my code with helix
Slowly but surely things are getting better in terms of cross-platform, with the latest in that realm being Apple itself committing to an open source rewrite of Foundation, which will fill in some holes and improve consistency on non-apple platforms.
Swift on server has been usable for a while now too.
I think the next big bottleneck on popularity will be tooling, and a solid VS Code extension is a small step forward in addressing that issue.
As someone who’s been using Swift for years on iOS/macOS, I’d love to use it for desktop development on Windows and Linux. I think the language is well suited for that purpose, and it strikes a nice balance between safety, speed, features, ease of writing, and clean syntax which isn’t matched by too many other languages.
Swift on server has been usable for a while now too.
I think the next big bottleneck on popularity will be tooling, and a solid VS Code extension is a small step forward in addressing that issue.
As someone who’s been using Swift for years on iOS/macOS, I’d love to use it for desktop development on Windows and Linux. I think the language is well suited for that purpose, and it strikes a nice balance between safety, speed, features, ease of writing, and clean syntax which isn’t matched by too many other languages.
Well, with WASM everywhere I think that it might realize some of its potential as tooling improves. Don't you want to write your algorithms and data structures in such a nice language? Slap the native UI, when in iOS its SwiftUI and when on the web its ReactJS or something and when its on Android its whatever Android uses but have your actual processing of the user inputs in Swift.
The traditional cross platform approach is to write it in JS and use the native UI framework API, which works but its not native anywhere and you have to write JS.
So instead of doing that, you can start with Apple platforms and port to the other platform where porting would mean just UI and device specific API implementation as the Swift can be portable. You wouldn't be trying to build native UI with Swift but you would use the Swift code as a service which handles everything except the UI where the UI implementation will communicate with your Swift code.
The advantages are:
1) Working with Swift, which is pleasant to work with.
2) Apple's all platforms are on the same architecture and as a result, running your code for mobile on your dev machine works at full speed. This means, even the cheapest Apple Silicon device provides great performance on your workflow. No more sluggish emulators.
3) Preserve the data structures across all platforms and these data structures are not JS data structures. You have integers for example :). Categories of bugs and work to make things fit vanish.
The traditional cross platform approach is to write it in JS and use the native UI framework API, which works but its not native anywhere and you have to write JS.
So instead of doing that, you can start with Apple platforms and port to the other platform where porting would mean just UI and device specific API implementation as the Swift can be portable. You wouldn't be trying to build native UI with Swift but you would use the Swift code as a service which handles everything except the UI where the UI implementation will communicate with your Swift code.
The advantages are:
1) Working with Swift, which is pleasant to work with.
2) Apple's all platforms are on the same architecture and as a result, running your code for mobile on your dev machine works at full speed. This means, even the cheapest Apple Silicon device provides great performance on your workflow. No more sluggish emulators.
3) Preserve the data structures across all platforms and these data structures are not JS data structures. You have integers for example :). Categories of bugs and work to make things fit vanish.
For me XCode is just so so bad for actual code editing so I edit the code in VSCode and run it through XCode
I agree. I personally find XCode absolutely bewildering.
The several times I've tried to do anything with it, I just gave up and found an alternative. My guess is that if you've been using Apple tools for years, then it makes sense, but to me it's indecipherable. The menu options don't seem to match with the GUI, resource views don't seem to match the files, random panels appear with unnecessary information, resources are needed for unclear reasons and more.
It's all very Apple, but in the worst way possible. It's like the IDE version of AppleScript - seemingly useable but based on a logic which totally escapes me.
The several times I've tried to do anything with it, I just gave up and found an alternative. My guess is that if you've been using Apple tools for years, then it makes sense, but to me it's indecipherable. The menu options don't seem to match with the GUI, resource views don't seem to match the files, random panels appear with unnecessary information, resources are needed for unclear reasons and more.
It's all very Apple, but in the worst way possible. It's like the IDE version of AppleScript - seemingly useable but based on a logic which totally escapes me.
The use case is mainly for writing packages, command line tools or server side components where the Swift toolchains are quite nice to work with. The experience is very much like using Rust or Go.
I am more likely to try Swift, if I can use it in my existing tools. So maybe the play is to make it more popular.
Fun fact, Swift is actually available in Fedora Linux’s default repos.
It’s just “dnf install swift” and you’re all set.
I would love to see more Swift adoption, I know at one point IBM was investing in it for server-side programming, but I think they’ve abandoned that.
It seems to be a nice sweet spot of relatively easy to code, expressive, powerful, memory safe, and performant.
It’s just “dnf install swift” and you’re all set.
I would love to see more Swift adoption, I know at one point IBM was investing in it for server-side programming, but I think they’ve abandoned that.
It seems to be a nice sweet spot of relatively easy to code, expressive, powerful, memory safe, and performant.
It’s such a shame, i really envy some of the features in Swift but I just can’t justify the risk with how Apple-centric it is. Too many times I’ve been bitten by ducks that quacked just like that one, I suppose.
I’d love to see like a gccSwift the way there’a a gccRust coming together. I think that would be really cool.
I’d love to see like a gccSwift the way there’a a gccRust coming together. I think that would be really cool.
Developers rarely use XCode out of choice, at least from the iOS devs I know.
It also opens up the potential for development on non-Apple equipment if the CI can handle builds.
It also opens up the potential for development on non-Apple equipment if the CI can handle builds.
You can already develop Swift code on non-Apple equipment
You can’t develop for iOS as their frameworks are as of now (this is changing, they’re rewriting Foundation) tied to macOS, so this doesn’t change much
You can’t develop for iOS as their frameworks are as of now (this is changing, they’re rewriting Foundation) tied to macOS, so this doesn’t change much
Stuff I really miss from Xcode:
* Smarter refactoring like "extract protocol"
* Detection of unused imports and dead code
Both things the original Visual Studio had over a decade ago.
I think the new generics system is finally making the language more usable for the typical scenarios I like to tackle with it. What still baffles me is that it's impossible to create protocols that have stuff like @Published in them. Massively decreases / complicates / uglifies reusability opportunities in ViewModels.
* Smarter refactoring like "extract protocol"
* Detection of unused imports and dead code
Both things the original Visual Studio had over a decade ago.
I think the new generics system is finally making the language more usable for the typical scenarios I like to tackle with it. What still baffles me is that it's impossible to create protocols that have stuff like @Published in them. Massively decreases / complicates / uglifies reusability opportunities in ViewModels.
My brain and fingers hurt using the vim keybindings in Xcode. Looking forward to trying this extension out in VSCode which has far superior vim keybindings.
The vim keybindings that Xcode has implemented work fine for me, but some omissions like using the period character to repeat the last action are quite debilitating.
Good. Wish something like that existed for Kotlin.
And no, being locked into Intellij ecosystem is not the same.
I wish there is something like this for Kotlin and Android development. One of these I might Android development just because of the shit its development and build environment is — Android Studio, Gradle etc. What a glorious mess!
Funny how things sometimes overlap, JetBrains dumps support for Swift [1], and a month later VSCode gets the production ready plugin.
[1] https://news.ycombinator.com/item?id=33994406
[1] https://news.ycombinator.com/item?id=33994406
And in December an effort was started to get Copilot in Xcode[1] when it was previously limited to only in Jetbrains AppCode. Now we have two options for Swift Copilot.
[1] https://github.com/intitni/CopilotForXcode
[1] https://github.com/intitni/CopilotForXcode
Link 1: It's out of preview.
Link 2: It has release notes with no new information.
Link 3: Available here:
https://marketplace.visualstudio.com/items?itemName=sswg.swi...
Link 2: It has release notes with no new information.
Link 3: Available here:
https://marketplace.visualstudio.com/items?itemName=sswg.swi...
Does anyone know of any reliable VSCode extension for Kotlin (Android or server side)?
Given that JetBrains officially stated they also want Kotlin to help drive InteliJ licenses, and removed support from Eclipse plugin, don't expect too much on that front.
https://github.com/fwcd/vscode-kotlin uses the maintained Kotlin Language Server but it’s not perfect. There’s nothing on par with Jetbrains out there
Link to the VSCode extension: https://marketplace.visualstudio.com/items?itemName=sswg.swi...
Still trying to learn swift. My impression is that it’s an ugly language designed by committee (largeness and some extraneous features like guard) and part of the reason why the compiler is slow and why xcode has problems with slow syntax checking sometimes.
That's not really my impression at all. I see it as a fairly opinionated language that has taken a lot of inspiration from Ruby and Haskell. Things like strings are strongly opinionated and have gone through multiple revisions to get them to where they are.
One of the opinions is that it values expressiveness, and having multiple ways to do things that means you can choose a nice way to express each line, rather than always being forced to write it the same way.
This is a trade-off. To use `guard` as an example, sometimes it may be clearer to use a guard, and sometimes it may not. Swift has chosen to provide both options, at the cost of users needing to learn both.
I think it developed a negative reputation for the fact that the first few iterations did have a lot of breaking changes and added a lot of features. This made sense to me, the first version was somewhat of an MVP and it needed plenty of work still, but the language is relatively mature now and has stabilised significantly in recent years.
The compiler isn't generally that slow overall, but there are performance edge cases where complex type-checking can take far longer than other things. If you're having problems with speed, I'd recommend profiling your build, it's possible there are a handful of functions that are taking most of the build time.
One of the opinions is that it values expressiveness, and having multiple ways to do things that means you can choose a nice way to express each line, rather than always being forced to write it the same way.
This is a trade-off. To use `guard` as an example, sometimes it may be clearer to use a guard, and sometimes it may not. Swift has chosen to provide both options, at the cost of users needing to learn both.
I think it developed a negative reputation for the fact that the first few iterations did have a lot of breaking changes and added a lot of features. This made sense to me, the first version was somewhat of an MVP and it needed plenty of work still, but the language is relatively mature now and has stabilised significantly in recent years.
The compiler isn't generally that slow overall, but there are performance edge cases where complex type-checking can take far longer than other things. If you're having problems with speed, I'd recommend profiling your build, it's possible there are a handful of functions that are taking most of the build time.
> [Swift] values expressiveness, and having multiple ways to do things that means you can choose a nice way to express each line, rather than always being forced to write it the same way.
There are at least two major problems with this kind of PL design approach: 1.) when you work on a large codebase from multiple contributors, all the possible combinations of the available syntax and standard library calls will eventually get used, making your brain frustrate quickly when reading code written by others, and 2.) when you interview for a new job, all the possible combinations of the available syntax and standard library calls will eventually be asked about by interviewers, making you look and feel like an incompetent programmer.
I have to agree with the OP - Swift seems to be an unreasonably bloated PL. Unless one plans to work only with Swift all the time, learning all there is to learn about Swift on the way, it might be easier to just use Rust or Go.
There are at least two major problems with this kind of PL design approach: 1.) when you work on a large codebase from multiple contributors, all the possible combinations of the available syntax and standard library calls will eventually get used, making your brain frustrate quickly when reading code written by others, and 2.) when you interview for a new job, all the possible combinations of the available syntax and standard library calls will eventually be asked about by interviewers, making you look and feel like an incompetent programmer.
I have to agree with the OP - Swift seems to be an unreasonably bloated PL. Unless one plans to work only with Swift all the time, learning all there is to learn about Swift on the way, it might be easier to just use Rust or Go.
Rust and Swift have about the same amount of syntax imho, and often share a lot of it. Go is simpler as a language but you end up writing more code to accommodate that.
> Rust and Swift have about the same amount of syntax
I wouldn't agree, I feel Swift has significantly more surface area than Rust.
But even syntax and standard libraries aside, I think that Rust is significantly more "explicit", "consistent" and "predictable" than Swift. I consider those to be very important qualities in a PL. Maybe that's why Rust was easier to learn and memorize than Swift (with the exception of the Rust borrow checker and lifetime annotations that indeed have to be well understood to be even usable).
But it might be just me.
I wouldn't agree, I feel Swift has significantly more surface area than Rust.
But even syntax and standard libraries aside, I think that Rust is significantly more "explicit", "consistent" and "predictable" than Swift. I consider those to be very important qualities in a PL. Maybe that's why Rust was easier to learn and memorize than Swift (with the exception of the Rust borrow checker and lifetime annotations that indeed have to be well understood to be even usable).
But it might be just me.
Hmm can’t say I agree about the significantly more surface area. I switch between rust/C++/Swift fairly regularly for work, and I think they’re roughly similar in complexity with the exception of Rust having lifetime annotations and Swift having computer properties.
Where I do think Swift has a lot of noise though is @attributes. There’s just so many attributes to learn, especially if you happen to do SwiftUI or ObjC interop. Though rust has the same issue , it’s just there’s no ubiquitous UI lib like SwiftUI. I imagine it would have the same if it did.
Where I do think Swift has a lot of noise though is @attributes. There’s just so many attributes to learn, especially if you happen to do SwiftUI or ObjC interop. Though rust has the same issue , it’s just there’s no ubiquitous UI lib like SwiftUI. I imagine it would have the same if it did.
> If you're having problems with speed, I'd recommend profiling your build, it's possible there are a handful of functions that are taking most of the build time.
How does one do that? I hit this problem a lot. (I’ve since learned to use lots of explicit casts to make it less bad.)
How does one do that? I hit this problem a lot. (I’ve since learned to use lots of explicit casts to make it less bad.)
I can't remember exactly, it's been a year since I last did this. I believe there's a setting for the threshold at which this should be logged, so you could set it to log any expression that takes more than 100ms to type-check. By default I think it just times out at 10 seconds or something.
I looked into it, and found that you can add these "OTHER_SWIFT_FLAGS" to your project:
OTHER_SWIFT_FLAGS = -Xfrontend -debug-time-expression-type-checking -Xfrontend -debug-time-function-bodies
There's also this great WWDC session on build parallelization:
https://developer.apple.com/wwdc22/110364
OTHER_SWIFT_FLAGS = -Xfrontend -debug-time-expression-type-checking -Xfrontend -debug-time-function-bodies
There's also this great WWDC session on build parallelization:
https://developer.apple.com/wwdc22/110364
The things you find ugly are the things that I think make Swift code quite pleasant to work with.
More languages need a guard. It’s a really great control flow operator to flatten your code. Rust added `let else` last year that does the same and it does wonders to clean up code.
There are things I dislike about Swift , like lack of explicit namespace organization (rust mod or c++ namespace keywords, and the enum trick does not count) as well as the ability to drop extensions anywhere (which leads to a lot of stream of consciousness programming). However I don’t think I’d really consider it ugly.
What languages are you coming from and what else do you not like about Swift?
More languages need a guard. It’s a really great control flow operator to flatten your code. Rust added `let else` last year that does the same and it does wonders to clean up code.
There are things I dislike about Swift , like lack of explicit namespace organization (rust mod or c++ namespace keywords, and the enum trick does not count) as well as the ability to drop extensions anywhere (which leads to a lot of stream of consciousness programming). However I don’t think I’d really consider it ugly.
What languages are you coming from and what else do you not like about Swift?
Coming from the usual languages: pascal, modula-2, objective c, c, lisp, miranda, ruby, python. Another thing I don’t like about Swift are the named parameters which was an objective C thing. I find it makes reading code difficult because you don’t start parsing a function call until the first ‘(‘, you have to read the args too to determine which function is being called. I also don’t like the integration of swiftui syntax into swift. Plus you read some of the stuff going on in swift evolution and it seems they are hell bent on adding everything to the language.
Personally (and totally subjectively) I’d argue that a lot of those languages you listed are ugly, with the exception of the last two. Some of them are nice looking for short bits but get really ugly for larger pieces of code. Especially when you practice defensive programming and are nested several levels deep because of the lack of optionals.
The SwiftUI integration doesn’t materially change the language much. It’s based on passing in blocks as parameters and has been a norm for obj-c as well (effectively how everyone does completion handlers).
But I think that’s why language beauty is in the eye of the beholder. To me, Swift allows flatter/cleaner code while defensively programming with lower branching and higher ergonomics. That’s beauty. That’s why guard is so nice. But I can see how it might be off putting if you’re coming from other PL paradigms.
I think a lot of it comes down to whether people want simple syntax vs simple code. C for example is simple syntax but rarely ever simple code , Swift and rust are more complex syntax but much simpler code.
The SwiftUI integration doesn’t materially change the language much. It’s based on passing in blocks as parameters and has been a norm for obj-c as well (effectively how everyone does completion handlers).
But I think that’s why language beauty is in the eye of the beholder. To me, Swift allows flatter/cleaner code while defensively programming with lower branching and higher ergonomics. That’s beauty. That’s why guard is so nice. But I can see how it might be off putting if you’re coming from other PL paradigms.
I think a lot of it comes down to whether people want simple syntax vs simple code. C for example is simple syntax but rarely ever simple code , Swift and rust are more complex syntax but much simpler code.
> Another thing I don’t like about Swift are the named parameters which was an objective C thing.
Might just be what you're used to, but I find languages without named parameters annoying, particularly when I'm reading code I'm not my own. They do a lot to disambiguate and make reading unfamiliar code much smoother.
Might just be what you're used to, but I find languages without named parameters annoying, particularly when I'm reading code I'm not my own. They do a lot to disambiguate and make reading unfamiliar code much smoother.
Surprised to see this opinion on `guard`! IMO it's such a nice feature for future developers looking at that code, it's a clear indicator to pay attention to this area of code and know exiting the function is important.
I may be too harsh on guard but I like small languages. When I first encountered guard I wondered if it was truly necessary to the language and it wasn't.
Many languages have ergonomic features that aren’t truly necessary but are worth having.
I recognize you prefer smaller languages but I’d like to make a case for guards usefulness.
Guard is great because it’s a combined early return and assignment. Imho if you have a language with optionals, it’s a required pattern to have, or you end up with lots of conditional unwraps and nested blocks, or lots of placeholder variables that you might accidentally use in your code later causing safety or memory access issues .
Take the following code
if let foo = Some(optional) {yourLogicHere} else {return}
That’s one level of nesting.
Swift is nice enough to elide the Some matching so you’d just have
if let foo = optional {yourLogicHere} else {return}
Still one level of nesting but a little cleaner.
Now if you have a language based around safety, like Rust or Swift, a lot of functions return optionals. So you’ll keep nesting code in your checks for safety
Now take a guard.
guard let foo = optional else { return }
yourLogicHere
That’s one level of unnesting removed , and that compounds.
Better yet, you can chain them
guard let foo = optional, let spam = foo.lookup() else {return}
The equivalent in C like languages would be
type foo; if (!getOptional(&foo) return;
Now either you early return in the case of the optional failing or you nest. Nesting gets repetitive and deep.
Or you unnest like I have and have that foo sticking around un-initialized, potentially causing issues of use later.
Guard simultaneously removes both conundrums and makes your code both neater and safer.
I recognize you prefer smaller languages but I’d like to make a case for guards usefulness.
Guard is great because it’s a combined early return and assignment. Imho if you have a language with optionals, it’s a required pattern to have, or you end up with lots of conditional unwraps and nested blocks, or lots of placeholder variables that you might accidentally use in your code later causing safety or memory access issues .
Take the following code
if let foo = Some(optional) {yourLogicHere} else {return}
That’s one level of nesting.
Swift is nice enough to elide the Some matching so you’d just have
if let foo = optional {yourLogicHere} else {return}
Still one level of nesting but a little cleaner.
Now if you have a language based around safety, like Rust or Swift, a lot of functions return optionals. So you’ll keep nesting code in your checks for safety
Now take a guard.
guard let foo = optional else { return }
yourLogicHere
That’s one level of unnesting removed , and that compounds.
Better yet, you can chain them
guard let foo = optional, let spam = foo.lookup() else {return}
The equivalent in C like languages would be
type foo; if (!getOptional(&foo) return;
Now either you early return in the case of the optional failing or you nest. Nesting gets repetitive and deep.
Or you unnest like I have and have that foo sticking around un-initialized, potentially causing issues of use later.
Guard simultaneously removes both conundrums and makes your code both neater and safer.
Adding to this excellent explanation, the guard is compile time checked too, so you can't accidentally screw up the early return like one could in say c or c++
It might seem like a quality of life feature to some, to me however it's an essential feature of swift and one of the better ones.
It might seem like a quality of life feature to some, to me however it's an essential feature of swift and one of the better ones.
This means that, unless I'm missing something, you can't open your existing project in VSCode like you could with AppCode.
Overall, I'm unhappy with the tooling around Swift. The compiler is slow, the formatters and linters are worse than in the javascript-ecosystem, and since AppCode is sunset, there's only a single supported IDE which I dislike. I frequently run into issues where the compiler won't give me a useful error message until I simplify my code, and the SwiftUI previews don't seem to work at all.
[1]: https://github.com/swift-server/vscode-swift/issues/128#issu...