To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/DreamsofCode . You’ll also get 20% off an annual premium subscription.
What if we made a scripting language none of the things good about a scripting language. If you want to write scripts in C, compile a fucking executable 🤣
honestly how is this different from writing a program and compiling it. scriptistoe just takes the file and compiles it for you when you run the file with it. which is nice for fast debugging but its just an compile on execution thing. you could just have a program or nvim macro to compile on file save. and then just run the executable
I haven't used it myself but as far as I can see it: - Only recompiles it if the source code has changed (keeps hashes of source content) - Allows for extraneous build artifacts such as Cargo.toml to be included in the metadata to retain the one file nature of a script - Allows you to just give someone that opne script file and as long as they have scriptisto installed it should work for them too Still not sure it is for me. I'm too used to bash and Perl and see development in C and Rust to be completely different mindset.
@@grifferz so it's like Cmake or any other build tool, but it forces your files to stop being language compliant by forcing you to add the # at the top of the code. Cool. Useless.
@@Waffle4569 Yes, but what if you wanted something that the user could make changes to for configuration purposes. Storing everything in json or similar files isn't enough for all configuration needs.
Honestly, I hate bash as much as the next person but I don't see much value in this tool. I mostly only use scripts for work and there I have a folder in my dotfiles called scripts that's a collection of makefiles that clone the repo for a script, set it up(compile/make venv, etc) in the repos folder and then add an entry to the path in a script_paths.bash file that's sourced from my bashrc. Makefiles also have a clean option that remove a tools folder and path entry. This way you're more modular, get git tracking for each script individually which makes it easier to share and you can decide on a tool by tool basis what it is you want.
I also prefer to compile things when i can for scripts that require thoughtful planning - but for repetitive things where a single file is good enough, running feels faster than build + run even if not compiled
`cargo r` Runs it, compiles it. Copy the binary at will. I really don't see the point. Now, if we're talking a language that can actually do more with a couple of lines of code, like Python or Ruby, sure. But for Rust?
It might be nice for a small script you make small tweaks every so often, since the code is visible in the same place that you run it from. Also I'm to lazy to right docs so I often `cat` out the script to make sure I'm running the right one or what args it needs. It is a skill issue but whatever.
Omg lol, that's my tool. Thanks for making this video! My inspiration for writing this was a desire to write block scripts for i3bar in rust. So I can fetch deps transparently to access various data sources, Internet libraries. It is not packaged to Debian. And another tip is to use built in templates via `scriptisto new` so you don't have to write the build comments from scratch
All the language listed are all good for scripting, I don't really get the reason for saying that it's not suitable? If 'go run' command is already good enough, doesn't it only mean an external library like (scriptisto) is just adding unnessary dependencies / libraries to your project?
I wrote my own C-script shebang tool in bash. it's fun Rust is getting `cargo script` maybe sometime this year, which will allow single file packages that can use dependencies and stuff
As a side effect this is going to put build information inside of source files. THANK YOU!!!! Imagine a future with no build files because the source code has the information needed to build in it. And all build systems know how to leverage it. Also, your speech is very good. Solid elocution.
if you pan on using a script you made for a long time, and using a compiled lang, just compile it once and move the bin file to the /bin directory in linux (or another dir that is in the path)
This seems rather complicated tho. TCC works fine for C scripts since forever and has the benefit of not having to add configs etc. Obviously it only works for C, and there only for C90 and a subset of C99 (although honestly I don't use VLAs anyway, which I think is what they didn't implement, so it's fine for me), but for that it seems like a better alternative if you don't rely on some specific gcc or clang-specific intrinsics.
You're an inspiration. I use almost all the tools youve suggested. And You're one of those who inspired me into making my first video myself. Man ypu must spend a lot of time editing. Thanks!
Maybe for some situations you can use C+Lua or C++ with Sol (Lua lib). You can create a set of specific functions in C and call them from Lua, compile the whole thing once, and only edit the Lua file according to the project. I think this is the best way to get scripting speed and natively compiled code performance.
I use javascript and node, and have found myself reaching to it for scripting as well. I find it a bit hilarious that it actually works more seamlessly than go for this purpose.
I was wondering a week ago how I could use compiled languages for scripting. Bash is good for a lot of use cases, but when it comes to error handling, I struggle a lot. In that case I like to use compiled languages. Thanks for this video. It is a nice inspiration for me 👍
A tool is a tool is a tool, to abuse Gertrude Stein. So many technologies are tools in search of use cases. I am glad to hear you want to produce some bash content. I was flabbergasted to see your face on a video - from your voice I had imagined you being at least 40 - you come across as very well seasoned. Excellent content - as per usual.
Thank you! I'm definitely older than I look tbf! I think bash is one of those skills that I personally should know better, if you asked me to write a for loop without any reference, I don't think I could achieve it!
I don't understand the usecase for this at all, but it's neat that it exists i guess. I'm gonna stick to either just use bash or compile beforehand and use the binary when needed.
Yeah I agree, it's certainly not for me. That being said, having strong types in a script does feel nice, but I don't think this is the best way to achieve it.
This seems totally unnecessary. Also, I'm assuming it has to recompile your code on every init or implements a cache for the compiled binaries. Anyway, it seems like basically the same as compiling your own code, you even have to write the build command anyways. So yeah, I don't see the value, I'll probably just stay away from this
He says it caches the binaries and uses a hash to know when to recompile. Otherwise the rust example would take half an hour each time he invoked it. Imo it's pretty useful since you don't need a whole build setup for 1 file.
6:00 why is mot the best? Can we just run the script with go run, and called with a bash script only run `go run my_script`? Or just add a alias to the shell for it?
Compiled scripts are nice for speed, but they can easily be _much_ larger than an equivalent bash script without some pretty extreme measures. For actual scripts, I'll probably be using nushell for the most part for the foreseeable future. Also considering that my user and system environments are themselves effectively "compiled", there's really no overhead to just writing what would be a script in Rust or C and then just compiling when when rebuilding the environment. There are even standard functions specifically from making compiled scripts. I thought I remembered there being one for C, but I was only able to find one for Haskell, and a function to generate these script compilers. (Edit: found the C script function.)
Hey! Very much in time, yesterday I just started multibin project of rewriting some of my scripts to rust. Quickly I realised I need to have it go with dynamic library, as bins are kinda large otherwise
Hi, video is quite nice, but it lacks consistency. Every presented language with different example? And only last was used with template from scriptisto? Go template also has colouring dependency put into go.mod. In general this is overkill. They can be compiled easily to binary which can be shared. These scripts need specific compiler and scriptisto on the machine, so you cannot give them to everyone.
"Entr" can monitor changes and run specified commands once a change is detected like a makefile, which itself will know what to recompile based on what changed, rendering this entire program pointless.
Honestly, I can see this being useful for C/C++ codebases as an alternate to using using make files. Or CMake... I really hope that clang and gcc try and add scriptisto or something similar to their infrastructure!
Am I missing something? What was the point of all this? You're wrapping the compilation & execution of a perfectly working source file in a script? What do you stand to gain against having a Makefile or running cargo build/run?
It seems like a complex solution to a simple problem. Bash works for a simple sequence of command calls and python for anything more complex. Languages like C, Go, and Rust aren't designed for scripting and will lead to more problems. You can install python packages globally using your package manager. If not create an environment called global and install packages there.
Really cool project, people make amazing things. But for me I still doubt if it has a practical use case. You still need to install the whole thing as a dependency, scriptisto. And one reason why I also use a lot of Shell or Bash scripts is that it's far more standard on every Linux distro. Bash is installed by default, nothing more is needed. Shell scripts are also much simpler for actual system tasks, I mean when executing external commands is actually my primary goal. Good to mention is that Python is also pretty standard on Linux (maybe not on a fresh base Arch linux install, but tons of additional packages have it as a dependency), so I have used that for some system related scripts too, as it is very simple and also stored as a text file that does not require compilation. But for most actual system tasks it is still often more code to write, and shell scripts stay a simpler default in many cases. So real programming languages do I use for actual software development, both at work and personally, when actually building things.
Hey. I really enjoy your videos. Very good content, high value explanation of things. Would you be interested in making a go api with the new router? Didn't find any good videos. Would enjoy your way of making them in golang 🙂
I'd use python as it is already installed on most linux distros and on macos (not sure about windows though). It has everything you need out of the box and scripting feels more natural.
What is the reason to use this? To me, it feels more complicated then just writing pure C/Go/Rust and compiling it yourself. Bash often does the trick, and if speed is an issue, well, you're not really scripting anymore at that point, and a compiled program shouldn't be too hard to make then.
Me, wanting to write scripts for fun and automation but don't wanna use bash. 😭 Me picking the most personal and practical language that has maybe 1/10th the size of 'popular choices' 😁 Bell ringer by the way. 🔔
@@dreamsofcode *Takes a deep breath* So note this on a Nobara/Fedora machine and likely will be used as an automation server when put out to pasture when I update my machine, so for my use cases, I expect frequent changes, but it can be local over a network. And when I get my gaming machine, I will likely stay with this family of distros. I chose Nim and D. I like nimscript and rdmd. I like Nim for the python-like syntax and the powerful out of the box FFI. I like D for getting me out of my fear of curly bracketed C languages (maybe rust is next, **shiver** ); but more seriously for the speed and general use standard library. It has basically everything I need including edge cases for complex numbers, I/O, networking and HTTP, as well as being designed to be very 'generic and flexible'. I even compiled CPython recently and it wasn't particularly slow. For a command and with a spotty connection after all, one it was all on my machine, it works out of the box lol. So yeah, good videos man! Keep it up, and be sure to spread good technical and personable knowledge you can. 💜 Edit: Oh and I compiled MRI Ruby, which has a C based and it was much faster and smaller and I love Ruby! It was my scripting language of choice when I got here, and I owe it alot.
@@dreamsofcode I chose Nim (nimscript) and rdmd (D) for any scripting job in near and long term. I like Nim's python like syntax and since I expect to be doing alot of tinkering with CPython and MRI Ruby source (both of which I just compiled), it's C FFI interop is kind of smooth. I like D's huge standard library for out of the box functions and jobs you can do. Really, and since rdmd exists as a companion to the compiler, anything you can do with the standard library can be piped to your shebang shell. It is also got me over my fear of curly bracketed languages like C and Rust lol.
Agreed. Python is pretty good. I find it becomes a bit heavier once you need to use dependencies, but until that point it's a great choice for scripting.
We've been able to write scripts that run through a compiler or other preprocessor forever. Just point the shebang to a script that operates on the file. This is not new and doesn't require scriptisto or any other special purpose processor. I've been doing this for years and never thought it wasn't already common knowledge. Research it. Heck, try shebang that invokes a LLM and make your "scripts" natural language statements.
"is it worth it?" I once thought it is only a JS land thing that everything needs to be a useless wrapper on top of the builtins; even the simplest, like with rimraf. Looks like why should only JS junkies have all the fun!
Omg, I hate everything with this idea! This is awful and does not serve the purpose of a simple script anymore. This is a standalone application itself. Also, it requires the wanted language installed on the executing system. To get this stuff running with debugging, in the meantime, you can start a new service in Go or C to do the work. I personally prefer a solution like amber lang. It's a transpiler to make bash scripts maintainable with common syntax and transpiles and executed scripts, keeping it stupidly simple. I don't want to write complex software with bash or scripts, I just want to automate maybe 3 or 4 commands I would execute manually. Rest is a responsibility of my application
I've not see amber lang before! It looks pretty interesting and could potentially solve the syntax issue of bash. Going to do some research and might do a future video on it! Thank you for the recommendation!
I don't know, this still seems a little unwieldy. I've personally been trying to get into kotlinscript as a scripting language, which is theoretically quite nice, but of course would require kotlin as a dependency, which would make it equally unwieldy for anything beyond personal use.
This is just very complex makefile replacement. Which is totally unnecessary because make works great for a decades now already. Just use it. for Go and Java there is a go run and java commands also no need for additional tools at all
It's way easier to use python for scripting than C (or Rust, memory safety is pointless on a script), you have to reimplement the whole world just to do the simplest thing! (I love C, but in its intended use case, systems programming)
One cases would be long running scripts, you can save on memory use because you don't keep the interpreter all the time. I originally implemented scriptisto to feed custom scripts output to desktop status bars. I didn't want to have 10 Pythons hanging there
Great video as usual. The tool itself seems unnecessary to me... though I can see the desire it appeals to, I think. That said, I think the name is just the word for "scripter" in Esperanto, which means the name should be pronounced "scrip-TEES-to".
Thanks! I agree, I don't think this is the solution for writing scripts in compiled languages for myself. I knew I should have brushed up on my Esperanto!
personally, i think this is really cool but for now, imma stick to python and bash for scripting i already have a large enough collection of python and bash scripts
So, it’s a dumbed down make? If I need to use a compiled language as a script so much, I’d much rather have a precompiled binary and invoke it from an actual scripting language with actual support around it.
To try everything Brilliant has to offer-free-for a full 30 days, visit brilliant.org/DreamsofCode . You’ll also get 20% off an annual premium subscription.
v1: script is toe
v2: script is foot
V3: script is leg
We like to resolve problems that don’t exist, don’t we?
I was thinking the same thing…
Yeah, I'd just use any of the available script languages instead, this just seems tedious
If bash wasn't a problem, we wouldn't have developed a billion scripting languages. Small bash files probably have more bugs then a large C project.
programming is about solving problems
so programmers are problems solvers
they sometimes create problems too
in order to (re)solve those problems
What if we made a scripting language none of the things good about a scripting language. If you want to write scripts in C, compile a fucking executable 🤣
honestly how is this different from writing a program and compiling it. scriptistoe just takes the file and compiles it for you when you run the file with it. which is nice for fast debugging but its just an compile on execution thing. you could just have a program or nvim macro to compile on file save. and then just run the executable
I haven't used it myself but as far as I can see it:
- Only recompiles it if the source code has changed (keeps hashes of source content)
- Allows for extraneous build artifacts such as Cargo.toml to be included in the metadata to retain the one file nature of a script
- Allows you to just give someone that opne script file and as long as they have scriptisto installed it should work for them too
Still not sure it is for me. I'm too used to bash and Perl and see development in C and Rust to be completely different mindset.
@@grifferz so it's like Cmake or any other build tool, but it forces your files to stop being language compliant by forcing you to add the # at the top of the code. Cool. Useless.
@@tiranito2834having everything in one file is great for ephemeral scripts.
Not to mention a compiled exe will work on more than one person's machine. Isn't half the point of scripts that other people can easily run them?
@@Waffle4569 Yes, but what if you wanted something that the user could make changes to for configuration purposes. Storing everything in json or similar files isn't enough for all configuration needs.
8:03 Typo, It's called "ANSI Escape Code"
Exactly
Honestly, I hate bash as much as the next person but I don't see much value in this tool. I mostly only use scripts for work and there I have a folder in my dotfiles called scripts that's a collection of makefiles that clone the repo for a script, set it up(compile/make venv, etc) in the repos folder and then add an entry to the path in a script_paths.bash file that's sourced from my bashrc. Makefiles also have a clean option that remove a tools folder and path entry. This way you're more modular, get git tracking for each script individually which makes it easier to share and you can decide on a tool by tool basis what it is you want.
Why not just compile it?
I guess the idea is to keep it similar to the benefits of a script, such that you're able to contain everything you need in a single file.
I also prefer to compile things when i can for scripts that require thoughtful planning - but for repetitive things where a single file is good enough, running feels faster than build + run even if not compiled
`cargo r` Runs it, compiles it. Copy the binary at will. I really don't see the point. Now, if we're talking a language that can actually do more with a couple of lines of code, like Python or Ruby, sure. But for Rust?
It might be nice for a small script you make small tweaks every so often, since the code is visible in the same place that you run it from. Also I'm to lazy to right docs so I often `cat` out the script to make sure I'm running the right one or what args it needs. It is a skill issue but whatever.
@@dreamsofcode You mean like Go? LOL
Omg lol, that's my tool. Thanks for making this video!
My inspiration for writing this was a desire to write block scripts for i3bar in rust. So I can fetch deps transparently to access various data sources, Internet libraries.
It is not packaged to Debian. And another tip is to use built in templates via `scriptisto new` so you don't have to write the build comments from scratch
Thanks for the good work man!
Very nice. TCC from Fabrice Bellard has this feature for C - see ex1.c ex2.c.
All the language listed are all good for scripting, I don't really get the reason for saying that it's not suitable? If 'go run' command is already good enough, doesn't it only mean an external library like (scriptisto) is just adding unnessary dependencies / libraries to your project?
I wrote my own C-script shebang tool in bash. it's fun
Rust is getting `cargo script` maybe sometime this year, which will allow single file packages that can use dependencies and stuff
Shouldn't it be pronounced as a single word with the accent on the 2nd syllable? I was confused when you pronounced it as 3 separate words at 1:09.
For single file scripts this is pretty great. It's like an inline makefile/build script
The nix-shell shebang is another powerful way to improve or even replace this tool.
As a side effect this is going to put build information inside of source files. THANK YOU!!!! Imagine a future with no build files because the source code has the information needed to build in it. And all build systems know how to leverage it.
Also, your speech is very good. Solid elocution.
this gave me an idea to write a header-only library for C that will have tools to make scripting easier...
if you pan on using a script you made for a long time, and using a compiled lang, just compile it once and move the bin file to the /bin directory in linux (or another dir that is in the path)
This seems rather complicated tho. TCC works fine for C scripts since forever and has the benefit of not having to add configs etc. Obviously it only works for C, and there only for C90 and a subset of C99 (although honestly I don't use VLAs anyway, which I think is what they didn't implement, so it's fine for me), but for that it seems like a better alternative if you don't rely on some specific gcc or clang-specific intrinsics.
You're an inspiration. I use almost all the tools youve suggested. And You're one of those who inspired me into making my first video myself. Man ypu must spend a lot of time editing. Thanks!
Maybe for some situations you can use C+Lua or C++ with Sol (Lua lib).
You can create a set of specific functions in C and call them from Lua, compile the whole thing once, and only edit the Lua file according to the project.
I think this is the best way to get scripting speed and natively compiled code performance.
I use javascript and node, and have found myself reaching to it for scripting as well. I find it a bit hilarious that it actually works more seamlessly than go for this purpose.
Rust actually has a scripting feature built in! It’s in the nightly compiler but it works basically the same, and much easier
Scriptisto is an Esperantism I am sure.
BunJS shell feature is a charm, I use it as a bash alternative
I was wondering a week ago how I could use compiled languages for scripting. Bash is good for a lot of use cases, but when it comes to error handling, I struggle a lot. In that case I like to use compiled languages. Thanks for this video. It is a nice inspiration for me 👍
It's definitely a fun project, and worthwhile of a try in my opinion. I'd be interested to know what you build with it!
tcc also has a -run flag to run C files
A tool is a tool is a tool, to abuse Gertrude Stein. So many technologies are tools in search of use cases. I am glad to hear you want to produce some bash content. I was flabbergasted to see your face on a video - from your voice I had imagined you being at least 40 - you come across as very well seasoned. Excellent content - as per usual.
Thank you! I'm definitely older than I look tbf!
I think bash is one of those skills that I personally should know better, if you asked me to write a for loop without any reference, I don't think I could achieve it!
I also thought he is around prime's age
Dont get whats extra while writing and running the app as a script? enumerating the ENV?
Such a good video. As a Bash enthusiast my self, I can't wait for your future Bash related videos 👀
How am I supposed to enjoy this video? There's no catppuccin!
Me and catppuccin have broken up 😭
@@dreamsofcode :o whyyyy
@@dreamsofcodewhat's the new theme?
@@christopherwood6514 Tokyo night! I'm enjoying it a lot at the moment.
@@christopherwood6514 Lol replied from my other channel!
I don't understand the usecase for this at all, but it's neat that it exists i guess.
I'm gonna stick to either just use bash or compile beforehand and use the binary when needed.
Yeah I agree, it's certainly not for me. That being said, having strong types in a script does feel nice, but I don't think this is the best way to achieve it.
Making RUclips content, that's what most programing videos are about, showing unrealistic stuff just for the sake of getting engagement
This seems totally unnecessary. Also, I'm assuming it has to recompile your code on every init or implements a cache for the compiled binaries. Anyway, it seems like basically the same as compiling your own code, you even have to write the build command anyways. So yeah, I don't see the value, I'll probably just stay away from this
He says it caches the binaries and uses a hash to know when to recompile. Otherwise the rust example would take half an hour each time he invoked it. Imo it's pretty useful since you don't need a whole build setup for 1 file.
Can you share your tmux config to set the window number to that symbol? Tried to find in your GitHub but the config there looks outdated?
Can’t wait to use my c shell to launch my interpreted vim to write my interpreted kernel to run on my interpreted version of qemu!
Once cargo script RFC lands there would be no need to do this in Rust with external tooling
I'm excited for #!/usr/bin/env cargo
6:00 why is mot the best? Can we just run the script with go run, and called with a bash script only run `go run my_script`? Or just add a alias to the shell for it?
Sorry if that line wasn't clear. Using Go with scriptisto I don't think is the best, instead I much prefer to just use `go run`
Yeah, definitely better. The Rust example was terrible, better write the code and let cargo build or just use Go anyway.
Compiled scripts are nice for speed, but they can easily be _much_ larger than an equivalent bash script without some pretty extreme measures. For actual scripts, I'll probably be using nushell for the most part for the foreseeable future.
Also considering that my user and system environments are themselves effectively "compiled", there's really no overhead to just writing what would be a script in Rust or C and then just compiling when when rebuilding the environment. There are even standard functions specifically from making compiled scripts. I thought I remembered there being one for C, but I was only able to find one for Haskell, and a function to generate these script compilers. (Edit: found the C script function.)
I like awk cause it's both a command AND an entire programming language. It's great for processing CSV data too
Hey! Very much in time, yesterday I just started multibin project of rewriting some of my scripts to rust. Quickly I realised I need to have it go with dynamic library, as bins are kinda large otherwise
And here I was trying to learn Go as a replacement for my automation with scripts/packages in Python :p
Hi, video is quite nice, but it lacks consistency. Every presented language with different example? And only last was used with template from scriptisto?
Go template also has colouring dependency put into go.mod.
In general this is overkill. They can be compiled easily to binary which can be shared. These scripts need specific compiler and scriptisto on the machine, so you cannot give them to everyone.
"Entr" can monitor changes and run specified commands once a change is detected like a makefile, which itself will know what to recompile based on what changed, rendering this entire program pointless.
Honestly, I can see this being useful for C/C++ codebases as an alternate to using using make files. Or CMake... I really hope that clang and gcc try and add scriptisto or something similar to their infrastructure!
V is set up really nice for this type of scripting. That's my go to for complex scripting.
Am I missing something? What was the point of all this? You're wrapping the compilation & execution of a perfectly working source file in a script? What do you stand to gain against having a Makefile or running cargo build/run?
I'm pretty sure I brought up similar points.
Anything is better than makefiles. Instead of a makefile you could use this to write your own build system
you have a face
i feel betrayed...
It seems like a complex solution to a simple problem. Bash works for a simple sequence of command calls and python for anything more complex. Languages like C, Go, and Rust aren't designed for scripting and will lead to more problems.
You can install python packages globally using your package manager. If not create an environment called global and install packages there.
Really cool project, people make amazing things. But for me I still doubt if it has a practical use case. You still need to install the whole thing as a dependency, scriptisto.
And one reason why I also use a lot of Shell or Bash scripts is that it's far more standard on every Linux distro. Bash is installed by default, nothing more is needed.
Shell scripts are also much simpler for actual system tasks, I mean when executing external commands is actually my primary goal.
Good to mention is that Python is also pretty standard on Linux (maybe not on a fresh base Arch linux install, but tons of additional packages have it as a dependency), so I have used that for some system related scripts too, as it is very simple and also stored as a text file that does not require compilation.
But for most actual system tasks it is still often more code to write, and shell scripts stay a simpler default in many cases.
So real programming languages do I use for actual software development, both at work and personally, when actually building things.
I'd love to see some more bash content
Hey. I really enjoy your videos. Very good content, high value explanation of things. Would you be interested in making a go api with the new router? Didn't find any good videos. Would enjoy your way of making them in golang 🙂
was it an intentional pronunciation choice? i'b betting the akshual way was supposed to be akin to virtuoso "skrip-tee-sto"
I'd use python as it is already installed on most linux distros and on macos (not sure about windows though). It has everything you need out of the box and scripting feels more natural.
What is the reason to use this?
To me, it feels more complicated then just writing pure C/Go/Rust and compiling it yourself.
Bash often does the trick, and if speed is an issue, well, you're not really scripting anymore at that point, and a compiled program shouldn't be too hard to make then.
I think I came to the same conclusion at the end of the video :)
Pls tell your alacrity window size
I’m not the biggest fan of bash and do prefer C but that is just too much boilerplate for a script.
Surely Python would be preferred.
Me, wanting to write scripts for fun and automation but don't wanna use bash. 😭
Me picking the most personal and practical language that has maybe 1/10th the size of 'popular choices' 😁
Bell ringer by the way.
🔔
Which language did you choose? Maybe I can do a follow up 😁
@@dreamsofcode *Takes a deep breath*
So note this on a Nobara/Fedora machine and likely will be used as an automation server when put out to pasture when I update my machine, so for my use cases, I expect frequent changes, but it can be local over a network. And when I get my gaming machine, I will likely stay with this family of distros.
I chose Nim and D. I like nimscript and rdmd. I like Nim for the python-like syntax and the powerful out of the box FFI. I like D for getting me out of my fear of curly bracketed C languages (maybe rust is next, **shiver** ); but more seriously for the speed and general use standard library. It has basically everything I need including edge cases for complex numbers, I/O, networking and HTTP, as well as being designed to be very 'generic and flexible'.
I even compiled CPython recently and it wasn't particularly slow. For a command and with a spotty connection after all, one it was all on my machine, it works out of the box lol. So yeah, good videos man! Keep it up, and be sure to spread good technical and personable knowledge you can.
💜
Edit: Oh and I compiled MRI Ruby, which has a C based and it was much faster and smaller and I love Ruby! It was my scripting language of choice when I got here, and I owe it alot.
@@dreamsofcode I chose Nim (nimscript) and rdmd (D) for any scripting job in near and long term. I like Nim's python like syntax and since I expect to be doing alot of tinkering with CPython and MRI Ruby source (both of which I just compiled), it's C FFI interop is kind of smooth. I like D's huge standard library for out of the box functions and jobs you can do. Really, and since rdmd exists as a companion to the compiler, anything you can do with the standard library can be piped to your shebang shell. It is also got me over my fear of curly bracketed languages like C and Rust lol.
I am not sure if my comment got filtered twice, so last try, I picked D and Nim (rdmd) and (nimscript)
@@twenty-fifth420 This one made it through! Nimscript is an interesting prospect to try out!
I thought this video would be about bash)))) It's very useful, but I think for a small project.
basically is automate the process of compiling
is it a script if its compiled anyways?
I love to use Python for quick scripts. It generally performs better than bash while also being easier to use
Agreed. Python is pretty good. I find it becomes a bit heavier once you need to use dependencies, but until that point it's a great choice for scripting.
@@dreamsofcode Agreed, dependencies are a nightmare in python lol
@@Mempler Not just dependencies, but also python versions
@@dreamsofcode will consider using Scriptisto to solve that problem for Python too. They have a python-pip template.
Doesn't poetry solve this problem?
We've been able to write scripts that run through a compiler or other preprocessor forever. Just point the shebang to a script that operates on the file. This is not new and doesn't require scriptisto or any other special purpose processor. I've been doing this for years and never thought it wasn't already common knowledge. Research it. Heck, try shebang that invokes a LLM and make your "scripts" natural language statements.
"is it worth it?"
I once thought it is only a JS land thing that everything needs to be a useless wrapper on top of the builtins; even the simplest, like with rimraf. Looks like why should only JS junkies have all the fun!
For C, we have cling. For Rust, we have irust. For python, we can just use it as is.
I am not a go programmer so not sure about this.
Handsome though
Bash content!
I’m no expert but why not just run the binary to skip the compilation step?
“Script-is-toe”? It’s scrip-tee-stow… I’m 99% sure.
“She-bang”? It’s shuh-bang… I’m 100% sure.
finally. i can now script with bfk
let's write another program to run scriptisto
To learn Go , i bruteforced making scripts that would take seconds in python just because
Why does he pronounce everything like that "She-bang", "Script-is-toe" wtf :D
Now let's try amber-lang. It's in early stages of development but it should be an interesting experiment
On my way to run scripts in x86 assembly
BASHH CONTENT LESSGOOOO
Well, if I want to use c or c++ for scripting, I can use cling for that.
Omg, I hate everything with this idea! This is awful and does not serve the purpose of a simple script anymore. This is a standalone application itself. Also, it requires the wanted language installed on the executing system. To get this stuff running with debugging, in the meantime, you can start a new service in Go or C to do the work.
I personally prefer a solution like amber lang. It's a transpiler to make bash scripts maintainable with common syntax and transpiles and executed scripts, keeping it stupidly simple.
I don't want to write complex software with bash or scripts, I just want to automate maybe 3 or 4 commands I would execute manually. Rest is a responsibility of my application
I've not see amber lang before! It looks pretty interesting and could potentially solve the syntax issue of bash. Going to do some research and might do a future video on it!
Thank you for the recommendation!
no not the "she bang" 😭
great now lets try it with zig build files
Even normal zig trips me up 😭
I write all my scripts in bash, and honestly kind of hate it.
I just use Nu(because my shell is Nushell) or nim for writing scripts. Bash is just so yucky.
This is actually pretty handy, great find man!
nutshell is OP for scripting
I don't know, this still seems a little unwieldy. I've personally been trying to get into kotlinscript as a scripting language, which is theoretically quite nice, but of course would require kotlin as a dependency, which would make it equally unwieldy for anything beyond personal use.
I love your videos! Could you do a video about your setup? I'd love to know which OS you're using and what PC hardware you have.
Absolutely! I'm also doing some twitch streams as well
Might just be simpler to use make and run whatever language you want.
Does the LSP work though? If not, It might not be that ergonomics!
It's hit or miss depending on the language. For Go it worked pretty well, but for Rust it would break.
@@dreamsofcode I heard that there is an RFC rust script currently im its work. Hopefully that would make things really intresting
anything bigger than 10 lines, I write in ruby
writing a "one file script" in compiled languages is weird in the first place
I dont really see a usage for this tbh, as you concluded at that point just use bash/zsh for your scripts or python
Yah, agreed. It was still fun to play with though.
@@dreamsofcode oh yeah I could see it being fun to toy with
But have you ever heard of ansible?
Why are we making network requests in scripts?
This is just very complex makefile replacement. Which is totally unnecessary because make works great for a decades now already. Just use it. for Go and Java there is a go run and java commands also no need for additional tools at all
This is awesome!
Can you please make a video on Zellij how to use it with Nvim it would be tool helpful.`
Absolutely! That one sounds like it'll be perfect for my second channel: Dreams of Autonomy
@@dreamsofcode great will wait for it btw thanks for zoxide video
It's way easier to use python for scripting than C (or Rust, memory safety is pointless on a script), you have to reimplement the whole world just to do the simplest thing! (I love C, but in its intended use case, systems programming)
One cases would be long running scripts, you can save on memory use because you don't keep the interpreter all the time. I originally implemented scriptisto to feed custom scripts output to desktop status bars. I didn't want to have 10 Pythons hanging there
Great video as usual.
The tool itself seems unnecessary to me... though I can see the desire it appeals to, I think. That said, I think the name is just the word for "scripter" in Esperanto, which means the name should be pronounced "scrip-TEES-to".
Thanks! I agree, I don't think this is the solution for writing scripts in compiled languages for myself.
I knew I should have brushed up on my Esperanto!
personally, i think this is really cool
but for now, imma stick to python and bash for scripting
i already have a large enough collection of python and bash scripts
That's pretty much how I feel about it as well! It's def interesting but I think the portability of bash is hard to beat.
@@dreamsofcode tbh, i think python may be better suited as its easily available cross platform
Just build the damn script and use it, or maybe a makefile!
So, it’s a dumbed down make?
If I need to use a compiled language as a script so much, I’d much rather have a precompiled binary and invoke it from an actual scripting language with actual support around it.
I love bash