Earlier quoted context omitted.
> The languages that dominated the 2000s (Ruby, Python, Javscript, PHP) were all more or less derived from Smalltalk One of these is not like the others. Javascript derives from Lisp (first-class functions, lambdas, closures), not Smalltalk.
Python has those too, although with less convenient syntax (multiline functions (closures) can only be at statement locations).
Swift is a more convenient Rust
271–280 of 318 posts
Re: Swift is a more convenient Rust
#272Earlier quoted context omitted.
thanks, i'm bad at abbreviations and don't like when people just throw them like this without first using the whole term at least once
This is indeed an abbreviation, but it doesn’t convey meaning. At this point ML is just the name of the thing, it could not expand to anything and still convey the same meaning. If you don’t know ML, knowing what it stands for won’t help you. It’s like JS, either you know what JS is or you don’t. It’s not about what it means, it’s about what it is.
Re: Swift is a more convenient Rust
#273The article is outright wrong at times (like the need for Box or special status of enums), and is missing 80% reason to use Rust: it helps to ensure correctness of multi threaded synchronization at compile time. So no, Swift is not a "more convenient Rust". It is not Rust at all. It is more of a variant of C#/Java. And I haven't seen any indication that it is an improvement over either. The only reason to use Swift i…
Article may have overlooked this since it's been available in recent 5.x and becomes default in 6:
Swift 6 brings complete concurrency enabled by default
By far the biggest change is that complete concurrency checking is enabled by default. Unless you're very fortunate indeed, there's a very good chance your code will need some adjustment – it's no surprise the Swift team made it optional in earlier versions to give folks time to evaluate what's changing.
Swift 6 improves concurrency checking further, and the Swift team say it "removes many false-positive data-race warnings" that were present in 5.10. It also introduces several targeted changes that will do wonders to make concurrency easier to adopt – if you tried with 5.10 and found things just too gnarly to figure out, hopefully some of the changes in Swift 6 will help.
Easily the biggest is SE-0414, which defines isolation regions that allow the compiler to conclusively prove different parts of your code can run concurrently.
https://www.hackingwithswift.com/articles/269/whats-new-in-s...
Re: Swift is a more convenient Rust
#274Earlier quoted context omitted.
thanks, i'm bad at abbreviations and don't like when people just throw them like this without first using the whole term at least once
Expanding this abbreviation conveys zero information. It’s a programming language named ML, and if you haven’t heard of it then giving the etymology of the name isn’t going to help.
Re: Swift is a more convenient Rust
#275Earlier quoted context omitted.
This is indeed an abbreviation, but it doesn’t convey meaning. At this point ML is just the name of the thing, it could not expand to anything and still convey the same meaning. If you don’t know ML, knowing what it stands for won’t help you. It’s like JS, either you know what JS is or you don’t. It’s not about what it means, it’s about what it is.
You are forgetting that looking up abbreviations of 3 characters is already very hard, and it becomes almost impossible for the 2 character ones.
> A large part of why many people love Rust is that it's the first time they've used an ML family language.
You wouldn’t search "ML" but "ML family language".
Or copy paste the whole thing and ask ChatGPT what ML means in this context.
Re: Swift is a more convenient Rust
#276Earlier quoted context omitted.
Ok. Then manual memory applies to just heap memory management. It's not rocket science. If you are calling malloc/free to maintain your memory you're doing manual memory management. > You can also do manual memory management in Rust You can do Garbage Collection in C, it doesn't make it Garbage Collected language. You're confusing default memory management with what's possible. By your logic, Arena allocators can be…
> It's not rocket science. If you are calling malloc/free to maintain your memory you're doing manual memory management. Sure, and when I do the same in Rust I'm also doing manual memory management. So by your definition, both Rust and C are manual memory languages. > You're confusing default memory management with what's possible. Ah, so we care about the default, which I pressume is what the language semantics them…
You're being very thick on purpose. In Rust you need to reach for foreign functions to implement malloc/free.
> So by your definition, both Rust and C are manual memory languages.
No. By my definition what is the default semantics determines if it's manual or automatic. It's CS 101.
But if you want to play these semantics games, you just admitted C is GC language and thus unsuitable for kernel development.
> Uh, even in bog standard Java without any shenanigans you are using an "arena allocator".
No, no you aren't. At least not explicitly. I assume you mean GC, if it has or doesn't have arenas is implementation detail.
It also hinges on Wikipedia being correct that Arena IS manual memory management, which is unsubstantiated at best.
Re: Swift is a more convenient Rust
#277Earlier quoted context omitted.
Mainstream is whatever people could use between 1958 and 1969, as high level programming language, in whatever computers, universities and companies could afford. Goggle, Bing, DuckDuckGo, ChatGPT,... will gladly provide a list.
What people could use is not at all what mainstream is. You can use D, OCaml, F# and brainfuck, but they are not mainstream. To define what was mainstream we'd need to talk to people coding at the time and ask them about popularity, adoption, tooling availability, etc. and what languages people were likely to use rather than what was available. And no, I have no need for researching that as I have no use of the infor…
Besides, any Assembly programmer is well aware of what stack memory is all about, bring us even further back than 1958.
Re: Swift is a more convenient Rust
#278Hmmm...I disagree with a number of statements in the post but I think the following two hypotheses will make for more interesting discussion than some nitpicks: 1. A large part of why many people love Rust is that it's the first time they've used an ML family language. One of the innovations of Rust was to create a community that felt like home to Unix hackers who weren't programming language nerds. 2. Rust is the fi…
Rust is not really an ML language, is it? &mut is a very noticeable difference. Calling Rust, Scala, Swift and Kotlin ML seems to be taking it too far. Scala and Kotlin even have all the traditional OOP features. You might just as well put C++ in the ML list.
Re: Swift is a more convenient Rust
#279Earlier quoted context omitted.
> The languages that dominated the 2000s (Ruby, Python, Javscript, PHP) were all more or less derived from Smalltalk One of these is not like the others. Javascript derives from Lisp (first-class functions, lambdas, closures), not Smalltalk.
More than features, JS derives from Lisp because its author was a Scheme implementor. Otherwise function pointers are trivially done even in assembly language, and Smalltalk does have closures. Or maybe you think of the fact that JS uses prototype-based OOP, which makes it closer to what one would do with Scheme (something inspired from CLOS I guess) than Smalltalk ?
CLOS is an evolution from Flavors and similar Lisp packages, and outside Lisp, Julia would be the closest to it, in modern times, not counting Dylan.
Re: Swift is a more convenient Rust
#280Earlier quoted context omitted.
Swift is in its .NET Framework stage. I’m looking forward to Swift Core!
It might be too late. IMHO Microsoft also did transition too late and these days .NET is less relevant today than it used to be - even many microsoft apps are build using React Native or Electron.
While they do their best to open source .NET and related SDK tooling, the whole IDE story has been a bit of a mess, rewriting VS4Mac only to kill it shortly after the rewrite reached 1.0, C# DevKit under the same license as VS, the stuff that will never leave Windows or VS to Mac/Linux, Xamarin.Forms rewrite, while not taking GNU/Linux into consideration, and using Catalyst for macOS MAUI backend, dotnet watch drama, some of the ASP.NET features seen as way to sell Azure stuff,....
If you look closer, you will notice that usually the React Native or Electron based applications are from business units that are mostly C++ focused, that never had great love for .NET in first place.
While the team tries to cater to new generations with making .NET development a great experience, even with some constraints in cross-platform deployments, I think they would gain more by fixing the bad perception .NET still gets in UNIX shops, which those upper management decisions don't make any better, regardless of how great .NET happens to be.