Speculative: Rust for base system components

classic Classic list List threaded Threaded
132 messages Options
1234567
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Conrad Meyer-2
Hi Garance,

On Tue, Jan 1, 2019 at 3:18 PM drosih <[hidden email]> wrote:
> Brian's simple experiment is a simple experiment.  It's interesting,
> but hardly the definitive word in evaluating a language.

Sure, that's fair enough.  On the other hand, it matches every other
report of the compiler and language I've heard, even from advocates of
the language.  Compiler performance was on the Rust roadmap for 2017
(incremental rebuilds added during 2017) and 2018:

https://blog.rust-lang.org/2017/02/06/roadmap.html
https://blog.rust-lang.org/2018/03/12/roadmap.html

In particular I think the Rust 2018 community survey (URL below) is
informative.  Scroll to the figure just above "Many non-users
responded that they did want to learn Rust, but there were factors
that slowed them down."  Leading reasons for people who had used Rust
but no longer did were: (1) Rust is too intimidating, too hard to
learn, or too complicated; (3) Rust doesn't solve a problem for me;
and (6) Switching to Rust would slow me down too much.  One of the top
10 free-form comments for November 2018 is "improve compile times."
It's still a problem.

https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html

> I thought the 'ripgrep' program seemed like an interesting one
> to look at.  Compare how fast it works to how fast our grep works.

It's not a great comparison; our grep (either GNU grep 2.5.1 or
BSDgrep) is just not very good and must conform to POSIX.

'ag' (pkg install the_silver_searcher) is a more interesting
comparison, with similar ability to exclude files automatically.  Both
are source-code focused; by default, both .gitignore and similar files
to exclude files and directories.  Both share similar goals, probably
inspired by 'ack' (which is slower than both): high real-world
performance, threaded search, and fast, non-PCRE regular expressions
by default.

On the other hand, grep(1) must maintain POSIX compatibility, which
makes for significantly slower defaults in many searches.  This limits
the impact of improving the performance of the internals on
real-world, default-behavior search — because excluding files is a
huge boon for ag/rg.

In my experience, ripgrep is much faster than our grep, but pretty
similar to 'ag'.  Both have a comparable feature set; if anything, ag
has more features IME.

The binary sizes are interesting:

-r-xr-xr-x 3 root wheel  113640 Nov  4 15:47 /usr/bin/grep*
-r-xr-xr-x 1 root wheel   89104 Oct 28 14:24 /usr/local/bin/ag*
-rwxr-xr-x 1 root wheel 4284416 Oct 29 05:12 /usr/local/bin/rg*

All are dynamically linked and stripped amd64 binaries.  Ripgrep
(Rust) is 48x the binary size of ag and 37x that of grep(1).  Like
grep(1), 'ag' is written in C.

Of that 4 MB binary, 2805414 bytes of ripgrep are ".text".  Other
major contributors are .rodata, .eh_frame and .rela.dyn at 540kB,
300kB, and 240kB respectively.

Of the 89 kB ag binary, 37 kB is ".text", 14kB is ".rodata," and 13kB
is ".data".  I think this difference is illustrative and reasonably
representative.

Best,
Conrad
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

freebsd-hackers mailing list
On 01/01/2019 19:35, Conrad Meyer wrote:

> The binary sizes are interesting:
>
> -r-xr-xr-x 3 root wheel  113640 Nov  4 15:47 /usr/bin/grep*
> -r-xr-xr-x 1 root wheel   89104 Oct 28 14:24 /usr/local/bin/ag*
> -rwxr-xr-x 1 root wheel 4284416 Oct 29 05:12 /usr/local/bin/rg*
>
> All are dynamically linked and stripped amd64 binaries.  Ripgrep
> (Rust) is 48x the binary size of ag and 37x that of grep(1).  Like
> grep(1), 'ag' is written in C.
>
By default, the dynamic linking in rust binaries are limited to crt
unless a non-default flag is passed to rustc. Thus, this is effectively
static linking, albeit at an earlier stage like llvm-link(1). Rust is
not alone; golang is almost identical in this regard, by default.

ag also has next to no external dependencies at all, compared to
ripgrep's laundry list of crates it uses.

--
Charlie Li
Can't think of a witty .sigline today…

(This email address is for mailing list use only; replace local-part
with vishwin for off-list communication)


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

freebsd-hackers mailing list
In reply to this post by Eric McCorkle-2
Quoting Eric McCorkle <[hidden email]> (from Sun, 30 Dec 2018  
21:18:33 -0500):

> Before I begin, I want to be clear that everything here is in the realm
> of speculative, long-term discussion.  My goal is to start a
> conversation, not to propose anything concrete right now.
>
>
>
> I've talked at several conferences about the possibility of bringing the
> Rust programming language into the base system, with the intent of
> making it a viable implementation language for parts of the base system.
>  I believe the potential security and stability benefits of doing this
> are *substantial*.  This would obviously be a serious undertaking, but I
> think the benefits are worth the cost.  For the rest of this mail, I'll
> outline my position and present the important facts that support it.
After reading this thread I see several issues here. The suggestion from
me here is to remove excuses.

The issues I see (no particular order, and you can replace "rust" by
anything which may or may not be better suited for the task):
  - chicken and egg problem (solution: make it possible to use it easily,
    e.g. bsd.rust.mk (name doesn't matter) as a port to try it, wiki page
    to explain how to make it possible + HOWTOs regarding where and how to
    use it (library/program/kernel module/...), links to code examples)
  - if all what you know is a hammer, then every problem looks like a nail
    (a lot of people seem to talk about things they have never seen...
    me included, solution: links to examples / snippets of how what we do
    currently can be done better with rust and descriptions about what rust
    is doing for people which learned C 20 years ago and never looked at
    something else and are not "language nerds")
  - performance matters, at the same time it doesn't if we want safe code
    (we don't talk about replacing everything with rust, time critical
    parts can stay in C, new items may benefit from rust... solution: show
    how to get (enough) speed, show how to reduce size (e.g. name this
    non-standard compiler option instead of having people talking about
    one), show that you get more (safety) with less (code)... this is
    overlapping with the previous item)

You will not get a endorsement here, you will not get an approval here,
and you should ignore people which talk down the benefits. If you believe
in your opinion you need to remove excuses. Make a little item list of
what is needed. Make it public (e.g. in the wiki). Start with providing
possibilities. Mention what you have (When you have at least something)
in the periodic status reports, get some people to join to try it,
provide some interesting additions or replacements to let people evaluate
it.


Bye,
Alexander.

--
http://www.Leidinger.net [hidden email]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [hidden email]  : PGP 0x8F31830F9F2772BF

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Johannes Lundberg
In reply to this post by Conrad Meyer-2

On 1/2/19 12:35 AM, Conrad Meyer wrote:

> Hi Garance,
>
> On Tue, Jan 1, 2019 at 3:18 PM drosih <[hidden email]> wrote:
>> Brian's simple experiment is a simple experiment.  It's interesting,
>> but hardly the definitive word in evaluating a language.
> Sure, that's fair enough.  On the other hand, it matches every other
> report of the compiler and language I've heard, even from advocates of
> the language.  Compiler performance was on the Rust roadmap for 2017
> (incremental rebuilds added during 2017) and 2018:
>
> https://blog.rust-lang.org/2017/02/06/roadmap.html
> https://blog.rust-lang.org/2018/03/12/roadmap.html
>
> In particular I think the Rust 2018 community survey (URL below) is
> informative.  Scroll to the figure just above "Many non-users
> responded that they did want to learn Rust, but there were factors
> that slowed them down."  Leading reasons for people who had used Rust
> but no longer did were: (1) Rust is too intimidating, too hard to
> learn, or too complicated; (3) Rust doesn't solve a problem for me;
> and (6) Switching to Rust would slow me down too much.  One of the top
> 10 free-form comments for November 2018 is "improve compile times."
> It's still a problem.
>
> https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html
>
>> I thought the 'ripgrep' program seemed like an interesting one
>> to look at.  Compare how fast it works to how fast our grep works.
> It's not a great comparison; our grep (either GNU grep 2.5.1 or
> BSDgrep) is just not very good and must conform to POSIX.
>
> 'ag' (pkg install the_silver_searcher) is a more interesting
> comparison, with similar ability to exclude files automatically.  Both
> are source-code focused; by default, both .gitignore and similar files
> to exclude files and directories.  Both share similar goals, probably
> inspired by 'ack' (which is slower than both): high real-world
> performance, threaded search, and fast, non-PCRE regular expressions
> by default.
>
> On the other hand, grep(1) must maintain POSIX compatibility, which
> makes for significantly slower defaults in many searches.  This limits
> the impact of improving the performance of the internals on
> real-world, default-behavior search — because excluding files is a
> huge boon for ag/rg.
>
> In my experience, ripgrep is much faster than our grep, but pretty
> similar to 'ag'.  Both have a comparable feature set; if anything, ag
> has more features IME.
>
> The binary sizes are interesting:
>
> -r-xr-xr-x 3 root wheel  113640 Nov  4 15:47 /usr/bin/grep*
> -r-xr-xr-x 1 root wheel   89104 Oct 28 14:24 /usr/local/bin/ag*
> -rwxr-xr-x 1 root wheel 4284416 Oct 29 05:12 /usr/local/bin/rg*
>
> All are dynamically linked and stripped amd64 binaries.  Ripgrep
> (Rust) is 48x the binary size of ag and 37x that of grep(1).  Like
> grep(1), 'ag' is written in C.


