Live data from Hacker News

Swift is a more convenient Rust

blog.namangoel.com

101–110 of 318 posts

Re: Swift is a more convenient Rust

#101

Earlier quoted context omitted.

I’m aware of how boxing works in GHC, I learned it from Simon Marlowe. I don’t mean to be obtuse but I don’t see what that has to do with linear typing as a fucking weird mandatory default?

Why should every language occupy the same design space? Rust was shaped by Mozilla wanting a language to replace parts of Firefox with. A language that is low-level enough to give very high performance, enforces correctness through the type system, and yet has many abstractions so it feels modern and convenient to use. Rust doesn't have any automatic allocations. You can wrap every type in `Arc >` and treat it like a…

I think Rust is cool!

If it wasn’t actively seeking world domination I’d be like, cool let’s use that sometimes.

Rust is so hell bent on a Rust monoculture ranging from stuff like TRACTOR to actively opposing interop that a few of us who know our shit have to be like “easy now” once in a while.

I’m trying to decide between tiktoken and sentencepiece for a new vocabulary at the moment, and it would be easier in some ways to go with tiktoken.

But I want it to run faster than a fart at inference time, which means I’m linking libtorch, which means I’m writing C++.

And fuck, link to Rust from C++? Let’s take another look at the Google stuff.

Re: Swift is a more convenient Rust

#102
post #62
post #54

Earlier quoted context omitted.

I mean.. upgrading every 5-6 years is pretty normal outside the Apple world too, if you are a professional programmer. I don't expect my mom to upgrade her computer that much (she's happy with her 2011 (!) model iMac). But for those of us who use a computer every day, surely it makes sense to stay a bit cutting edge and it won't break the bank either since it is literally our income.

Is it sustainable?

The curve has flattened a lot - on mobile phones it is extremely noticeable, but I would say that apple’s M series is also the last significant jump in the laptop world (because laptops weren’t really ‘mobile’ before with such a bad battery life). So, yeah, I would say it can be reasonably sustainable.

Re: Swift is a more convenient Rust

#103

Earlier quoted context omitted.

perhaps a dumb question, but why does laziness imply boxing? or does 'boxing' in haskell mean something other than 'embed a simple bit of data in a fancy thing on the heap'?

A dramatic over-simplification is that a lazy value referenced by some continuation/thunk is hard to stack allocate in-situ. Now GHC does stack allocate, but it’s hard to count on without really aggressive hinting.

Funnily enough Rust supports exactly that pretty well with async.

An `async {}` block is not evaluated, but converted into a generator/state machine that lives on the stack, and that has to be advanced by calling a poll method. You can move it to the heap , but that does not happen automatically.

Sharing of values is obviously much more awkward due to mutability and no automatic cloning though.

Re: Swift is a more convenient Rust

#104
My interest in Rust stems from a very good Python interop. There's a very small handful of compiled languages with that property: Rust, C++, Nim (which is itself quite niche)... That's basically it as far as I know. Swift doesn't seem to tick that box.

I would happily have something 50-100% slower than C++/Rust with good interop, alas there seems to be very little / nothing. Cython for various reasons isn't ideal.

Re: Swift is a more convenient Rust

#105
post #17

Earlier quoted context omitted.

Not to praise Swift, but Swift and Xcode are unrelated projects. Saying that Swift is inconvenient because of Xcode issues is like saying C++/C# is inconvenient because of Visual Studio. You can install Swift on Linux if you want and code away, just like with Rust - but as it hasn't really caught on for anything other than building apps for the Apple ecosystem, it's not a particularly normal thing to do.

I’m pretty sure you need Xcode to compile Swift on macOS.

Everyone who has installed Homebrew has the official CLI Developer Tools (Homebrew installs them for you), and everyone who has those has a way to compile Swift.

Even if you don’t have Homebrew, the first time you try to run `swift` in a Terminal you’ll get a GUI prompt which lets you install the Developer Tools in two clicks.

Or you can run `xcode-select --install` (comes preinstalled, no Xcode needed).

Re: Swift is a more convenient Rust

#106

Hmmm...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…

> 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.

Re: Swift is a more convenient Rust

#107
post #69

Earlier quoted context omitted.

Is upgrading every 5-6 years to be able to write code considered normal in the Apple world? I'd been comfortably writing code in several languages using latest toolchains on a decade-old Intel machine just a few months ago, and was forced to upgrade because one of the components died. Otherwise I'd be using it for at least five more years.

I don't see why would anybody complain that the tools they bought 10 years ago don't magically do the things that the new tools are doing. It's not like the old tools stopped doing the things they do, right? Anyway, you sel the old machine and get the new one is pretty normal as the Apple devices tend to hold value.

let the record show that we're talking about 6 years

Re: Swift is a more convenient Rust

#108
post #53

> In fact, Swift treats enums as more than just types and lets you put methods directly on it You can do the exact same thing in Rust: impl Coin { fn valueInCents(&self) -> u8 { match self { Self::Penny => 1, Self::Nickel => 5, Self::Dime => 10, Self::Quarter => 25, } } }

Also they probably have their understanding upside down. What's going on here isn't that either Swift or Rust treats the enum types as "more than just types" but that they are indeed first class types, whereas in C and C++ what you get isn't a type at all, it's just a strange way to spell an integer.

I don't think Swift has union types, but Rust does and so does C++ and in both languages the unions, just like their main product type (C++ class, Rust struct) can have methods defined on them. The enumeration "types" in the C-like languages are special and it's because they really aren't proper types at all, they're just integers wearing a funny hat.

One of Rust's most important post 1.0 types MaybeUninit is actually a union, lots of Rust's important types, in 1.0 and since, are enums.

Re: Swift is a more convenient Rust

#109

Earlier quoted context omitted.

In my toy usage of swift I found it to run dramatically slower than rust. To even get something close to go or java speeds I had to compile with unchecked losing a lot of safety. Other than developing for an apple product, I don't know why I would ever pick swift and I wouldn't ever find myself deciding between rust and swift. It would be swift vs go. When considering rust it would be vs c++ or zig.

It depends on the axis you are considering. Swift might be slower than Rust, but it has an equally powerful type system. Swift and Go are much less similar than Swift and Rust in this regard.

I compare tools based on what they do not how I use them. I use mig and hot glue guns similarly, but I'd compare mig to stick or tig and a glue gun to tubes or gluesticks.

Re: Swift is a more convenient Rust

#110
Unrelated to the blogpost in question but I don't understand why the author is not using its own certificate if he is using his own domain.

Using an browser set to autodirect to https by default, all I get is some huge warning because the host use a certificate for svbtle, the service used to host this blog.

I know some people think that because some blogpost is public it can be served without ssl, but I think it is still nice to leave the choice of the reader to disclose or not to his provider and everyone in between what he is reading or not without seeing horrible warnings.

Post reply on HN