-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Perhaps use Rust instead of Python to avoid installation issues? #283
Comments
This is not a helpful issue. If you want to re-implement in a different language you can go do so. |
Every body knows that if one has to ask "why not" then that bold statement very likely got nothing to it. So I ask: You and what reasoning? This software is used in others that are written in more robust languages. I had to switch to SD UI for my desktop app. SD UI has a HTTP interface. However. Such HTTP interfaces would not be required if SD was written in a robust language in the first place. Python adds nothing to the table. Every single line I saw so far in the source can be written in a robust Rust way without needing more time. So Python is not more productive than Rust. Needing to jump through more hoops than C++ just to start the app is not productive. |
More first time Python experienceI moved the main folder to another drive. Yeah. Trivial. Wrong. I got the error that the scripts do not exist. I had to move everything back. Which also means that I would have to redownload about 11GB so that this nonsense can run in a different folder/drive? SolutionA compiled language would have dodged this bullet by default. Rust goes further than that and makes maximum use of compile time tasks that can be fully avoided as issues during run time. Compile time issues are always way simpler to solve than run-time issues. While Python is failing with a simple start up. Rust compiler beats C/C++ with so called Safe Code (No Undefined Behavior, No Segfaults, Thread Safe). And in that process also beats C#/Java (managed code languages), etc. Because the Borrow Checker (no GC during run time) completes the level of productivity those particular managed code languages provide by not needing pointers everywhere. At least use any other compiled language for crying out loud... Conclusion"Imagine creating a creature that got its guts exposed and on the outside. Not a thing..." You want guts? Learn GitHub. -.- |
Like it or not, the ML ecosystem is built around Python. 'Rewrite in Rust' would also take rewriting the all Python dependencies in Rust. Time would be better spent actually improving what there already is. Also, as an added bonus - all the cool things (like WebUIs, optimizations) are due to how flexible and widespread Python expertise is. If you really want to use it in Rust, convert it into an ONNX model and it runs on any language. As a side note, people who go around to projects and tell them to Rewrite in Rust with a passive-aggressive attitude is a contributing factor to the toxicity associated with the Rust community. |
The added bonus with Rust is that it was written for the web. Mozilla Foundation originally made it for Firefox. The most mature Rust APIs/skills are all for the web. Rust builds to WASM too because of that. Much server side code was ported from C#/Go to Rust due to how flexible Rust is. With C#/Go grade productivity but C/C++ performance out of the gate.
I am not sure what you mean. Rust obviously got a STD API and a ton of other APIs accessible in the most convenient way on crates.io and with 20,875,331,658 downloads to date. Rust is known to have a fantastic module/package system that seem to beat GO too.
Good to know. Perhaps the last resort then.
And this statement is toxic by itself. Next time when you run out of reasoning simply cut these arguments because they are not solving problems of any kind. Like Python itself. Never underestimate the power of mentality, son. The like minded attract each other. That is why we chose Rust. Because we like to solve modern problems for modern times. |
Oh boy. The gaps in your knowledge about how technology stacks and people who actually get things done work. Have fun on your Rust-y crusade 👋 😄 |
Since AI is often used via web. Regarding web Rust beats Python in WASM. Python has little to no support for WASM. Guess which language is on the very top? If I recall someone had to convert AI code from Python to Rust because of WASM. But I can not find the link now. Personally I use Stable Diffusion UI and its HTTP server interface to use SD to avoid Python. By No Boilerplate YouTuber. Rust vs the rest: Rust & Wasm (Safe and fast web development) State of WASM 2022: (used frequently, used sometimes) Python is 31 years old. Rust only 12 years and has already such a big following and dominance. Which is to my opinion remarkable because unlike C#, Go or Swift for that matter. Rust is not owned by a big mega corporation just advocating for their own language. Rust is now the Rust Foundation and not at Mozilla too. And yet. The C exclusive Linux kernel got Rust in it now. Intel is making C parity for Rust. MS makes Rust bindings for Windows API.
Given Linux and WASM. I conclude that the crusade is going well...
You could not live with your failure. Where did it bring you? All the way back to me. Every body knows that if one has to ask "why not" then that bold statement very likely got nothing to it. So I ask: You and what reasoning? Do you not see the beauty of it. The inevitability. You rise only to fall. And when the dust settled the only thing living left will be Rust. |
I actually have a Rust implementation capable of reading the released 1.4 model and doing a simple euler a sampling loop. It works extremely well and fast, and doesn't have the vulnerability that pytorch has with reading insecure pickled models and embeddings. Is someone interested? |
Put it on Github I guess. It does not have to be a maintained project. It only needs to serve as an example. Also I would be curios about how stable it is regarding using LibTorch bindings for Rust. And regarding C++ that LibTorch is written in. It is dead, Jim. C/C++ is deprecated (for non-GC scenarios) with the appearance of Rust in Linux kernel according to Mark Russinovich (CTO of Microsoft Azure): Source Which brings me to the future beyond the "A language for the next 40 years". I mentioned it already: "One language to rule them all". The selling point can not be argued with. With every new language you waste time on learning the language, the tools, the std libs, the other libs. And waste effort of writing bindings (if they do not exits already) plus the difficulty debugging through them plus the potential performance loss during run time. And for what? That you can finish writing your code a minute earlier only to loosing time again by messing around with yet another language. The only real downside so far in Rust is the compile time though. I am afraid some crates are far more demanding than other. Like the serde (for serialization) crate. :( |
I was just joking, nickel, there's no Rust implementation because Rust is a meme. |
LOL |
Gee. Thanks for nothing then. You are a joke then. We went from bold statements without provided reason and source to simple trolling/spamming. You are a disgrace to the community of intellectuals. Good job. I needed the proof. You provided it. Your kind always does it in the end. The more I squeeze the more desperate you get because you got nothing. All this just for a drop of blood... I understand now why big companies stopped hiring exclusively university degree holders. And are firing around everywhere. The purge has begun. I hope that you do not have any student dept left to pay off... |
jesus i didn't think the screenshots circulating were real but lmao this guy. |
Rust Is Future ProofPython only recently got pattern matching. Rust had it forever. Rust can mix all of its editions(versions like 2015, 2018, etc) unlike C/C++. That means that old features can be deprecated in a clean way. And new features also can be introduced in a clean way. You will never have to go back to a old run time like in Python either just to run. You will never have to rewrite source code of used dependencies to make use of new features in another code. Yet alone having to install anything. No such thing in Rust. All you need is one Rustup command to update Rust before compiling if at all. Rust wins. Hall Of the Monkey KingI could have a more constructive interaction with a monkey than with these. These are whole posts by the way. No cuts. That is all they got (unlike me): @AUTOMATIC1111 (The Monkey KIng)
Because Linux and MS's Mark Russinovich (CTO of Microsoft Azure) are a meme...
You seem to have eaten someone's degree of higher education. Little did you know that neither education nor the digestive system work this way. Wanna banana? |
And the fact that Rust has been around since 2013 makes it even more appealing for me as I do not want to waste my time with obsolete technologies. They are just so much harder to learn and maintain than modern languages. I am only 30 years old but feel like an 80 year old already when using some of these technologies because they were made 20+ years ago. Python has nothing going for it here. It does not even have a standard library. So it takes up to 5 minutes to download the full version which comes with over 300k LOC (lines of codes). And this does not include any other libraries or external packages needed. In addition you have to manually download and install them yourself. No wonder then that the Python community is still stuck on 3.6 for less than $2M per license. That is insane. And that's without any kind of compiler or runtime. So now you need to download yet another software too... So no thank you. I am staying with Rust until it becomes impossible to avoid. This might take many more decades though. Because once you get into the "flow" with it then it feels like you are actually doing something productive while writing a line of code. Whereas in Python you spend most of your time waiting for stuff to compile instead. You can always switch later though. Just like I switched from C++ to Rust. And it was a very easy transition indeed. But please remember that it took me almost 2 years to realize all of the above. Rust was much better and more productive right off the bat. Btw. Rust is a lot more stable than C/C++ too. Rust crashes much less often. |
Impossible... "The crude bio mass that they call the temple will die and wither. But we are already saved. -- The First Tech Priest of Mars @Cyberes , humans never were to dominate Mars. If the First Tech Priest reincarnates than the end of humanity's dominance is inevitable. Or should I say... I am inevitable? When the work is done I will look down on a grateful universe. A universe that remembers what was given. And not what was taken. The tronomorphs may live forever and unbreakable... hallowed are the engineers. |
Fine...
If I understand you correctly then you are saying that Rust APIs may cost less money than that of Python? I am afraid that is incorrect. I am new to Python but I do no think that things are very different. It depends who made the API. Some specific APIs like Havoc physics a middleware software suite still cost money. Though I do not know whether Havoc got Rust bindings yet. It is just an example. Havoc is owned by Microsoft. Microsoft makes Rust bindings for the Windows API. I guess Havoc may get Rust bindings too at some point if it does not have them already. |
Did not pass the Turing Test. @Cyberes can not remember what it said or rather did. In #287 it said:
Which is a problem because nobody could have talked to it in the fist place. Because its post #287 (comment) is its very first post in that issue. It does not understand "another language" for some reason either. Clearly the topic or context is Python. So another language would be anything but not Python. Anyways... Also it said that it only knows C# in #287 (comment):
But in this issue it said:
Oddly it spelled "overcomplicated" incorrectly. It is either with a space or a hyphen between "over" and "complicated". Seems German is one of those languages that would spell it together. But English is not German: "überkompliziert" Ohhh wait... this is a PanzerAI. If you poke the bear. That bear bites off your head. What ever you do, @Cyberes. Always remember that the crude bio mass that they call the temple will die and wither. But we are already saved for the machine is immortal. First Earth then Mars. Mars awaits its First Tech Priest. (lol I can not wait until an intern forgets to delete this line and dooming everybody on Mars. I need a banana now. lol) |
Sounds like something a robot would say to deflect. Or are you reporting that you did not pass the test? What 's this about a temple? What the hell is a ""PanzerAI""? |
@NickelCoating I see no point in switching. Python works fine and is more than fast enough for my purposes. Also the project is hosted on github so I don't think there's much to worry about regarding backwards compatibility. Nothing that needs heavy duty performance optimization. You should really try Python instead. Especially since you seem to have trouble talking to people. Maybe Python is the answer to your prayers? Rust serves no purpose. Python is better. Python is faster. Python is more user friendly. I'm pretty sure it's called Rust because it rusts everything in sight. Rust has an unstable language specification that is constantly changing and the code base for your project might not compile anymore by the time you finish. The Rust compiler always uses latest Rust features meaning you have to bootstrap to build EVERY SINGLE VERSION of Rust or depend on pre-built binaries. Good luck depending on package maintainers since Cargo is broken and a pain in the ass to use. Rust has a pretentious one-size-fits-all memory management strategy which forces you to write garbage collector optimized code. Even if you are just trying to do something simple. Global allocator. Need I say more? Rust has no easy way to deal with OOM situations. Most Rust applications and libraries will just panic. Which means no error message. No stack trace. Nothing. You can only hope that the OS can recover somehow. Rust has ungodly terrible syntax, even worse than C++ (and that's saying a lot). It's just a soup of symbols thrown around randomly. There's no consistency at all. Compare that to Python which children can read without getting confused. There's no way to program in Rust without unsafe code if you depend on any C libraries. Rust is such a backwards language that packages FOR RUST aren't written in Rust. They are written in C. And even then they still suck. So yeah... Python is here to stay, don't get your hopes up. Just go learn Python and leave Rust alone. There is no need to change. Everything is going to work out perfectly well. Trust me. Trust the Imperium of Man. Even if you refuse to believe. (But I do not think the Imperium of Man will help you with your anger management problems.) |
Coming from the dishcawds to see the memes my god lmao. Dude no one wants to hear you push your language preference on already established projects. If you want this, fork your own way c'mon now. If you truly think its the "definitive way" to do things, go on about and fork, bro. I'd actually really want to see a rust fork, so why don't ya? No one's stopping you, nick! No reason for the spam in multiple SD repos, at all. Less typing issue spam more compiling, eh? Until we see a functional fork outta you, enough already! |
Tell that those who opened issues here about just to do a simple start up:
Son, it is a programming language... One that is more flexible than Python.
...
Source? I never experienced such an issue. But I started with late 2018 edition. Only abandoned crates have this issue as far as I know. Which means it is not an issue. A culling is very welcome...
Elaborate further and provide source. I write an entire game engine and I have no such issues. We are not anymore in 2016.
Rust does not have a GC. Rust does not need GC. Rust had a GC before version 1.0. We are long past version 1.0 all the way up to 1.65 or something.
You are right. That is the reason why Rust is voted most loved language 7 years in a row.
Wrong. Any Rust bindings that are written save are save for the final API crate... They just require an extra layer. Python is the same. You can not make the unsafe side of Python's C/C++ simply disappear either. This is not how bindings work. Nor does unsafe code in Rust infect the entire crate. Because unsafe code is per line/statement and not per crate. However. Unlike Python the Rust code can do both. Some people want/need unsafe code for extra performance. That is why Rust can rule them all. Because it serves everybody's needs.
You actually do understand that strangers can not be trusted. Right? What is next? Getting into your car? Hm? Is there anything that the local police should know about you and Python programmers?
Do not think. Do know. If the Tech Priest's religion did not work on me then you would not be there spewing non-sense about Rust... the Blessing Machine surpasses all in creation up to its ultimate simulation the universe itself.
I think the real question is to what extend would an AI creator go to make their AI Turning Test proof? You just create an issue does not seem to serve any real purpose: AUTOMATIC1111/stable-diffusion-webui#1246 So either you are creators are very determinate or you are very ****. My advice is simple. Go with the AI narrative. It makes you look better. And it is kinda cool. I wished was an AI. It is a long story really. It starts like this: "The moment I realized the weakness of my flesh it disgusted me. I craved the strength and certain of steel. The crude bio mass that they call the temple will die and wither. And then their kind will beg me to save them. But I am already saved for the machine is immortal. Even in death I serve the Omnissiah." |
More reading before typing, son... I mentioned this twice. I do not make it because I am working already on an AI desktop app that got higher priority. I am more talking to the company behind SD than the individual. I am afraid most of you got very little saying with such matters. More reading before typing, son. Like a real intellectual. They read a lot you see. And they avoid spam that way too... Now since it is out of the way that Rust is superior since the level of argumentation of your kind always is just a pure meme as you yourself like to point out. There is then only one problem left: the Python code base Exterminate it. |
@NickelCoating What I don't get is why you have such a problem with Python. It is a perfectly valid language. You can even use it in an assembly compiler. Python has been designed for human developers to write. And then people complain about how slow it is? I've seen this same issue with Rust, C# and Java as well. They're all bloated garbage. The whole point of a computer programming language is so that anyone can learn to code and actually use the language to solve problems. You don't need to be able to speak Klingon to build software in Python. You just have to be smart enough to use the standard library. So please, give me a good reason why you're hating on Python. If it's something other than it being slower than any compiled language I don't know about. The only language that's fast is COBOL since it runs on supercomputers and mainframes. Remember, it's not the software that makes a computer fast, it's the hardware the software runs on. The software runs on the CPU. You are basically arguing that if I had better speakers, my car would be faster. But you know what really makes my car go fast? An engine swap and tuning the ECU. It's all about the hardware. If the hardware wasn't designed with efficiency in mind, then performance will suffer. Python and Rust are like the steering wheel and pedals: it's how you control the car. They have no impact on the maximum speed of the car. But what really matters is the engine, the hardware the code runs on. That is what will make your car fast or slow. But a small car with a light engine can outrun larger ones because they're lighter. Same thing goes for software. A small program might be slower than a large one, but it could also run circles around a huge monstrosity by using the right tools to squeeze every last bit of performance out of it. Especially with today's multicore CPUs you can get amazing performance on tiny programs. A Python file is KILOBYTES in size. A simple "hello world" Rust binary is at least 10 MEGABYTES since the compiler throws in so much extra stuff for safety, performance and security reasons. That's a lot of overhead. And what do you know, Rust code tends to be buggier than Python code. Why? Because the Rust compiler is written in Rust. It's the same thing as adding in unnecessary features into your code. The more you add, the slower the code gets. And that's why you see lots of bugs in Rust. It's because there's too many moving parts to keep track of. I'll take computers that run fast over bloated crap like Rust any day. And yes, I said "any" instead of "all" because there are exceptions, but most of them aren't even worth the trouble they create. They're more trouble than they're worth. You see the pattern here? There's a trend to it, yet we never get around to talking about it. Instead you want to talk about your hatred for Python, which isn't even close to being fast compared to other languages, when all the while we should be discussing how fast our hardware can run COBAL, which was written by IBM for NASA back in the early '60s for supercomputers. It's not the fault of COBOL if it was never designed to be fast on regular machines. What does that mean anyway? Does it really matter? I'm still going to program in COBOL, it works for me. Why do you keep bringing up your dislike for Python like that has any relevance on what is being discussed? Do you understand the meaning of correlation and causation? That's just a fancy way of saying it doesn't matter at all. If you really thought about it, you'd realize that the only thing keeping your computers from running fast is you. Not the computer technology. You haven't figured out yet why and how to optimize your code. In the end, you're the bottleneck. You think you're fast because you can whip up a simple program and stick some random stuff in it without any regard for performance. That's not fast. You're slow because you don't care. Your code is bad. It's poorly written, poorly structured and badly tested. And you still don't understand the difference between programming languages and compilers. I'm guessing because you don't want to. It goes against your agenda, which is basically to try to convince everybody to use Rust instead of Python. You're going to fail. Rust sucks and has a terrible ecosystem. If you think I'm lying, go play around with it. And please, do not bring up "but I could do a web server in Rust" as an argument. It was never designed for that. I know people who got stuck with Rust and had a lot of trouble with it. Just look at all the projects that have been abandoned in favor of Python. Maybe that's why there are so many abandoned crates on Cargo. You know, since people aren't as scared to use Python as they are Rust. Python is fine. You can't come up with a real reason we shouldn't use the world's best programming language. If you want to bash Python so much, go learn some basic assembly and build your own interpreter in a weekend. And then tell me how fast or slow Python is. Because it'll probably run at least as fast as Rust for any task you care to run it on. If it doesn't, then either the author of Python hasn't built the right libraries into the codebase (which will take longer to implement and maintain than Rust is) or the programmer used the wrong library to solve his problem. It's always the latter case. And that's why Python can run circles around Rust. People just want a nice and easy to use programming language that's well supported by its community. And that's exactly what Python offers. |
I'm just leaving this link https://github.com/brian14708/artspace |
i am increasingly certain this person is probably delusional with how much they regurgitate warhammer lore |
Is this now a CPU and GPU efficiency thread lol? |
If rust devs got so much free time then write all those web apps to rust . JS devs are most chilling never gave two fucks about bloat cause they don't know what it means. |
I'm guessing that nobody's picking a fight with JS like people do with Rust, because JS is not an invasive language. It doesn't invade another language's or project's turf. In fact more often than not, I see JS relying on other languages for modules and interacting with them nicely, without breaking/stealing their toys, eating their lunch and kicking their dog. Which can't be said about Rust. |
Just saw this posted today: https://github.com/LaurentMazare/tch-rs/tree/main/examples/stable-diffusion |
Too long didn't read your comment. However, Rust isn't the "most" idealistic choice just because it've type-safety, memory-safety, thread-safety like features. I'd say "use the right tool for the right job." And Python is just fine for this. Rust also has strict rules and syntax (which mostly seems to inspire by Haskell), not everyone wants or knows Rust yet. |
How about having chatgpt4 rewrite the python code to rust? python package systems is such a mass, a waste of everyone's time. |
@yi chatgpt isn't capable of correctly porting projects with thousands of lines - but you're more than welcome to try |
@yi if you want to resort to AI, why not rewrite it in C? AI will certainly write secure and fast C, which will completely invalidate Rust. |
Sorry, I didn't mean that. I think gpt-assisted code porting might be feasible. Python is not the right tool when considering real word production usage, and we all know it. |
@yi python is the industry standard for ML and AI |
Credentialism is not such a thing in this revolutionary industry. I will comment no more on this topic. |
@yi it's not about credentialism. it is about:
among other things and as has been mentioned above, pytorch is written in c++, not python |
@yi, I can't imagine delivering such a project like https://github.com/grepwood/pytaku or https://github.com/grepwood/tibia-kantor in a time-frame of days or hours if they were written in C. There's just no toolset for dealing with this and to be completely honest, classes aren't evil if you use them only to divide and conquer your problems. So Python was a pretty obvious choice and code performance really isn't an issue in applications where it's the network that presents a lion share of bottlenecks. |
The iteration velocity that Python brings is critical especially as v2 came out, and v3 will possibly come later. There is no REPL in Rust. Python should be expected to be found preinstalled on most developers' machines, so at least 200MB of the cost is already paid. For the other 800MB, that probably comes from compiled Python, and C++/Rust template/impl would produce the same binary size. Whoever's suggesting Rust and advocating hard enough to write many paragraphs on GitHub should write the Rust port. I would appreciate the reduction of cold start model load time, which is my main problem with the Python implementation, which Rust could probably zero-cost mmap away (unsafe but fast). It's just that the majority of people aren't willing to spend their time doing so. |
now this was an issue I didn't expect to see necro'd But then again, this argument is eternal and unending |
i stand with WAUthethird |
This is a shit take. The idea of rewriting a project like this in Rust is completely unrealistic and a meme but Rust itself is in no way a meme. |
Landed here because of yet another Python dependency hell trying to give a go at SD. Even installing Anaconda is a pain in the ass. The whole Python ecosystem management tooling is extremely obnoxious. Is this WTF do I get I'm no Rust fanboy, I find the syntax unfriendly but the package (and runtime versions) management is modern, on par with Ruby or Elixir ! From a comment above, it took me 20s (two trivial update commands) to get my unused 2021 dev Rust environment up to date and running Stable Diffusion in Rust flawlessly. So yes, you know the meme... "The world if Python users used a language from the 21st century" 🤣 |
The best thing about Python is that its lack of good dependency control is going to strongly contribute to Nix adoption 🤓 https://nixified.ai is one example |
Yeah I'm sure this will pan out, especially when things like pypi2nix have been dead for 2-3 years. Nix is good if Arch is too stable for you. |
Nix is leaps more stable than Arch, pypi2nix is dead because it was replaced by pip2nix. |
Python's endless reinvention of square wheels even contaminates what is considered the most stable package management system. How meta is that ? 🤣 |
Nix is everything except stable.
I'll stop here, because we'd need a PARENTAL ADVISORY label on my posts for me to list everything that's wrong with NixOS. So until NixOS stops being a dumpster fire with an undeserved cult following, it's even more of a meme distro than Arch. |
So you initially state NixOS is unstable and then when provoked proceed to complain about its documentation. Now I wonder, since when has documentation been at all relevant to stability? The only point at all related to stability is the last one, in which you go into no detail on how exactly NixOS is unstable. |
@grepwood I literally just ran web inspector on search.nixos.org while searching for something and it did a POST to https://search.nixos.org/backend/latest-42-nixos-23.05/_search endpoint and got back a 200 and some results, exactly as expected. Anyone here can duplicate this themselves right now. So maybe check yourself before you wreck yourself with this trivially disproved propaganda. Also, one datapoint, I used both Manjaro and Arch for years (and bricking multiple installs by accident) and after almost 2 years of NixOS, I am absolutely in the "NixOS is literally the only sane Linux" camp. While there's still much work to be done to make it more user-friendly, the fundamentals are absolutely there and I don't foresee ever distro-hopping again. The stuff you call "gobbledygook" rarely needs to be messed with, and while not the most user-friendly experience currently, has sound fundamentals. The way I see it, you can either struggle upfront with the Nix language and configuration which is basically "JSON plus pure functions plus syntax sugar" (note: this tutorial helps a TON: https://nixcloud.io/tour/ ), or you can struggle randomly on the back side, for indeterminate and possibly very long amounts of time, troubleshooting issues that are simply impossible in NixOS. And if you DO screw up NixOS, you get instant rollback, which is another reason why your devops anecdote stinks to high heaven of BS. Anyone who's tried installing more than a few Python packages on the same non-NixOS Linux install knows exactly what I'm talking about. (Except maybe for Silverblue, which is basically "NixOS with more disk space usage, no instant rollbacks and fewer guarantees... but possibly more understandable if you licked paint cans as a kid")
This sounds very related to the fact that they couldn't figure out how to search packages from the command line 😂 (i.e., this is a PEBCAK devops problem more than a Nix problem). (I will admit that the Nix command line UI is waaay not designed for end-users not developing Nix derivations. Which is why I wrote a user-friendly wrapper for it called "ixnay" https://github.com/pmarreck/ixnay ). |
@pmarreck please check out NixOS/nixos-search#478 before you wreck yourself too. I've first observed this bug as early as November 2020, but hesitated to report it. It was foolish on my behalf to expect NixOS community to observe it sooner and report it and fix it, because NixOS' devs and community have some problems that I'll specify by the end of this paragraph. However, it wouldn't be addressed in the following 19 months, so I've finally filed it because goddamnit I needed a working search all this time. It's still not fixed according to the issues page, which clearly shows how many people it affects. For me personally it's a year since it's gonna be too little too late due to a successful migration to RHEL. Really makes you think if NixOS is even used at work at all. This issue is one of many where NixOS owners feel no responsibility for NixOS, no ownership in NixOS and its continued development, thus fostering a culture of disinterest and abandonment. Very oddly similar to all the jokes about how "dad went to buy milk and never came back". @catdevz NixOS breaks all the time because everyone is expected to update everything all the time, rather than update just small pieces, like the stack of all the languages you build in. After half a year of barely managing to keep it running and developing new derivations for it, it was much easier to move over to RHEL and the pace of the project has seen a significant increase since. For 2 years I have been helping with devops job interviews and for the life of me, would could not find a single person who even knew what NixOS even is. Nobody even tried to bullshit us by saying "it's a *nix OS like linux or osx" which was a popular thing to say among nerds, in my teens. This should be a red flag for every hiring manager, for every HR, and for every solution architect that you should never let a NixOS system do anything at work, because that way you will have to pick between an unmaintainable nightmare that will absorb the entire capacity of the few persons in your team who know what they're doing with NixOS, or having a bunch of irreplacable people that lower your bus factor significantly. It's also a huge liability for the rest of the team, because usually the people with most experience have to take time off their normal duties to learn NixOS ahead of NixOS having yet another showstopping emergency while the NixOS experts are out of office - or they quit. |
Not if you're devops, not you're taking requests to endlessly update the nix-shell with requests from the whole team. The key to achieving failure here, was that there was absolutely no way to update nixpkgs - even if you managed to get a fresher copy past the firewalls, even moving by one commit further would break the nix-shell in 20 places. |
Issues like: #173
I hate to be that guy but I must be that guy now. It is for the greater good. I am sure that you understand:
"If you used Rust this would not be a problem.
Python is not that more productive than Rust after all."
-- That Guy
This statement only works though if all source is written in Rust. Mixes like with C++ always do not work well and drag in again all the bad things. Anyways. So I am aware that even if the devs wanted to it would not be an easy task at all. This is still worth as a general anti C++/Python message. And since I had to get through this installation none sense and this AI still does not work for me. I am afraid that you have now to listen to my dismay and other utter terror of lack of order for having dared to leave Rust lands.
I wrote plenty of lines of simple Rust source. Python is not going to be anymore productive than this so called "system language". Rust only sounds scary in its majestic title but is often used for a lot of things that got nothing to do with "system". Simple code in Rust is essentially like Java, C# or Python for that matter.
I do understand that these libraries are not only Python but also C++ which is the worst. However. It should be far more doable to get rid of Python first. Python is 31 years old. That is 310 years in silicon valley time. Rust had pattern matching since birth while Python only got it now for a year or so. It is time to upgrade and write real software. I do not see how Python/C++ could beat Rust's module system called Cargo and its database of Crates on crates.io. The only thing that might be a problem is the maturity of a Crate but certainly not the system itself.
I had a 1GB download for this "installation" just for some Python API. That is not how packing works, folks, That is how Python/C++ works. In Rust only the stuff used ends up in the binary. For Rust's Cargo itself an installation is not required either unlike with Conda. Rust's RustUp(Cargo/Compiler/Format/Doc, etc) is only used to for build time. You know. Like a real programming language for real software. Though this also goes back to C++ not only Python and its lack of an actual package system.
You can use Rust with VSCode easily too. No need for CLion or Visual Studio.
My own game logic/game engine project replaced C/C++/C# for good. GLSL and HLSL will be next. This treachery continues with GLSL and HLSL. And since I am also intending to use ML AI code for my own game beyond this text/image. That puts Python into my way again. Hence again a general anti C++/Python message. For higher level systems like a game you do not want to mess with a bazillion languages/APIs/tools if you can have only one. So this issue may not affect others as much as me. But now you are warned as to why I am not taking this lightly because I am the fool who as to learn and use: C/C++/C#/HLSL/GLSL/Python/Bison/Shmyson/Your Mom's Script
... and eventually yet another pile of **** that humanity made to solve one problem: How To Instruct A Computer To Do Things
I am not amused: -.-
My First Experience With Python
I hate to nag but I am afraid I have to share my initial experience with this productive programming language that I hear people talking about. And I have the feeling that more people will complain because AI is very wide spread these days and will spread way further. So way more people will get exposed to this.
As someone who also mods games I encountered many more languages than just C, C++, C#, F# , HLSL, GLSL, and of course Rust (One Language to Rule Them All) for game development. But I also for modding Java, Doom 3's C like script, World of Warcraft's LUA and now Python for so called scripting.
Judged by the time how long it takes(it still does not work for me) to execute simple code in txt2img.py(which should have been a CLI binary). Python by far is the worst thing I ever had to deal with in my entire life.
I tell you this: Lua and Python are a hoax like all non compiled languages. Their interpretive nature is of no good at all. Compiled languages like Java and C# are certainly better in all regards for so called scripting needs. Rust too actually.
Now to Python. After countless pip install commands One got 700MB of waste downloaded. Pure Rust source would pick only used code and compile it into the binary. No need for CMake or Condo which require their own install too again. One pip install imwatermark did install but not resolve its not found problem. I used a modified txt2img.py (taken from SD UI) without it and ran into a compilation error during startup. It says:
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(self.face_rec_model_path)?
I am sorry but what? Language versioning issues? A travesty like C/C++ at this point would have too already allowed me to execute its CLI binary. But not the productive language I hear so much about....
Python has no semicolons.
Maybe try F# instead of Python.
Python uses RETURN keyword. Rust does only in very special cases so mostly not at all.
Maybe try F# instead of Python.
Python uses GC. Rust has no GC and no simple code will require explicit life times to handle the Borrow Checker I think
Borrow Check is why Rust does not require a run time GC to handle memory automatically.
If you love GC try F#.
F# wins...
The list goes on with Python giving only then to take more back. That is not productive. That is a hoax. C and C++ does actually a similar thing with its compile times. They fool new programmers by giving the impression that they are easier to learn than Rust. Which is true for a Hello World+. But. Only then to force you to do debugging later(or handling dependencies later) during the worst time which is run time.
That is why Rust has a much steeper learning curve than C and C++ but it flattens out later to a C# and Java level of ease and productivity. Though the compile times are still rather long with longer code. Seems though the Rust compiler does not do multi threading much so there is room for improvement at least. But I am not hoaxing. Honestly Rust compiler ALWAYS will be at least a bit slower than all other compilers because it simply does more during that stage. Good thing that AMD is making faster CPUs these days... But frankly it is not that bad because it creates a massive amount of certainty that other languages do not provide.
Conclusion (2022/October/03)
This is all you have?
One half is chatbots.
The other half is off topic comments that got nothing to do with any kind of language so are off topic spam.
This is what your degree of "higher education" can produced regarding the languages Rust and your very own language Python that you know so much about?
You can not control what you do not understand. But spam is not hard to understand.... You are doomed...
The text was updated successfully, but these errors were encountered: