Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift is a more convenient Rust

blog.namangoel.com

Post reply on HN
Print view View original

241–250 of 318 posts

Re: Swift is a more convenient Rust

#241

Post by wsabihi »

tialaramex wrote: post #149
tgv wrote: post #80

Earlier quoted context omitted.

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.

It's not the Standard ML of New Jersey of course, like I was taught last century, but it looks like an ML to me. Rust has a sound type system, whereas a language like C++ inherits C's YOLO approach to typing. In Rust Vec > is just a counter. Really, that's not theory that'll just happen by default because of how type arithmetic works. In C++ you can't even write down an equivalent type, let alone say how it would be…

I've looked for this optimisation, and while it makes sense to me (Infallible is unhabitable ==> s: Option can only exist if s = None ==> all values in vector must be of the same value None that is known ahead of time ==> store a counter of how many Nones are in the vector instead of each None as an entry into a traditional vec), I cannot find any trace of such optimisation, whether by reading into the bytes backing the vector (with rustc -O / -C opt-level=3 to ensure this opt is triggered), or by calling `mem::size_of::>>()`.

Re: Swift is a more convenient Rust

#242

Post by alabhyajindal »

prmoustache wrote: post #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…

Exactly. Very annoying!

Re: Swift is a more convenient Rust

#243

Post by iknowstuff »

est31 wrote: post #240
lolinder wrote: post #136

Earlier quoted context omitted.

> Rust's memory management is not automatic, you have to explicitly manage memory. It's just made extremely easy for you by the language thanks to stuff like RAII, and there is checks that prevent memory safety violations like double free. But those checks won't prevent leaks, although the many lints do make it harder to forget about a value. By this logic no language on earth has automatic memory management. I've sp…

> Rust's memory management is automatic in that you can write entire Rust programs without once calling `free` manually. Personally I'd put the bar around not requiring people to distinguish different pointer types (owned vs shared). Languages like Java, JS, Python, Swift, Go, etc all have this "everything is a smart pointer" paradigm, (or at least the strong and widely used default). I'd say Rust is manually managed…

Swift has „weak” references for when you don’t want to bump the reference count. Does that make it manual?

Re: Swift is a more convenient Rust

#244

Post by pjmlp »

arghwhat wrote: post #236
pjmlp wrote: post #36

Earlier quoted context omitted.

Not at all, considering the decade of high level systems programming languages that predated the very thought of C coming into life. All with stack allocation.

Keyword is mainstream, so it’s not when the idea was invented - I think Forth popularized it? I can’t really comment on what counted as mainstream before C though. Not old enough for that.

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.

Re: Swift is a more convenient Rust

#245

Post by arghwhat »

pjmlp wrote: post #244
arghwhat wrote: post #236

Earlier quoted context omitted.

Keyword is mainstream, so it’s not when the idea was invented - I think Forth popularized it? I can’t really comment on what counted as mainstream before C though. Not old enough for that.

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 information - the point is to say that automatic memory management in mainstream languages predate rust by decades and is present in most languages, not "this specific language should get credit".

Re: Swift is a more convenient Rust

#246

Post by consteval »

est31 wrote: post #240
lolinder wrote: post #136

Earlier quoted context omitted.

> Rust's memory management is not automatic, you have to explicitly manage memory. It's just made extremely easy for you by the language thanks to stuff like RAII, and there is checks that prevent memory safety violations like double free. But those checks won't prevent leaks, although the many lints do make it harder to forget about a value. By this logic no language on earth has automatic memory management. I've sp…

> Rust's memory management is automatic in that you can write entire Rust programs without once calling `free` manually. Personally I'd put the bar around not requiring people to distinguish different pointer types (owned vs shared). Languages like Java, JS, Python, Swift, Go, etc all have this "everything is a smart pointer" paradigm, (or at least the strong and widely used default). I'd say Rust is manually managed…

Most GC langs have these features too they're just not in your face. Technically C# has true value types like C++.

Rust makes the distinction between stack and heap references, like C++. Other, more high-level languages don't - there's only one kind of reference, you can't take a reference to a stack object. Maybe you implement that by making all objects heap allocating (Java) or you just say they have to be copied every time (C# struct). That's really where the difference is.

There's a lot of juicy, juicy performance there. The problem is taking references to stack variables is problematic. Tracking heap objects with a GC or a ref counter is really trivial in comparison IMO, at least when you try to combine the systems.

Re: Swift is a more convenient Rust

#247

Post by consteval »

tialaramex wrote: post #222
pessimizer wrote: post #207

Earlier quoted context omitted.

> you can write entire Rust programs without once calling `free` manually. If you mean "drop," it's just syntactic sugar for calling a trait that manually deallocates the memory and that you're free to reimplement. It feels like people are equating "manual memory management" with "onerous memory management." People are usually going to want to do the boring thing with memory, and everything in the standard library by…

You can't call Drop::drop for type T at all. Try it if you don't believe me. It would be unacceptable to allow this because Drop::drop says it only takes a mutable reference &mut T (and indeed it does) but now the thing is destroyed, so, that wasn't just a mutable reference at all! You can call core::mem::drop but well, look at it, here's the code: pub fn drop (_x: T) {} Like, duh, we give it a T and then it doesn't…

To be fair I don't think this is enough to say automatic memory management, otherwise C++ would be automatic memory management too (and maybe it is, just poorly implemented?)

Re: Swift is a more convenient Rust

#248

Post by tialaramex »

consteval wrote: post #247
tialaramex wrote: post #222

Earlier quoted context omitted.

You can't call Drop::drop for type T at all. Try it if you don't believe me. It would be unacceptable to allow this because Drop::drop says it only takes a mutable reference &mut T (and indeed it does) but now the thing is destroyed, so, that wasn't just a mutable reference at all! You can call core::mem::drop but well, look at it, here's the code: pub fn drop (_x: T) {} Like, duh, we give it a T and then it doesn't…

To be fair I don't think this is enough to say automatic memory management, otherwise C++ would be automatic memory management too (and maybe it is, just poorly implemented?)

Yes, C++ has automatic memory management.

As with the rest of the language, the automatic memory mangement requires that your program has no mistakes - which requires inhuman amounts of care during implementation and testing. So, that's obviously a spectacularly bad idea, but it's still automatic memory management.

Re: Swift is a more convenient Rust

#249

Post by consteval »

nicce wrote: post #184
pzo wrote: post #173

Earlier quoted context omitted.

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.

> even many microsoft apps are build using React Native or Electron. I doubt that .NET has much to do with it. There are just many more JavaScript developers who know how to make UIs.

That's because the web is cross platform, truly. It's not a separate issue - the prevalence of the web is exactly due to platforms like .NET being limited. If .NET (and others) were cross platform much earlier, I think many applications would be true apps instead of web apps right now.

Re: Swift is a more convenient Rust

#250

Post by consteval »

tialaramex wrote: post #216
secondcoming wrote: post #128

Earlier quoted context omitted.

C++'s scoped enums are strict types.

Scoped enums ("enum class") are a very small improvement on the previous enum, the main thing they deliver is that they don't pollute your namespace as badly thanks to the scoping. Their notional status as "strict types" means nothing in a language which doesn't really care anyway, that's why memory_order::relaxed In Rust if you write nonsense like that it doesn't compile, these aren't comparable things. In C++ they'…

Oh come on now, everyone who programs in C++ knows operators don't work like that. Operators are tied to types, those enums don't have operator You also can't add them, or subtract them.

Yes behind the scenes their integers, but almost certainly this is the case in Rust too. You can SOMETIMES coerce an enum class instance back to an int if you do unsafe casts (on purpose).

Post reply on HN