Hi


Rust by default statically link everything in executable binaries. This
is comparable to statically link in libc and all other dependencies in
your C program. You can have Rust programs link against shared rust
libraries (std, etc) and get the size down to basically same as C.


If Rust is used in base and everything is built at the same time, with
same version compiler, it would make sense to link dynamically I think.


Switching topic a bit. Just wanted to also add my contribution, a simple
sysctl Rust library https://github.com/johalun/sysctl-rs .


Cheers

>
> Of that 4 MB binary, 2805414 bytes of ripgrep are ".text".  Other
> major contributors are .rodata, .eh_frame and .rela.dyn at 540kB,
> 300kB, and 240kB respectively.
>
> Of the 89 kB ag binary, 37 kB is ".text", 14kB is ".rodata," and 13kB
> is ".data".  I think this difference is illustrative and reasonably
> representative.
>
> Best,
> Conrad
> _______________________________________________
> [hidden email] mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[hidden email]"
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Garance A Drosehn-2
In reply to this post by Conrad Meyer-2
On 1 Jan 2019, at 19:35, Conrad Meyer wrote:

> Hi Garance,
>
> On Tue, Jan 1, 2019 at 3:18 PM drosih <[hidden email]> wrote:
>> Brian's simple experiment is a simple experiment.  It's interesting,
>> but hardly the definitive word in evaluating a language.
>
> Sure, that's fair enough.  On the other hand, it matches every other
> report of the compiler and language I've heard, even from advocates of
> the language.  Compiler performance was on the Rust roadmap for 2017
> (incremental rebuilds added during 2017) and 2018:
>
> https://blog.rust-lang.org/2017/02/06/roadmap.html
> https://blog.rust-lang.org/2018/03/12/roadmap.html
>
> In particular I think the Rust 2018 community survey (URL below) is
> informative.  Scroll to the figure just above "Many non-users
> responded that they did want to learn Rust, but there were factors
> that slowed them down."  Leading reasons for people who had used Rust
> but no longer did were: (1) Rust is too intimidating, too hard to
> learn, or too complicated; (3) Rust doesn't solve a problem for me;
> and (6) Switching to Rust would slow me down too much.  One of the top
> 10 free-form comments for November 2018 is "improve compile times."
> It's still a problem.
>
> https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html

There was a lot of good information in this message, including the
parts I have deleted just to keep this message reasonably short.
Thanks!

So my gut reaction to this is that it seems too early for the freebsd
project to make any significant commitment to rust.  Some of us could
get more experience with it, and then maybe we could reconsider it
in a year or two.  It's frustrating that these things take so much
time to evaluate, but that's just the way it is.  It takes a lot of
work (and thus a lot of time) for a new language to catch up with
all the time which has been put into compilers for established
languages.

I've also found some of the videos for explaining Rust to be rather
intimidating, even when done by developers in the Rust community.
But I do think it's trying a lot of interesting new ideas for a
systems-programming language, and thus I hope to gain some more
experience with it for myself.  Now I just need to find some copious
spare time that I can devote to that!

--
Garance Alistair Drosehn                =     [hidden email]
Senior Systems Programmer               or   [hidden email]
Rensselaer Polytechnic Institute;             Troy, NY;  USA
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Garance A Drosehn-2
In reply to this post by Johannes Lundberg
On 2 Jan 2019, at 6:06, Johannes Lundberg wrote:

> On 1/2/19 12:35 AM, Conrad Meyer wrote:
>>
>> All are dynamically linked and stripped amd64 binaries.  Ripgrep
>> (Rust) is 48x the binary size of ag and 37x that of grep(1).  Like
>> grep(1), 'ag' is written in C.

>
> Rust by default statically link everything in executable binaries.
> This is comparable to statically link in libc and all other
> dependencies in your C program. You can have Rust programs link
> against shared rust libraries (std, etc) and get the size down
> to basically same as C.
>
> If Rust is used in base and everything is built at the same time,
> with same version compiler, it would make sense to link dynamically
> I think.
>
> Switching topic a bit. Just wanted to also add my contribution,
> a simple sysctl Rust library
>    https://github.com/johalun/sysctl-rs .

Personally I think it's interesting and helpful to see some more
projects like this, so we can get a better understanding of how
well the language works for systems-level programs.  I'm going to
take a look at this, just for my own curiosity.   Thanks!

--
Garance Alistair Drosehn                =     [hidden email]
Senior Systems Programmer               or   [hidden email]
Rensselaer Polytechnic Institute;             Troy, NY;  USA
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Johannes Lundberg

On 1/2/19 11:28 AM, Garance A Drosehn wrote:

> On 2 Jan 2019, at 6:06, Johannes Lundberg wrote:
>
>> On 1/2/19 12:35 AM, Conrad Meyer wrote:
>>> All are dynamically linked and stripped amd64 binaries.  Ripgrep
>>> (Rust) is 48x the binary size of ag and 37x that of grep(1).  Like
>>> grep(1), 'ag' is written in C.
>> Rust by default statically link everything in executable binaries.
>> This is comparable to statically link in libc and all other
>> dependencies in your C program. You can have Rust programs link
>> against shared rust libraries (std, etc) and get the size down
>> to basically same as C.
>>
>> If Rust is used in base and everything is built at the same time,
>> with same version compiler, it would make sense to link dynamically
>> I think.
>>
>> Switching topic a bit. Just wanted to also add my contribution,
>> a simple sysctl Rust library
>>     https://github.com/johalun/sysctl-rs .
> Personally I think it's interesting and helpful to see some more
> projects like this, so we can get a better understanding of how
> well the language works for systems-level programs.  I'm going to
> take a look at this, just for my own curiosity.   Thanks!
>
You're welcome! Oh, I forgot my most recent tool:

https://github.com/johalun/pperf

It's similar to iperf and useful for simulating many clients making
short connections to ranges of IP addresses. The source code is
ridiculously short and simple, showing how powerful Rust is when writing
(safe and bug free) multi-threaded programs (of course with the use of
some 3rd party crates).


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Wojciech Puchar-8
In reply to this post by Garance A Drosehn-2
>> <snip>
>>
>> Brian's simple experiment [1] demonstrates that "zero-cost" is
>> more of an aspiration (and a very long term one, perhaps) than
>> a hard fact ;-)
>
> Brian's simple experiment is a simple experiment.  It's interesting,
> but hardly the definitive word in evaluating a language.  We need
> more real-world experience with serious programs before dismissing

wrong. you have to PROVE it's useful, not prove it's not useful.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Garance A Drosehn-2
On 2 Jan 2019, at 8:54, Wojciech Puchar wrote:

>>> <snip>
>>>
>>> Brian's simple experiment [1] demonstrates that "zero-cost" is
>>> more of an aspiration (and a very long term one, perhaps) than
>>> a hard fact ;-)
>>
>> Brian's simple experiment is a simple experiment.  It's interesting,
>> but hardly the definitive word in evaluating a language.  We need
>> more real-world experience with serious programs before dismissing
>
> wrong. you have to PROVE it's useful, not prove it's not useful.

Please read the rest of my replies before getting yourself worked
up over whatever it is that you think I am trying to prove.

