https://github.com/uutils/coreutils
Why does it feel so wrong? Is it just me being a conservative?
It shouldn't have to, the GNU coreutils were a "rewrite" of the tranditional unix core utilities too, after all. But I guess the discord button in the readme doesn't help
Why does it feel so wrong? Is it just me being a conservative?
The main thing that bothers me is that this is a lot of effort to fix a non-problem, that Rust has a single implementation with no standard, and that this project is licensed under MIT instead of GPL. So you're creating something with worse power relations than the existing solution without really improving it in any meaningful way.
>>2
Oh well, I didn't notice the Discord button. I won't comment on that to stay polite.
Discord...
>>4
The official Rust community switched from MozNet to Discord.
>>5
But why on earth would they use Discord? Even if they all had PTSDs forbidding them to go outside the browser or Electron apps, they could use thelounge.chat (an IRC client), Gitter, Riot/Matrix... These all provide the same experience with the cute emojis and the site previews and the audio file uploads and the Markdown and whatnot.
Now, if they cannot use a keyboard to communicate (which is perfectly understandable for programmers) there's Mumble whose audio quality if far superior than Discord's.
They're using a service they cannot host themselves. The day Discord thinks it doesn't earn enough $$$ with selling their user data and wants to cash in, they'll sold the whole stuff or require paid accounts. What are they going to do then? You want your friends back? You pay.
I'm beginning to understand why they need their code of conducts, they're hanging out in vocal chats for sex maniacs. Discord doesn't even work properly on Firefox. WHO's going to take them seriously?
>>6
I don't believe they use Discord because they think it's actually good. My theory is that they're actively trying to distance themselves from the crusty dinosaur image of IRC and get into whatever glossy jank kids are using these days in hopes of attracting young blood to recruit. IRC is often cited as a barrier to entry for first-time contributors, just like mailing lists.
Mozilla itself was also considering moving to Discord after they decided Zulip and Mattermost aren't good enough. It appears there was enough pushback that they switched to Matrix instead. It's a pity they had to shut down MozNet.
>>6
>>7
A lot of people seem to perfer it. I constantly see people inviting other to their "discord servers" (for whatever reason), and I guess they hoped that they could more maintain a community easier using a flashier platform with round corners.
>>8
Gitter is another flashy platform with rounded corners but it's open source and intended for developers. Discord is closed source and made for gamers (by furries).
Discord invites were spammed so much when it was the new thing, it made me suspicious that it might be an MLM thing. But I was told that they actually did it for free.
>>9
There's also Discourse.
>>3
https://zaiste.net/posts/shell-commands-rust/
Not a single one of them is licensed under a strong copyleft license, they all use push over licenses. Why do they waste their time?
>>12
Increase adoption
>>1
Well, it's needless work, mindlessly attacking GNU, using Rust without real reason, with a loose license because copyleft is evil to these people. The Discord link and other garbage is just the icing.
These Rust programmers aren't doing anything innovative. They're simply copying worse-is-better. UNIX and C with ad-hoc formats can and will get worse, with the WWW and JavaScript and Rust using JSON or Protobuffers or whatever garbage someone comes up with next.
The silver-lining here is how this is doing to UNIX weenies exactly what was done to better systems, idiots coming in thinking they know better and replacing everything with worse software, doing less with more, ever less reliable.
Does anyone really think Rust hipsters will be around in sufficient quantity years from now to continue maintaining all of these rewrites? I really don't think they will be--they will be off surfing the next big language wave. No one should be taking them seriously.
The silver-lining here is how this is doing to UNIX weenies exactly what was done to better systems, idiots coming in thinking they know better and replacing everything with worse software, doing less with more, ever less reliable.
How long do you think this can keep repeating itself?
Why does it feel so wrong? Is it just me being a conservative?
No. Rust programmers want to prove rust is better than C by rewriting everything in rust
>>16
I don't know. I'd prefer to think it won't last forever. Currently, we're in the transition from UNIX and C to the WWW and JavaScript, with languages such as Rust also on the latter half. The transition was from real systems like Multics written in real languages to UNIX and C, with various other groups being lumped in the former half, such as the Lisp Machines.
Now that machines are billions and trillions of times faster and more spacious, UNIX and C seem acceptable despite their disgusting inefficiencies. If machines somehow keep improving, I could see the next band of retards thinking the WWW and JavaScript are efficient compared to what follows, and relics such as UNIX which use only a few hundred megabytes for their inefficient garbage would be seen as not worthwhile, similarly to how truly efficient software defeated in the market is viewed nowadays.
I'd like custom hardware to start proliferating, which seems like the way machines will start improving. If dedicated people can build their own specialized hardware, UNIX and C may die out to be replaced by better, and if people have to implement more of the software they use, they'll care about simplicity and reasonable standards, which would kill the WWW and JavaScript.
If machines somehow keep improving, I could see the next band of retards thinking the WWW and JavaScript are efficient compared to what follows, and relics such as UNIX which use only a few hundred megabytes for their inefficient garbage would be seen as not worthwhile,
There are already many things that follow in this direction, Chromebooks, Javascript (web/mobile/desktop) frameworks, node.js, and programming languages which compile to javascript. These things remain strong, but it seems like to some extent they might be fading away at the same time. I'm not really a fan of webassembly, but it will be interesting to see how that shakes up this space.
and if people have to implement more of the software they use
This may have already been tried and constantly shot down as "in their own little world".
>>19
I don't have hope it's already been happening, expect web hdl being the norm for harware design.
I don't have hope it's already been happening, expect web hdl being the norm for harware design.
If you look at it (as a Hegelian) dialectically it makes sense for WWW to subsume hardware. I think that would be something like web assembly implemented in hardware with vendor specific extensions or even heterogeneous multiprocessing of some sort. What's not clear to me is how this will reflect in software, for example it seems to already be the case that the momentum of Node.js has been subsumed by languages which can compile to Javascript such as Clojure and ReasonML, I can't see Javascript re-emerging on the server side in a context where these languages exist. Something that might be interesting is a move towards continuation-based web frameworks in these languages which can compile to Javascript. In this world everything would be sort of tacitly modified by the assumptions of the WWW, but WWW would in some sense remain distinct, sort of like how UNIX tacitly modifies anything that runs in its environment, even though most application on UNIX systems don't fully ad hear to the values.
continuation-based web frameworks
This was not what I meant, I meant something like Ocsigen's Eliom.
>>22
Is that like Smalltalk's Seaside?
>>23
Well it is, but I miss-spoke, this wasn't what I was trying to emphasize. The interesting thing I was trying to point out was this idea of writing servers and multiple client implementations all in one language as a single application, all sharing abstractions, etc.
>>21,22
I didn't think anyone would take that seriously enough to reply but "webhdl" will probably be certain companies have their own "web platform" for "cheap" hardware production that's using some horrific proprietary hdl or common hdl with vendor specific extensions as you said, which they have the ide on site written in atom or whatever the webui of the day is, that you must use for some reason.
Hdls already have a major toolchain problem, this will happen naturally with all the risc-v hardware design sites popping up, if they ever allow ic modifications using a hdl.
(as a Hegelian) dialectically
Your replies were more interesting then mine but calling it the next norm was pushing it for fun. The major players using their own maintained versions and toolchains won't be switching to a "webdoc" development style, even if they are the ones running the "web platform" for everyone else.
I think that would be something like web assembly implemented in hardware
Some s930x cpcs run java byte code more directly as machine code already, funny chromebooks and webphones don't do this yet with some type of ir ecmascript "byte code", then support something declarative style opcode enhancements™ for html and css on the side. I don't know how the last part would work generically like that.
In this world everything would be sort of tacitly modified by the assumptions of the WWW, but WWW would in some sense remain distinct, sort of like how UNIX tacitly modifies anything that runs in its environment
I'm not sure it will stay completely distinct with how the www currently is and unlike single research sconix™ the www exists as a single defined theory, until terms like web 2.x start being used. Xanadu defines the theory, isc defined the more terrible base standards and diverts like single unix on steroids, until you look at how it is today, it's mostly different and worse. Otherwise history is repeating it's self again.
>>25
I think we were both just playing around to some extent. I don't really know enough about HDL. I think I probably agree with your analysis on www being too poorly defined to be distinct.
>>25
https://developer.arm.com/documentation/100069/0607/a64-floating-point-instructions/fjcvtzs
>>27
Marvell and apple based chromebooks if they exist might be arm8.3-a and up now but webphones are dead. This isn't like a full emcascript engine implemented as a asic instead something you would expect from an arm "risc" processor that has the asic embedded. I wouldn't be surprised if arm did implement in standard for a full hardware based ecmascript engine in the future though.
I don't know what to say about the s930x cpcs that implement a jvm and if it's even an asic inside the cpc since trying to get info like this out of ibm requires suicide.
Why are people so afraid of garbage collection?
Why are people so afraid of garbage collection?
This is actually a fairly interesting question.
>>29
Garbage collection is a convenient red herring. Idiots have convinced humans that efficiency is the primary function of a computer, but getting wrong results fast is worse than useless. The masked inefficiencies are worse than GC could ever be. The inefficiency of wasting human time writing C; with a kernel micromanaging everything, because programs can't be trusted to run without micromanagement; and much of that being used to wastefully send text messages back-and-forth, constantly parsing, constantly starting up a new program for a minor task.
UNIX and C are the true inefficiencies.
For more most applications, GC is a really nice idea. I don't really understand the aversion to it when it is done well and not wastefully. I suspect many people were slightly traumatized by bad early experiences with slow, inefficient GC and did not recover.
But one use case where there GC can render a language wholly inappropriate as it is typically implemented are real-time systems where tight timing is a requirement. Even multithreaded GC languages still do not provide fine enough control over which threads should be garbage-collected and which should not. This is actually important, but most GC language authors carry the mentality that you should not be trusted to decide memory matters ever, just extending many of the same micromanagement mistakes of the UNIX paradigm. So C endures especially in the embedded space, because at least it does not overtly try to get in your way and retains the most of the efficiency of a proper low-level language, whereas most languages with GC target much higher levels of abstraction and low-level work isn't a serious consideration.
>>29
It's only subjectively bad when you can't understand it or objectively when it's forced, both insure bad code from shitty engineers but a switch will also cause shitty engineers and hipster blogs advocating its use until it becomes the norm. This doesn't mean you shouldn't make more automation like it was all meant to be but the cost of implementation is the question. Could you in a month for your deadline implement a complete rust toolchain on whatever platform you're using then still have time to finish the project. This is why sconix and mostly imperative c get used and will still be used. Anyone competent using them doesn't like it and is experiencing torture, probably made their own esoteric language.
>>32
This seems rather agreeable. The “right thing” seems to be mostly distinguished by the proper handling of exceptional cases, and in the case of memory management there are exceptional cases where garbage-collection as it exists is inadequate. That being said I'm not certain that direct experience with the exceptions for which garbage-collection is inadequate is a significant motive for the revulsion.
Could you in a month for your deadline implement a complete rust toolchain on whatever platform you're using then still have time to finish the project. This is why sconix and mostly imperative c get used and will still be used.
Do most projects actually require the implementation of a complete toolchain, and is UNIX actually the best way to achieve this? This doesn't seem true to me.
>>34
That was an absolute as an example, the sconix thing has to do with whats already there not with whats the best way. I don't know why you took effort to read that.
It's only subjectively bad when you can't understand it or objectively when it's forced, both insure bad code from shitty engineers but a switch will also cause shitty engineers and hipster blogs advocating its use until it becomes the norm.
That reads similarly to how UNIX became popular.
Could you in a month for your deadline implement a complete rust toolchain on whatever platform you're using then still have time to finish the project. This is why sconix and mostly imperative c get used and will still be used.
I completely forgot about how every C programmer is bravely forging a future in a land so esoteric only a C toolchain is available, but simultaneously not so esoteric that C can't pretend it's not running on a PDP-11. This is like when people use vi because it's everywhere. Yes, we're running so fast we don't have time to put on comfortable shoes, of course.
Also, why the fuck is every programming discussion turned into projects and other corporate shit? Don't pretend a hobby with self-imposed deadlines were being discussed. Why can't I program just for enjoyment?
>>36
I'm bored and this reply satisfies me but the pdp11 part, I expected more.
That reads similarly to how UNIX became popular.
Close but it's mainly corporate shit, the concept that sconix is anything like that is smoke and mirrors only elevating and giving credit to something that isn't. The switches and hipsters were always real.
All, bravely forging, working on improving c and wanting to use c, pdp11.
Epic. It's out of frustration and doesn't get far past a incomplete hobby project for the competent that aren't completely desensitised but this optimism is amasing to even exist as sarcasm.
There are complete operating systems with new esoteric languages that have their own toolchains separate from sconix so I might not be giving enough credit here but esoteric languages are usually interpreters in an interpreted language.
This is like when people use vi because it's everywhere.
That's their reason, this is a good comparison. If they had more reasons like wanting to use comfortable shoes they would either be working on crafting comfortable shoes with the broken tools they had or using comfortable shoes. Even better forging better tools from the start, instead of losing all ten pointers.
Also, why the fuck is every programming discussion turned into projects and other corporate shit
Like you are complaining now they complain in some way about corporate shit, talking about it is unloading. This doesn't apply to all programming discussions but the institutionalisation uses scheme for part of the courses now, you won't get that purity here. It's more likely befunge or piasco will provide more immunity from anything corporate.
Don't pretend a hobby with self-imposed deadlines were being discussed.
What was being discussed is why is gc feared not a hobby with self imposed deadlines, I gave broad theoretical examples and nonexistent philosophies, which that one was corporate shit not a hobby and probably doesn't apply to anyone here but I'm starting to wonder.
Why can't I program just for enjoyment?
I get bothered in real life why I don't take software engineering as a job or go through the mill, this is my venting. I consider myself shit at it but still do it for fun.
>>28
Found something for anyone still interested but it's jvm with armv5 https://web.archive.org/web/20140328171422/https://www.arm.com/products/processors/technologies/jazelle.php