Swift First Impression (as a .NET Developer)

Join this channel to get access to perks:
/ @amantinband

[@pwbm]

I believe that for us developers, learning a new language with the help of LLMs will be a less difficult task, especially when developing an MVP in a programming language we're not aware of. Great video, cheers!

[@amantinband]

Yeah 100 percent! I think it’s more about being able to read and debug code in any language than knowing the intrinsics of a specific language at this point

[@Scotthutchinsonking]

This was great Amichal , great to learn and look at other code compared to C#

[@farzadmf]

Thanks for sharing; very insightful and full of useful information

[@fkeyzuwu]

Well, I don't know swift, but i assume that LLMs would often tell you to structure some sort of complex architecture as a manager, since that is the most common approach, regardless of progamming language(maybe other than low level languages). As most of us know at this point, LLMs can't really reason with complex architectures yet, so I wouldn't trust them on that. Also, 2200 LOC can indeed make your intellisense slower 😂 Nice video tho!

[@obinnaokafor6252]

They don't have intellisense, what they have is basic code completion.

[@josephizang6187]

I really liked this video because I am in a similar place about C# and Swift. I have been learning swift and doing server side web development with vapor and almost everything you said I agree with. I think closures was where I found the swift dx to be way better. 2 👍man. I liked this video a lot.

[@yatsuk]

Swift features are not that impressive as the capture screenshot application itself

[@ainame0954]

Nice to see more developers give Swift a try! BUT please don't create Manager classes😂It's been hated by iOS devs too. Legacy projects tend to use that name. This actually highlights that Apple doesn't provide the standard architecture for apps. You may choose whatever architecture in the wild that meets your project's needs; MVVM, TCA, VIPER, etc... If so, you rarely need to create the fat manager classes.

[@eusouodouglas5730]

Great video! Thanks for sharing

[@moranmono]

Very nice video.

[@DavidSmith-ef4eh]

I was expecting it to be more polished tbh

[@nixoncode]

nixon nixon Nixon { nixon nixon nixon() { Nixon.Nixon.Nixon("Apart from money, You're gonna love it!"); } }

[@54Rights]

Could it be similar to TypeScript or F# ? 🤔...

[@kmcdo]

I've always been jealous of other languages enum implementation. I feel it is one of .net's weakest features

[@obinnaokafor6252]

Discrimination Union and Typed Union is coming to C#. Another amazing feature coming is the Roles and Extensions ❤❤❤

[@leo_dipp]

The only issue for me is...... it's from Apple, and I'm proud to say I have never used a single Apple product, and I plan to continue this way 🙂

[@luikcastrosilva3175]

Stay like that, once you buy a product from Apple is hard to go back to Android/windows

[@DaminGamerMC]

@@luikcastrosilva3175 I had apple for years, never going back

[@vivekkaushik9508]

​@@luikcastrosilva3175not true.

[@vivekkaushik9508]

​@@luikcastrosilva3175not true

[@shoooozzzz]

ignorance is bliss

[@chrisg5433]

I'm a C# /.NET developer, Swift looks horrible 🤣. As other languages go , I enjoy using Go.

[@Eirenarch]

It is obvious to me that being able to use the internal variable name is not an option, if it is made part of the contract then you can't change it, then that destroys one of the great benefits of the feature. Now why you must always name the arguments is beyond me, overloading on argument names seems absurd to me. Also enforcing code style this way is pointless. A style tool like editorconfig can always add this enforcement if the project owner wants it

[@realSimonPeter]

The logic of Swift is that the parameter labels are part of the *function name*. If you have a function like: func moveFile(from srcPath: String, to dstPath: String) then the name of that function is “moveFile(from:to:)”, and that’s how you’d refer to it to get a function pointer. The benefit of this is that the parameter labels always disambiguate what the argument actually is, so you don’t have to look up which order the dst and src arguments go in (for example). Obviously code completion will help you out when you’re writing it, but when reading it later it’s not always so clear. So the primary purpose of this is disambiguation, not overloading. Swift wouldn’t actually consider functions with the same base name but different parameter labels as “overloaded” in the traditional sense, because again the functions have fundamentally different canonical names. And of course you can opt out of using parameter labels in function names by using underscore, which is how all C functions are imported for FFI by default.

[@Eirenarch]

@@realSimonPeter I get the logic, I disagree that it is a better and more ergonomic choice.

[@PbPomper]

I don't really care about being concise. Clarity should always be the priority. I'll never understand this obsession with being concise. To me doing three things at once crammed into one line with weird syntax is not great at all. It's terrible and creates an unnecessary barrier to entry.