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

The Case for Rust in the base system

mail-archive.freebsd.org

Post reply on HN
Print view View original

141–150 of 155 posts

Re: The Case for Rust in the base system

#141

Post by steveklabnik »

pjmlp wrote: post #134
steveklabnik wrote: post #108

Earlier quoted context omitted.

> Since Apple are bad at doing more than one thing, they've settled on the idea of a single successor language, chosen under advice but by senior management. So, Swift. Apple has been using Rust for years, and I'm not aware of any decisions to move away from that, though given how secretive they are, I guess that could be a possibility. > So yes, Rust for NT is very possible. Rust is already being shipped (in preview…

Apple's John McCall makes a picture of where they are going with Swift in "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" https://www.youtube.com/watch?v=lgivCGdmFrw

Of course Apple continues to invest into Swift, making it better and writing more code in it. There's no doubt about that.

This is an hour long talk. I don't see anything in the slides that indicates that Apple management has decreed that Swift is the sole successor language to C++, forsaking all others, and winding down their Rust codebases. Could you help me find out where that is in this talk?

Re: The Case for Rust in the base system

#142

Post by pjmlp »

steveklabnik wrote: post #141
pjmlp wrote: post #134

Earlier quoted context omitted.

Apple's John McCall makes a picture of where they are going with Swift in "Introducing a Memory-Safe Successor Language in Large C++ Code Bases" https://www.youtube.com/watch?v=lgivCGdmFrw

Of course Apple continues to invest into Swift, making it better and writing more code in it. There's no doubt about that. This is an hour long talk. I don't see anything in the slides that indicates that Apple management has decreed that Swift is the sole successor language to C++, forsaking all others, and winding down their Rust codebases. Could you help me find out where that is in this talk?

There are zero references to Rust on that talk.

It is all about C, C++, Objective-C and how Apple is replacing them with Swift.

Rust isn't even shown on languages in use at Apple, https://youtu.be/lgivCGdmFrw?t=284

As for tracking down the exact minutes of each Swift reference, maybe I will try to find some time on my side to prove me right on the Internet.

Re: The Case for Rust in the base system

#143

Post by steveklabnik »

pjmlp wrote: post #142
steveklabnik wrote: post #141

Earlier quoted context omitted.

Of course Apple continues to invest into Swift, making it better and writing more code in it. There's no doubt about that. This is an hour long talk. I don't see anything in the slides that indicates that Apple management has decreed that Swift is the sole successor language to C++, forsaking all others, and winding down their Rust codebases. Could you help me find out where that is in this talk?

There are zero references to Rust on that talk. It is all about C, C++, Objective-C and how Apple is replacing them with Swift. Rust isn't even shown on languages in use at Apple, https://youtu.be/lgivCGdmFrw?t=284 As for tracking down the exact minutes of each Swift reference, maybe I will try to find some time on my side to prove me right on the Internet.

What I am saying is that you aren't wrong, just that it comes across as a bit of a non-sequitur. The comment I was replying to says that Swift is the only language for the future. I am pushing back about that and that only. Of course they're not abandoning Swift. Of course they're moving away (in many cases) from C and C++. That doesn't imply that Swift is the only tool they will use, or that they're reversing course from the codebases they've already ported to Rust.

Re: The Case for Rust in the base system

#144

Post by nyssos »

nicoburns wrote: post #122
kagakuninja wrote: post #114

Earlier quoted context omitted.

>2. got amazing, highly flexible and generalized iterator and monad support (you can use iterator methods on monads), basically second only to Haskell itself, that compiles down to the equivalent of hand written assembly code loops As I understand it, Rust lacks do-notation and higher-kinded types, making it hard to have true monads in Rust. Scala would be the language with monad support comparable to Haskell.

My understanding is that Rust lacks the ability to have a generic Monad abstraction like Haskell and Scala, but that it certainly has monads (e.g Option, Result, Vec, etc). And indeed that even languages like JavaScript have lots of monads (e.g. Promise) it's just that these are likewise not abstractable. I believe that a monad is basically any container that has both a constructor and a flat_map function (and there…

> (and there may be one other requirement that I've forgotten)

`map: forall a b . (a -> b) => (m a -> m b)` and `pure: forall a . a -> m a`, plus some (mostly very natural) compatibility conditions between the three: `flatMap(pure)` does nothing, `map` takes the identity to the identity, etc.

Re: The Case for Rust in the base system

#145

Post by yencabulator »

nocombination wrote: post #82
richardwhiuk wrote: post #80

Earlier quoted context omitted.

I assume you are still programming in COBOL?

It's not what you program in that matters—it's how you test and ensure quality results.

It's really hard to test for security.

It's much more feasibly to be secure by construction.

Re: The Case for Rust in the base system

#146

Post by kevans91 »

bitfilped wrote: post #130
GrumpySloth wrote: post #33

Earlier quoted context omitted.

Not after I added the second paragraph. ;)

Don't forget (f)lua is in base :)

To be fair, for the vast majority of FreeBSD users flua is essentially nonexistent; it was pushed off into /usr/libexec and renamed so that it doesn't get used by consumers of base in such a way that it can't be updated.

Re: The Case for Rust in the base system

#147

Post by steveklabnik »

faitswulff wrote: post #8

> fusefs tests. Absolutely impossible to do in C. I considered Rust, but went with C++ so they could live in base. They are too closely coupled to fusefs(5) to live out-of-tree. Can anyone comment on why this is impossible in C?

The OP has since elaborated:

> I don't think anybody has claimed this yet. But I _have_ made a similar claim, that some things can't be written in C. I'll elaborate on the project that started this thread: the fusefs test suite. When I designed the fusefs test suite, I based it around the priniciple of Mocking. Each test case has a client thread that does normal file system access, and a server thread that implements a fuse file server. But it isn't a full implementation of a fuse file server; it's just a shim around a mock object. For each test case, the file server's behavior is programmed with expectations. The mocking technique is so limited and awkward to use in C that almost nobody bothers. Just compare the documentation for CMockery (C) with Mockall (Rust). C++'s Googlemock is somewhere in between.

https://lists.freebsd.org/archives/freebsd-hackers/2024-Janu...

Re: The Case for Rust in the base system

#148

Post by Ferret7446 »

steveklabnik wrote: post #147
faitswulff wrote: post #8

> fusefs tests. Absolutely impossible to do in C. I considered Rust, but went with C++ so they could live in base. They are too closely coupled to fusefs(5) to live out-of-tree. Can anyone comment on why this is impossible in C?

The OP has since elaborated: > I don't think anybody has claimed this yet. But I _have_ made a similar claim, that some things can't be written in C. I'll elaborate on the project that started this thread: the fusefs test suite. When I designed the fusefs test suite, I based it around the priniciple of Mocking. Each test case has a client thread that does normal file system access, and a server thread that implements…

Mocking is a horrible principle. It is probably the worst of the various types of test doubles, in terms of the kind of test design they imply. Software engineering would be significantly better off, IMO, if mocking were so awkward that no one bothers to do it, ever, in any language.

Re: The Case for Rust in the base system

#149

Post by pjmlp »

steveklabnik wrote: post #143
pjmlp wrote: post #142

Earlier quoted context omitted.

There are zero references to Rust on that talk. It is all about C, C++, Objective-C and how Apple is replacing them with Swift. Rust isn't even shown on languages in use at Apple, https://youtu.be/lgivCGdmFrw?t=284 As for tracking down the exact minutes of each Swift reference, maybe I will try to find some time on my side to prove me right on the Internet.

What I am saying is that you aren't wrong, just that it comes across as a bit of a non-sequitur. The comment I was replying to says that Swift is the only language for the future. I am pushing back about that and that only. Of course they're not abandoning Swift. Of course they're moving away (in many cases) from C and C++. That doesn't imply that Swift is the only tool they will use, or that they're reversing course…

So I got some time to go through the video,

- Overview of C, C++, Objective-C and Objective-C++ history on Apple platforms

From https://youtu.be/lgivCGdmFrw?t=169 to https://youtu.be/lgivCGdmFrw?t=306

- How Swift fits into the picture

https://youtu.be/lgivCGdmFrw?t=317

Key statements.

"Apple is very serious making Swift viable anywhere on this chart..."

Meaning a chart showing "UI Apps, Portable utililities, Platform libraries, Portable libraries, Kernel and below."

"...that is because we feel we need a successor language anywhere on this chart, so we are putting Swift at the kernel and below, as well as, platform libraries, and not just UI application, and we think it is a very important future for the language, we are very commited to it"

Up to https://youtu.be/lgivCGdmFrw?t=352

- Basic Expectations

"We need to focus on adding one sucessor language"

"Every language we add comes with extra complexity, in terms of tooling, XCode support, build system support and so on, as well as, language problems making them interoperate"

"We have four precessor languages, we don't want four sucessor languages"

"Should be accessible as first language, for people coming into our platform"

From https://youtu.be/lgivCGdmFrw?t=360 to https://youtu.be/lgivCGdmFrw?t=411

"At the same time, if we want to make it usable in kernel, we need to provide enough control to make it usable in such environments"

"In particular that means being able to scale down to a minimal runtime"

From https://youtu.be/lgivCGdmFrw?t=420 to https://youtu.be/lgivCGdmFrw?t=493

- Problems with C

https://youtu.be/lgivCGdmFrw?t=493

- Overview of Swift

"So we feel pretty strongly, obviously at Apple our sucessor language is Swift and I am here to talk about features of Swift, both to try to sell you on to it, but also to talk about the things we think are pretty necessary and the ways in which a programming language can support, you know, clear code, safer and more correct code."

"Like I said before, Apple has always intended for Swift to be a sucessor language for all of our predecessors, from the top to the bottom of our stack, accessible to novices, powerful enough for experts, it is real a tall order.

From https://youtu.be/lgivCGdmFrw?t=1996 to https://youtu.be/lgivCGdmFrw?t=2042

Quite clear that Swift is the future and zero mentions of Rust.

Re: The Case for Rust in the base system

#150

Post by justincredible »

pjmlp wrote: post #132
kjs3 wrote: post #115

Earlier quoted context omitted.

the many places that have my social security number So COBOL everywhere it is. Let it be written, let it be done.

Actually it isn't susceptible to C's security flaws, and is a compiled language, with relatively good performance. :)

[dead]
Post reply on HN