Note that I'm having some trouble with my email client over the
last few days, so read all emails (no matter how oddly formatted)
which are by either [hidden email] or '[hidden email]' (even if
it doesn't include my first name in it).

If you read them all, you'll hopefully realize that I am not
trying to force anyone to do any specific thing, and thus I don't
have to prove much of anything.

--
Garance Alistair Drosehn                =     [hidden email]
Senior Systems Programmer               or   [hidden email]
Rensselaer Polytechnic Institute;             Troy, NY;  USA
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Cy Schubert-4
In reply to this post by Eric McCorkle-2
In message <[hidden email]>, Eric
McCorkl
e writes:

> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
> --tu7wwqLaLNvV59iK66RVuCN4u9LNuo2ra
> Content-Type: multipart/mixed; boundary="40zQJvQINjrS8i7U0w9C4z0duC53dUJgc";
>  protected-headers="v1"
> From: Eric McCorkle <[hidden email]>
> To: [hidden email]
> Message-ID: <[hidden email]>
> Subject: Re: Speculative: Rust for base system components
> References: <[hidden email]>
> In-Reply-To: <[hidden email]>
>
> --40zQJvQINjrS8i7U0w9C4z0duC53dUJgc
> Content-Type: text/plain; charset=utf-8
> Content-Language: en-US
> Content-Transfer-Encoding: quoted-printable
>
> On 12/31/18 11:56 PM, Cy Schubert wrote:
> > What would having another language in base buy us? This reminds me of a=
>  couple of months ago at OpenHack Victoria someone was trying to convince=
>  me that the kernel needed a JavaVM. (Sure we each had a few beers) but t=
> he similarity of this discussion doesn't escape me. Kernel modules and fu=
> nctions written in java^H^H^H^H rust: why?
>
> I don't think that's a fair comparison at all.  Rust is a systems
> language built around zero-cost abstractions that is usable for
> developing real embedded code.  Java is a completely different animal,
> and there is no reasonable case for a Java VM in the kernel/loader.

What is the proposal then? Just to have another language in base? If
it's just that, wouldn't the port suffice?

>
> I'm all for discussion and criticism of this, that's why I posted it,
> but I don't think these kinds of false equivalences are helpful.

Actually it is helpful. Without a solid proposal of a new feature or
userland utility to be imported into base that requires the support of
a language not already in base, the implication of the original email
starting this thread was to rewrite FreeBSD using rust. There is
equivalence as the argument that evening was, "there are more Java
developers than C developers and replacing C with Java would benefit by
adding to the pool of possible contributors."

In reality we should rely more on ports. Over the years this business
has become more fragmented. Each year we see new languages being
developed and used. Importing new shiny objects into base is
unsustainable. IMO the momentum is behind containerization,
specifically kubernetes and docker-like containers. That is today. The
next year or two will introduce new technologies and shiny objects
which we will likely need to introduce here to remain relevant. We
should be looking to reduce the footprint of base, introduce new
technologies in ports (ports are much easier to build from scratch,
maintain, and update than base). Additionally the idea of meta-ports
that install groups of packages would make building purpose-built
systems a breeze for our user base, similar to what anaconda does, like
a FreeBSD based LAMP (FAMP) stack package that installs all the
necessary bits with one pkg install command.

In summary we should pair down base and use ports to our advantage.
Unless the proposal is to add some feature written in rust that cannot
live in ports or if the proposal is to rewrite FreeBSD into rust (which
I vehemently disagree with), there is no reason to consider adding rust
to base.


--
Cheers,
Cy Schubert <[hidden email]>
FreeBSD UNIX:  <[hidden email]>   Web:  http://www.FreeBSD.org

        The need of the many outweighs the greed of the few.




_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Wojciech Puchar-8
> necessary bits with one pkg install command.
>
> In summary we should pair down base and use ports to our advantage.
> Unless the proposal is to add some feature written in rust that cannot
> live in ports or if the proposal is to rewrite FreeBSD into rust (which
> I vehemently disagree with),

Why do you disagree?! Let others do it, or even reimplement it in java or
visual basic.

But as a separate project.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Igor Mozolevsky-2
On Thu, 3 Jan 2019 at 10:18, Wojciech Puchar wrote:

>
> > necessary bits with one pkg install command.
> >
> > In summary we should pair down base and use ports to our advantage.
> > Unless the proposal is to add some feature written in rust that cannot
> > live in ports or if the proposal is to rewrite FreeBSD into rust (which
> > I vehemently disagree with),
>
> Why do you disagree?! Let others do it, or even reimplement it in java or
> visual basic.
>
> But as a separate project.


... and call it RustyBSD or CRustyBSD (because there will still be C) :-))

--
Igor M.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Wojciech Puchar-8
>>
>> Why do you disagree?! Let others do it, or even reimplement it in java or
>> visual basic.
>>
>> But as a separate project.
>
>
> ... and call it RustyBSD or CRustyBSD (because there will still be C) :-))
let they call it whatever they like.

Just not try to turn FreeBSD upside down.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Eric McCorkle-2
In reply to this post by Cy Schubert-4
On 1/2/19 1:29 PM, Cy Schubert wrote:

>> I'm all for discussion and criticism of this, that's why I posted it,
>> but I don't think these kinds of false equivalences are helpful.
>
> Actually it is helpful. Without a solid proposal of a new feature or
> userland utility to be imported into base that requires the support of
> a language not already in base, the implication of the original email
> starting this thread was to rewrite FreeBSD using rust.

That doesn't represent what I wrote at all, and is bordering on a
strawman argument.  Nobody to my knowledge is suggesting rewriting
everything, nor would that be possible.

> In reality we should rely more on ports. Over the years this business
> has become more fragmented. Each year we see new languages being
> developed and used. Importing new shiny objects into base is
> unsustainable. IMO the momentum is behind containerization,
> specifically kubernetes and docker-like containers. That is today. The
> next year or two will introduce new technologies and shiny objects
> which we will likely need to introduce here to remain relevant. We
> should be looking to reduce the footprint of base, introduce new
> technologies in ports (ports are much easier to build from scratch,
> maintain, and update than base). Additionally the idea of meta-ports
> that install groups of packages would make building purpose-built
> systems a breeze for our user base, similar to what anaconda does, like
> a FreeBSD based LAMP (FAMP) stack package that installs all the
> necessary bits with one pkg install command.
And that seems to be the point of convergence in all this, which is fine
by me.  I was looking to discuss the options and figure out the best way
forward.


signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Enji Cooper

> On Jan 3, 2019, at 04:46, Eric McCorkle <[hidden email]> wrote:
>
> On 1/2/19 1:29 PM, Cy Schubert wrote:
>
>>> I'm all for discussion and criticism of this, that's why I posted it,
>>> but I don't think these kinds of false equivalences are helpful.
>>
>> Actually it is helpful. Without a solid proposal of a new feature or
>> userland utility to be imported into base that requires the support of
>> a language not already in base, the implication of the original email
>> starting this thread was to rewrite FreeBSD using rust.
>
> That doesn't represent what I wrote at all, and is bordering on a
> strawman argument.  Nobody to my knowledge is suggesting rewriting
> everything, nor would that be possible.
>
>> In reality we should rely more on ports. Over the years this business
>> has become more fragmented. Each year we see new languages being
>> developed and used. Importing new shiny objects into base is
>> unsustainable. IMO the momentum is behind containerization,
>> specifically kubernetes and docker-like containers. That is today. The
>> next year or two will introduce new technologies and shiny objects
>> which we will likely need to introduce here to remain relevant. We
>> should be looking to reduce the footprint of base, introduce new
>> technologies in ports (ports are much easier to build from scratch,
>> maintain, and update than base). Additionally the idea of meta-ports
>> that install groups of packages would make building purpose-built
>> systems a breeze for our user base, similar to what anaconda does, like
>> a FreeBSD based LAMP (FAMP) stack package that installs all the
>> necessary bits with one pkg install command.
>
> And that seems to be the point of convergence in all this, which is fine
> by me.  I was looking to discuss the options and figure out the best way
> forward.

Going back to my previous statement, I think writing a service monitor (to work alongside init and rc) in modern C++/rust would be a good item to undertake.

I’d be willing to do this with someone else, as a research project/to demo how rust could be used.

Given prior comments about rust binary sizes and the fact that the default linking option is mostly static, a “mission critical binary” like this (or rescue?) would be a good candidate for rust.

Cheers,
-Enji

PS let’s call the discussion mostly closed and start working on prototypes instead of beating a dead horse further.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Igor Mozolevsky-2
On Thu, 3 Jan 2019 at 16:26, Enji Cooper wrote:

<snip>

> PS let’s call the discussion mostly closed and start working on prototypes instead of beating a dead horse further.


That's precisely how ideas that most people disagree with get *pushed*
through by evangelists with confirmation bias! Like someone said
earlier in the discussion: does Rust add anything? The answer is a
resounding NO, save for bloat.

