@@theevilcottonballA windows user with a small drive? Well I wouldn’t say ‘that is new’ but definitely rarer. For context, I installed on Windows. It is actually not that bad, bloaty tools aside. Now on Linux, installing this thing is a fucking nightmare lol. Apple holds it back and it shows. I am considering its evil brother, Odin instead 😂.
But ODIN does not have super swift string interpilation. It kinda is C like (maybe better). Nah I'll hack C compiler to recognize \( as an escape sequence, and you can make a cursed print in C with just % and no type by cleverly combining NARGS macro with _Generic and so on.
@@theevilcottonball I don’t know if this is a joke but I do actually like swift string interpolation? And to answer above, Odin is not like Rust, more like C but Pascaly dna lol
Honestly, as somebody quite involved with Swift, I have to thank you for this stream! It was great, very good feedback. I hope the community takes this opportunity to fix and improve things. Swift is OSS so I'm sure we can make documentation and tooling better to get the Raylib speedrun down to a more reasonable time! ❤
In many cases it's Swift maintainers choose to put certain features in Clang/LLVM instead of Swift compiler itself (since Apple maintains and uses all of them).
The Swift compiler is built on LLVM and links libclang into itself so it can import C/C++ interfaces natively. Swift doesn’t compile to C or use clang to generate machine code.
Named parameters in functions are very handy because you usually can tell at a glance what the function uses those parameters for without having to look inside the function or into documentation Also inclusion of classes in pretty much non negotiable because Swift has to interop with Objective-C and Apple's SDKs written in objc
That last part made swift extremely better than C3 to interfacing with C!!? I hate Apple and its culture but that interfacing with C was awesome. I love that you don't need to rename C functions and not do that extern bs, but call them directly, like it should be. Please for the love of God, C3 compiler developers, you should have a better C interface than swift, that language is not even trying to be "a better C" you guys are! So be a better C by all means but make working with old C libraries a breeze!
To be fair near seamless interop with C is not that great of an achievement. I remember clearly importing dynamic libraries in python, and it was also very easy and straightforward. No static linking of course, but yeah, that should be a priority for any good modern systems language.
I guess they cared a great deal about C interoperability because Objective-C where most of their APIs are written is a strict superset of C that really doesn’t add that much that isn’t already implemented in C
I think the reason it has bad documentation for c interop is because Apple intends for people to use it in their ecosystem (xcode) which handles the language bridging by itself and provides an easier interface. Btw i think you missed the function param labeling, you looked at 'x:' and '_ x:', but it also does 'posX x:' kind of stuff too, it has its usecases. Also the use case for function param labels e.g. 'x:' that i used back when i did iOS dev was that it lets you overload functions, e.g. color(hex: string), color(r: int, g: int, b: int), color(r: int, g: int, b: int, a: int) etc.
@@owlmostdead9492just install nix packet manager and start a shell with nix-shell -p [packages] and your in a shell with the packages in your $PATH, containers are way more difficult than that. but if you're referring to nixos i agree but give it a serious try, you'll love it.
i see the vision. make the language as hard as possible to get running on your machine so you instantly get sunk cost fallacy so now you have to finish the project in swift. bravo tim
It's interesting to hear Chris Lattner talking today about Swift and about all the regrets he has. (For instance in a recent conversation with the creator of Roc) Of course, he has a new language to plug (Mojo)
And he is not making those mistakes: Mojo has very little syntax sugar at the moment (even the ones in Python), he is adamant about not adding sugar too early; is not being built in secret; has very dump type inference; starts out with Linux as the most supported platform; says a lot of "No!" to feature requests; All in all, very encouraging first steps. Edit: I have to add that the entire interview was about Mojo, it wasn't being plugged. When Chris Lattner says he is working on something the entire software industry holds its breath.
Here’s my perspective as an Apple developer: Swift has pretty syntax and is neat for simple things but if you do a larger project compile times are pretty terrible. Also generics are kinda underdeveloped,, language has too much magic and random things can be super slow when you don’t expect it (while other things are super fast) Binaries tend to be huge, and the language is extremely complicated imo with tons of special syntax and abstract stuff for special cases. Overall the language just feels bloated and “conceptually” ugly and complicated even if on the surface it looks very simple and pretty since the syntax is very concise. I think I’m more productive with Apples old la gauge Objective-C. It’s very verbose on the syntax but it’s conceptually very simple and pretty. Like the opposite of Swift. I like it more. (And I’m not just old, Swift was actually the first language I learned after python.)
Generics are supposed to be really powerful in Swift, but I would actually prefer a simple dumb generics, like in Java. Something that a simple coder without a phd in astrophysics could understand. Otherwise I totally agree, Swift is a complicated mess. The only way I can live with it, using it every day, is by avoiding all of its “advanced“ features.
Although Swift Package Manager is bad and I have written a replacement for it at my previous workplace, the how to interop with C/C++ guide was good, it just assumed you already know how to use SPM for Swift code or at least can read the error message, which tried to explain that if you have multiple targets then you need a subdirectory for each of them instead of placing your code at the root of the Sources directory. Swift 6 will bring the option to cross-compile statically linked binaries with musl, the current static linking flags are just experimental. Currently if you build on one machine, and try to run on a different machine with a different Linux version, it probably will crash. That's why docker is currently the preferred for Linux.
One reason why I got into Odin way back in 2018 was because I downloaded the compiler and it just worked. I also tried Zig around that time and it gave me some LLVM error instead of an executable.
Compilers in Docker containers are great because now we can switch to any version at any time. We can also collaborate with the exact same setup through our teams, and it improves CI/CD pipelines a lot. that's why.
It's always a lovely day when Tsoding uploads a language review (more commonly known as a "raylib speedrun"). It's really interesting to see his reaction and hear his thoughts about it. I found out about Pascal, Fortran and Ada through his videos (never tried them before but knew about them to be specific) and tried them out on my own and liked them, especially with the C interop. Im quite interested to see which language he might review next. 😀
Also, Swift and Ada taught me the two extremes of package managers. And if I design my own, Swift in particular black pilled me that a PM is a dumb idea 🤷
I don't know Ada at all, but I believe that C way (especially when you compile only one .c file for one .o at the time and after that everything done by linker which have nothing to do with the language that produced those .o files), everything you do in language should be able to be fitted into one signle text file: exporting and importing symbols (data and functions), maybe even letting the developer specify by which convention it should be done, but C FFI is obviously should be the default one; importing other files, probably in the way that it is possible to put it namespace but not by default creating it since it then be impossible to just read those includes as one stream if needed; etc.. I feel like types are generally broken in all popular languages or just unusable, and this especially obvious when language lets you to work on variables as on real data objects in memory and you are so abstracted away from what would be produced by compiler that it's just impossible to write simple code that translates 1to1-ish that program text will look like in the end.
This finding documents situation is not only in swift! Almost every “NEW” language that I learn how to import some external libraries just dumps “everything” to the document, but sometimes I just want to know “how it works“, not “how we should do it”.
It is quite trivial, that a language designed for apple products is dynamically linked when it is meant to run on a finite set of devices probably coming with the libraries necessary to run Hello World
I am a C dev, had to use Swift for a project. Really enjoyed once I wrote my own makefile. It sometimes feels like distopian future C (it still has #defines and other C looking features).
You poor poor bastard! After moving back from overseas, 10 years ago or so, I was without hardware so borrowed my dads old 2012 iMac 24", don't get me wrong, a beautiful machine to use, to 'consume' content ... but I wanted the challenge so I decided to re-write my old complex number visualiser (Mandelbrot on steroids with user input custom algorithms) just give it a range and it'd generate you a complex plane with whatever visualisation you could program and it did like HSV stuff for you, so that was nice ... in C#. Re-writing that in Swift (never mind objective-c) gave me grey hairs. On my chest. And Eyebrows.
i wonder how much more i have to learn every time i watch your videos, its honestly humbling. i feel like I would really just start by reading the documentation and you are 12 minutes into it and already just exposing all the shit behind the language, like whaaat? would be really cool to know what those "dependencies" of an executable you were talking about and stuff
Swift was the fourth language I've learned. Back in 2014, I only knew C++, Java, and a little bit of Delphi, and I found it pretty pleasent to use, especially compared with objective-C. The problem I guess is that they've changed the standard a lot, so old code wouldn't even work. And nowadays, people have way more choices.
The required parameter naming is done for Swift-to-Objective-C interop I think, where methods and their parameters are also specified by name on the call site. The C-interop is designed to be easy because it was the main focus for the first versions of Swift - to be able to call C and Obj-C functions/classes/methods from Swift (and sometimes even calling Swift from Obj-C) without jumping through hoops. It was required to "sell" the idea of Swift to Obj-C developers, similar to how Kotlin makes Java interop their priority. I was working with Swift 1, 2 in an iOS project back when Swift was new, and I've used the interop with Obj-C heavily (and easily at the same time).
@@nashiora That’s dogfooding the toolchain and locking out interchangeable alternatives. also, _maybe_ templates, but I’d rather not have the compiler go through C macros.
I think the "trash compiler" comment is a bit unfair. It's more unfamiliar interface than anything else. `cargo build` doesn't accept file name as argument, and `swift build` behave exactly the same (even the error messages are comparable).
“Hello! The time has come: today we are going to do Odin programming language!” Who else is waiting for mr zozing to start a stream with that saying? 😅
I wish Tsoding would do more of this. Pick a language without any prior knowledge and learn it on stream. The next languages I would suggest is: IDRIS.
The build system cruft is all about walking you into the Apple ecosystem. They can't afford to lose programmers, or control of their tools, which happened with Objective c because Next insisted on building their objective c compiler on GCC. Apple wants the utility of being able to lean on a open source project for resources, but not the responsibility of contributing back, because that might benefit someone other than them.
Where did the expectation that Swift is a system language (or wants to compete with Rust) come from?? Swift is a modern replacement for Objective-C, and therefore fully interoperable with C libraries, but it's used by tons of developers to build iOS and MacOS apps. It's an app development language, like C# or Kotlin, but way more efficient, with no garbage collector or fat runtime. Plus it was open sourced a long time ago.
Actually, that’s not technically true. ‘println’ can capture identifiers from string literals. Macros can’t do that in Rust. ‘println’ is a language feature pretending to be a macro.
Right, most of the genius are weird :-) They have weird OS which doesn't run Swift. That's why Apple creates docker images containing a Swift compiler inside. If you ever try Scala 3 (as you did with Swift), that'll be really great.
I didn't see a lot of boilerplate, at least in the main code. Which I actually consider a problem, Swift does a lot of inference which makes things very confusing
Around the 23 mark he's incorrect. You can take the cpp route and just add a preparser to gain whatever features you want without worrying about the compiler.
Swift tutorials in the meantime: open xcode and click next 3 times. Click on the triangle symbol which appears by default at the top left. If you dont see that, enable it in the "view" settings..
I'm only 15 minutes in so far.. and this 15 minutes reminds me of my pain trying to compile and run Java applications without an IDE... Also, hot take: The main issue with languages like C and the reason they are the way they are, is single pass compilation.
All include system in C is incompatible with multipass compilation, so single pass compilation can't be just replaced with something else. Thus, single pass compilation is not a cause, it's one of the effects of that extremely primitive include system which will break if you change anything.
A friend trying to watch this episode on iPhone shows "You cannot play this video" , "Sensitive content". Told him you have to be on Linux in order to watch it, or sign up for AWS and create a Linux server. Just saying 😜...
2:10 May be that docker image use for things like github action (CI/CD). and people use those things nowadays just to escape from managing package installation by them self.... they are not used to cloning repo and build the compiler, library by them self...
While working at company, I felt that docker is basically a shitty replacement for proper system administration with package manager and stuff and everyone just trust Docker that their garbage would work and isolate everything properly (spoiler: it is not, most of the time). So yeah, basically it's a compromise between developers who ate a corpo-pill and learned how to program in SlopLang while not being able even to setup their own laptop so it would not overheat because of shit 12GiB text editors that they're using to work.
Because he expects things to be simpler then they are and he is absolutely right, plus most languages use roughly the same compiler and linker ideas and he is able to do it successfully 99.99% of the time, most of us here would just give up at the first sign of trouble and many of us can't even do it without a IDE.
@@Argoon1981 I was also very surprised at his hatred of build systems, considering how much I love Gradle and similar systems... I guess low-level devs really just think different
Swift compiler did not finish MIT, sorry ;) They even did not eat their own dog food in a closed room, where no one will leave it until compiler will work as expected by interpreter, more than that, it looks like that swift designer team, interpreter team and compiler team all were a completely different software teams of developers ;)
