Conversation

Jarkko Sakkinen

Edited 1 year ago
In 99,999% of cases it would be better if people would work out with existing and established open source communities to enable #Rust rather than making their "better" completely new version of any possible asset.

It is slow, tedious, complicated and sometimes even quite discouraging but if you are successful then you are also doing something of high measurable value. And by going through the long and hard path also the end users will get the governance of long-term support, which they IMHO deserve.

At least for me the end user is the king of the hill, not developers. We need to do the hard and nasty part.

#rustlang #opensource
1
0
2

@jarkko I'd knock a few nines off that number but in broad strokes this is true. The tendency to rush off and build from scratch in a new favored tool is not unique to Rust either, FOSS projects are plagued with the syndrome. But also some of them do just need scrapping and starting over: bad crufty code plus bad project management isn't a good foundation to build on.

1
0
1
@alerque well that's exactly what engineers do. other way around is sort moving responsibility to the user by breaking backwards compatibility :-) Almost anything can be refactored and refined. It takes time and is difficult but it is optimal for the users.

For instance, I like that bat has syntax highlighting but I would scrape it any day if GNU's version added the same feature, and I would not tbh care if it was implemented in Rust or not. This sort of culture drives to loose commitment and saturated software ecosystem,.

This article really never gets old: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
1
0
0

Jarkko Sakkinen

Edited 1 year ago
@alerque starship.rs is a good example on how to engineer properly with rust, as it solves an actual problem: how to remove overhead from shell prompt. i.e. not "here's my own incompatible version" :-) i've been totally committed end user for a number of years now...

it actually does the opposite: it improves compatibility because e.g. the same prompt translates from something like bash to something like powershell.
1
0
0

Jarkko Sakkinen

Edited 1 year ago

@alerque Actually (and this is literal fact) before I did one day cargo install bat, I had an alias for along the lines of cat <file> | vim -R - sort of thing so it was literally just way to shortcut that and not much else.

The way Rust community looks at a “change” is sort of “this would nicer way to do this”. The way kernel community looks at a “change” is more like “we have this alarming situation that we need to absolutely deal with right here an right now or data centers or whatnot will be doomed”.

And even my fav language C is in the end for me an opcode generator, not more or less. Rust is yet another opcode generator with static analysis built-in. I just vote for the tech first and totally disregard “language level” kind of merits. What works the stuff that goes best to the cores best WFM me best in the end :-)

1
0
0
@alerque And also sort of might be a bit harsh and controversial to say this but when there's big noise about a new language feature (which in the end means zero value at least at its epoch) I just think "when are these language features going to end". I mean on C side in kernel we were before like C89 + gnu extensions and now I suppose we are like C11 standard('ish).

This rapidness might work for user space but especially for core kernel features feels a bit brutal to say the least...

I'm actually just opening my views because in LKML I see "yes Rust" and "please no Rust" so trying to address "in-between-but-doubtful-of-Rust" camp's concerns :-)
1
0
0
@alerque I'm mostly looking at things from operating systems and alike side and I have total buy-in uapi and drivers side because merits are really something I count (i.e. preventing subcategories of exploits thanks to compiler) but the "core" side of the equation is totally alien to me. Sorry, totally off-topic but just writing these down merely as remarks.
0
0
0