--
Igor M.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Wojciech Puchar-8
>
>
> That's precisely how ideas that most people disagree with get *pushed*
> through by evangelists with confirmation bias! Like someone said
> earlier in the discussion: does Rust add anything? The answer is a
> resounding NO, save for bloat.
>
for all such "evangelists" it should be clear reaction:

"start your fork".

Instead of making long discussion.

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Enji Cooper
In reply to this post by Igor Mozolevsky-2
Igor,

> On Jan 3, 2019, at 08:32, Igor Mozolevsky <[hidden email]> wrote:

...

> That's precisely how ideas that most people disagree with get *pushed*
> through by evangelists with confirmation bias! Like someone said
> earlier in the discussion: does Rust add anything? The answer is a
> resounding NO, save for bloat.

And this is why one reason people say “FreeBSD is dying”.

If we stuck with status quo, we wouldn’t have llvm, would use just PowerPC/Intel architectures, libxo wouldn’t be a thing, we wouldn’t have tests, etc.

Calculated risks have value. But in order to prove their acceptance and use, you need to provide prototypes to show their usefulness, provide measurements, and such.

My point is to provide an existing service that I’ve seen implemented more than once by FreeBSD-integrators in an ugly way, using non-modern C/C++, or python 2.x: the former which is more difficult to maintain than modern C/C++, and frankly was a mess; the latter which was maintainable, but slow (because JIT python) and didn’t use base system components, i.e., python 2.x.

Tl;Dr: if you don’t have anything constructive to say, please rethink your replies and provide constructive criticism. Constructive criticism is welcome. Armchair nitpicking is not.

Thanks,
-Enji
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Igor Mozolevsky-2
On Thu, 3 Jan 2019 at 17:41, Enji Cooper wrote:

>
> Igor,
>
> > On Jan 3, 2019, at 08:32, Igor Mozolevsky wrote:
> >
> > That's precisely how ideas that most people disagree with get *pushed*
> > through by evangelists with confirmation bias! Like someone said
> > earlier in the discussion: does Rust add anything? The answer is a
> > resounding NO, save for bloat.
>
> And this is why one reason people say “FreeBSD is dying”.
>
> If we stuck with status quo, we wouldn’t have llvm, would use just PowerPC/Intel architectures, libxo wouldn’t be a thing, we wouldn’t have tests, etc.
>
> Calculated risks have value. But in order to prove their acceptance and use, you need to provide prototypes to show their usefulness, provide measurements, and such.

Really, FreeBSD is dying because people don't want to experiment with
"new toys" that have *not* been proven to be effective at what they
claim to do while having been proven to be a bloat? Really, that's
your argument? Well, like And there I was thinking it way dying
because of long-term "issues" like this one:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203874 that prevent
me (and I suspect many many others) from virtualising FreeBSD and
causing a switch to the various flavours of Linux!

Like Wojciech said, absolutely nothing prevents you from forking off a
branch and even re-writing the entire code in Rust, just don't turn
around and say "I spend X amount of time on it therefore it must be
integrated into FreeBSD-proper regardless of the numerous shortfalls"!
As it stands the base install is too large as it is, and I have
recompile the whole thing with a whole bunch of WITHOUTs already, and
you're saying more bloatware should be added.



> My point is to provide an existing service that I’ve seen implemented more than once by FreeBSD-integrators in an ugly way, using non-modern C/C++, or python 2.x: the former which is more difficult to maintain than modern C/C++, and frankly was a mess; the latter which was maintainable, but slow (because JIT python) and didn’t use base system components, i.e., python 2.x.

Maintainability is not about code, it's about people's skills and
documentation, if one is inept at C, or Python, what on Earth makes
you think they would write amazing code in Rust? Your argument simply
doesn't follow there at all.


> Tl;Dr: if you don’t have anything constructive to say, please rethink your replies and provide constructive criticism. Constructive criticism is welcome. Armchair nitpicking is not.

Here's my constructive criticism: don't waste resources on an unproven
and still-evolving language; if you have *that* much free time on your hands
start working through BugZilla.


--
Igor M.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Speculative: Rust for base system components

Wojciech Puchar-8
In reply to this post by Enji Cooper
>> That's precisely how ideas that most people disagree with get *pushed*
>> through by evangelists with confirmation bias! Like someone said
>> earlier in the discussion: does Rust add anything? The answer is a
>> resounding NO, save for bloat.
>
> And this is why one reason people say “FreeBSD is dying”.
>
dying for whom?
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[hidden email]"
1234567