4 ms·

I can't go along with your reasons at all (installing go on every machine is not solving a portability problem, it is the portability problem) but I'm going to

I can't go along with your reasons at all (installing go on every machine is not solving a portability problem, it is the portability problem) but I'm going to leave that aside. can Go be used REPL as a shell CLI? and do everything I need to do from the CLI? because that's why I use bash for scripting. An equal amount of time I spend typing at the command line, and I one language is the language I want to use.

mirashii 3y ago
It’s not go as a literal replacement for bash, as in you write golang when interacting with your own machine. It’s go binaries instead of bash scripts. You’re still distributing one file, but now with all the GP’s stated benefits
dharmab 3y ago
There's a Go REPL called YAEGI, but it's not a similar experience as using a shell.
traceroute66 3y ago
> (installing go on every machine is not solving a portability problem, it is the portability problem) but I'm going to leave that aside. What a clueless reply. Complete FUD. Yeah, you can "leave that aside" because you have no clue what you're talking about. The ONLY place Go needs to be installed is on the developer's machine. With Go you write, you compile/cross-compile and SHIP THE COMPILED BINARY job done. Do some homework next time before engaging in completely unfounded FUD.
- wrboyce 3y ago
  Can’t help but feel like the tone of your response is completely uncalled for.
  - traceroute66 3y ago
    > Can’t help but feel like the tone of your response is completely uncalled for. Literally five seconds on Google could have shown the guy he was completely wrong. But no, instead he posts unfounded FUD about how he will courteously "leave aside" the demonstrably INCORRECT claim that Go runtime needs to be installed on all machines that a Go program runs on. So don't give me a hard time about it when it was that poster who made the original arrogant comment.
- jpfr 3y ago
  I think the question assumed that you can run go in a script-language mode. Because you do want the source of shell-scripts on the local machine. So it is easy to make changes by system admins/non-developers. Scripting is for glue functionality after all…
  - traceroute66 3y ago
    > So it is easy to make changes by system admins/non-developers. Scripting is for glue functionality after all… You can also use env-vars and flags in Go. Which many would argue leads to more robust "admin glue functionality", because the admin controls how much non-admins can mess around with instead of allowing them to mess around with the core shell-script functionality.
- fsckboy 3y ago
  (i don't mind if people use a rude tone, we're human. i just don't like when people are wrong, or interpret others wrong) in corporate environments, it is not easy to (nor should it be) to require every desk to install Go. If you are hired to script something (and scripts are even more important in corporate environments) and require a new piece of software to be installed, and a new language for staff to maintain, it's imposing a great burden and could very well be rejected. I don't not know what I'm talking about, and I'm not trying to FUD, I'm trying to suggest "gird your loins". But also, I said that was not the point of my comment, I just didn't want you to think that through my silence I had accepted your earlier suggestion.
vinceguidry 3y ago
Bash is not a language, it's a shell. There is a big difference, and the differences will bite you in the ass until you learn to recognize them. For one, bash has no standard library. Different machines will have different things available. It's weird that you cite portability and then use the one solution that's pretty much the least portable. At least if you build on, say the Win32 API, you know exactly what machines are going to be able to run it. Bash? Well you pretty much have to know exactly what the other machine is running in order to have a clue about whether or not it will work. I'd say the most portable thing you can build with that's script-y enough to be pleasant is likely Ruby. If you can avoid using things introduced with Ruby 3, keep in mind platform differences and the abstractions Ruby has built-in to deal with them, and stick with stdlib, it will likely run on just about every machine with just about any Ruby. Otherwise maybe perl?
- fsckboy 3y ago
  I wrote another comment, I guess I didn't post it. Perl made a run at being the standard middle layer language like bash 30 years ago. Learning perl back then was different than for people to learn today. Back then, everybody would have known bash, and awk, and grep, and sed, and perl borrowed the their syntax/semeantics so as soon as you started using it, it was like you alrady knew it. But perl followed a trajectory of being more complicated and less intuitive, so nobody wanted it to replace the shell, but it could have had things gone differently. bash used to be "a shell" and "the shell" before graphical shells became the norm. Now bash is a REPL and programming language, and you need to run an "ANSI terminal shell" to access it :) 1. the command line has a syntax of it's own ("readline", generally standard across different shells, in this instance enforced by bash) and then 2. bash has its own language you can use, turing complete, with if-branches and loops, functions, some return values, global values (env) but also file i/o can be used as up-down argument passing, i/o and you can call readline over and over 3. there are certain conventions for "filters" that fit into the above framework, and they impose a small variety of contentions onto the command lines which nest within readline syntax. it has warts, and I really wish there was a general desire to fix them, but I guess I'm going to have to want it enough to do it myself because i've had the same ideas for 30 yrs now and nothings been happening :( last point, people aren't picking up on the importance some of us place on a language which can script that is the same language that is the command line. We don't want two languages, we want one. i.e. a language with a REPL

mirashii 3y ago

It’s not go as a literal replacement for bash, as in you write golang when interacting with your own machine. It’s go binaries instead of bash scripts. You’re still distributing one file, but now with all the GP’s stated benefits

dharmab 3y ago

There's a Go REPL called YAEGI, but it's not a similar experience as using a shell.

traceroute66 3y ago

> (installing go on every machine is not solving a portability problem, it is the portability problem) but I'm going to leave that aside. What a clueless reply. Complete FUD. Yeah, you can "leave that aside" because you have no clue what you're talking about. The ONLY place Go needs to be installed is on the developer's machine. With Go you write, you compile/cross-compile and SHIP THE COMPILED BINARY job done. Do some homework next time before engaging in completely unfounded FUD.

wrboyce 3y ago
Can’t help but feel like the tone of your response is completely uncalled for.
- traceroute66 3y ago
  > Can’t help but feel like the tone of your response is completely uncalled for. Literally five seconds on Google could have shown the guy he was completely wrong. But no, instead he posts unfounded FUD about how he will courteously "leave aside" the demonstrably INCORRECT claim that Go runtime needs to be installed on all machines that a Go program runs on. So don't give me a hard time about it when it was that poster who made the original arrogant comment.
jpfr 3y ago
I think the question assumed that you can run go in a script-language mode. Because you do want the source of shell-scripts on the local machine. So it is easy to make changes by system admins/non-developers. Scripting is for glue functionality after all…
- traceroute66 3y ago
  > So it is easy to make changes by system admins/non-developers. Scripting is for glue functionality after all… You can also use env-vars and flags in Go. Which many would argue leads to more robust "admin glue functionality", because the admin controls how much non-admins can mess around with instead of allowing them to mess around with the core shell-script functionality.
fsckboy 3y ago
(i don't mind if people use a rude tone, we're human. i just don't like when people are wrong, or interpret others wrong) in corporate environments, it is not easy to (nor should it be) to require every desk to install Go. If you are hired to script something (and scripts are even more important in corporate environments) and require a new piece of software to be installed, and a new language for staff to maintain, it's imposing a great burden and could very well be rejected. I don't not know what I'm talking about, and I'm not trying to FUD, I'm trying to suggest "gird your loins". But also, I said that was not the point of my comment, I just didn't want you to think that through my silence I had accepted your earlier suggestion.

vinceguidry 3y ago

Bash is not a language, it's a shell. There is a big difference, and the differences will bite you in the ass until you learn to recognize them. For one, bash has no standard library. Different machines will have different things available. It's weird that you cite portability and then use the one solution that's pretty much the least portable. At least if you build on, say the Win32 API, you know exactly what machines are going to be able to run it. Bash? Well you pretty much have to know exactly what the other machine is running in order to have a clue about whether or not it will work. I'd say the most portable thing you can build with that's script-y enough to be pleasant is likely Ruby. If you can avoid using things introduced with Ruby 3, keep in mind platform differences and the abstractions Ruby has built-in to deal with them, and stick with stdlib, it will likely run on just about every machine with just about any Ruby. Otherwise maybe perl?

fsckboy 3y ago
I wrote another comment, I guess I didn't post it. Perl made a run at being the standard middle layer language like bash 30 years ago. Learning perl back then was different than for people to learn today. Back then, everybody would have known bash, and awk, and grep, and sed, and perl borrowed the their syntax/semeantics so as soon as you started using it, it was like you alrady knew it. But perl followed a trajectory of being more complicated and less intuitive, so nobody wanted it to replace the shell, but it could have had things gone differently. bash used to be "a shell" and "the shell" before graphical shells became the norm. Now bash is a REPL and programming language, and you need to run an "ANSI terminal shell" to access it :) 1. the command line has a syntax of it's own ("readline", generally standard across different shells, in this instance enforced by bash) and then 2. bash has its own language you can use, turing complete, with if-branches and loops, functions, some return values, global values (env) but also file i/o can be used as up-down argument passing, i/o and you can call readline over and over 3. there are certain conventions for "filters" that fit into the above framework, and they impose a small variety of contentions onto the command lines which nest within readline syntax. it has warts, and I really wish there was a general desire to fix them, but I guess I'm going to have to want it enough to do it myself because i've had the same ideas for 30 yrs now and nothings been happening :( last point, people aren't picking up on the importance some of us place on a language which can script that is the same language that is the command line. We don't want two languages, we want one. i.e. a language with a REPL