I mean, sure, there's plenty of ways to get the intended character/glyph into the terminal; but I really hope that we don't start doing that regularly as is implied above.
> FYI: This was renamed from "Tex" to avoid confusion with TeX -- This project is now called Teex! The GIFs below might still mention tex -- just replace that in your commands with teex
@dang can you rename the title of this submission as well?
Hey all! Thanks for all the enthusiasm for this little hacky tool. I'll be working on renaming the cli tool to 'teex' soon to avoid conflicts with TeX.
Maybe don't sweat it. I keep a bookmark folder with all the threads on HN where the primary form of comment is complaining about the name.
It's a pastime here, and it's a great way to provide a low effort comment that the community will upvote.
In reality people don't google search for the name of a tool they already know, and if folks are looking for a scripting language for their system, they'll find it via Google, not some already-known-to-nerds name.
That said, tex is short, and overlaps with a lot of stuff not even nerdy, so teex will probably help set you apart until the fanboys of some other obscure project called teex come to the party :)
I think you're not realizing how ubiquitous TeX, and the executable `tex` are. It seems like a bad idea to overlap with something so commonly already installed.
Neither did the low effort comment that didn’t finish reading my previous one, nor did it explain new information about how tex is a bad name. The entire point of this thread was that just saying it has the same name isn’t really helpful.
All that said, yes, it was harsh and needless, thanks for calling me out, we can all be better.
I did make it to the end of your comment. Your comment presupposed the reason us nerds (how is this an insult on HN of all places?) didn't think the name was a good idea was searching and branding. I was saying my problem with it was overlapping executable names. This wasn't new information in the comment section as a whole, but judging by your comment it seemed to be new information to you.
It makes sense that you wouldn't use TeX at Redhat, but as a professional mathematician, I've never met anyone in math who doesn't use it. Different fields use different tools.
> we can all be better
Sure, but I didn't, and won't, directly attack you or your work. My sin was 1) omitting that it is ubiquitous in mathematical sciences in particular, and 2) simply not realizing you already knew the info about the executable name I brought up and just didn't care. Since you didn't even mention the only part I cared about with the name I thought it was new information for you. Show some charity.
It’s tough to put all the context out there - obviously I’m guilty there too - I don’t even think searchability is a real reason, and overlapping executables are a thing but still not that tricky for most folks who are using a CLI.
I’m mostly annoyed with how every time something like this happens lots of people just comment on the name and not the substance of the project, it’s such a huge distraction.
I studied solar physics but my PIs were in their 70s so all drafts were reviewed in MS Office. I would have liked to have a reason to use something more classy, but that’s how it goes.
I appreciate your reply, and I apologize for being an asshole. I’ll take this with me as I try to be less of an asshole going forward, if you search my history it may look like I never learn, but I’m always trying :)
At work someone got annoyed with the phrase assume good intentions, and proposed an alternative: ask compassionate questions. I’ve been thinking a lot about this and I will try to do that next time I start making assumptions or before I blow my lid on a stranger, and it shouldn’t matter that you’re obviously a decent person, but I still appreciate it.
Thanks for the thoughtful reply. On the original topic, I actually think we agree for the most part. On the slightly broader topic of people complaining about names too much in general, I totally agree. I have a bad habit of pitting my self against all sides of internet debates (like I said above, I'm a mathematician, and that totally extends to my personality in some fairly stereotypical ways).
> ask compassionate questions
I like that! One of my favorite online communities formed around a blog where the first post explicitly talked about the principle of charity, but it's not always obvious how to actually follow through with the idea. This is a really good way to do it.
Ha, bravo for changing the name so quick! I must confess, I clicked on the link, then read the comments and was super confused about the hubbub as it was called Teex, and not Tex. Cool project, hope you are able to keep it up!
I love this, and I'm excited that you've finally released it!
One of the biggest issues I run into with using Elixir as a scripting language is the difficulty
of making use of libraries in a REPL without first installing them into a Mix project. Sometimes I really just want to open up a shell that has access to my HTTP client + JSON parsing library of choice, and until now, my workaround has been using a Mix project that I toss everything into.
I'm very excited to dive through the code and see how you've implemented everything!
There is a huge problem with this sadly, the startup time of the BEAM is too much! I was thinking about having a running VM process and injecting code directly, but I think this could be quite insecure. Love the idea though.
Totally understandable concern, in my quick experiments I haven't been bothered too much by the bootup time. But there's definitely better performance aware solutions for scripting
You could spawn independent actors for each invocation. That provide a degree of separation and be fine for secuirty, if the beam process was run as your user pid. Handling multiple stdin/stdouts would take some work, but doable with standard erlang libraries.
hi
{"init terminating in do_boot",0}
init terminating in do_boot (0)
Crash dump is being written to: erl_crash.dump...done
real 0m0.304s
user 0m0.117s
sys 0m0.010s
Ok, so 300 ms is clearly too much, but that's running a bunch of stuff.
Turning a bunch of stuff off, I get
time /usr/local/lib/erlang23/bin/erl -eval 'io:format("hi~n"), halt(0, [{flush, false}])' -noshell -start_epmd false -boot no_dot_erlang
hi
real 0m0.077s
user 0m0.094s
sys 0m0.008s
(I tried tuning down the number of schedulers, but couldn't get the real time lower)
This is still a lot worse than bash, but about 75 ms is sort of okish. Maybe a non-stock boot file could help. I usually plan for my BEAMs to run for months or years, so I don't worry too much about startup time :)
Nice that you’ve managed to speed it up quite a lot! Still it’s fairly slow, that’s why I was thinking about streaming stuff to a running BEAM from a Golang executable, say. Presumably then this problem goes away (compilation may still take a while). I guess if the #! just streams the file content over we are still protected by the execution bit, but what about malicious programs streaming their own content?
You could do something like that, but it adds a lot of complexity. I suspect if I can get the time down to 75 ms with a frw minutes of fiddling, someone who actually cares to run this could spend a couple hours or days on it and get it down to 30ms, which should be tollerable. Reduce as much runtime startup as possible (probably allocator tuning), and then reduce or postpone as much OTP startup as possible.
Otherwise you have to deal with things like how do you kill one script without killing the others, version fun including what happens if you are running scripts and update the beam, how to keep scripts separated for reals, etc.
But would that be more insecure than running arbitrary scripts on your machine? I imagine you could build something akin to Ruby's spring for elixir, might be interesting.
Elixir’s ability’s to be used as a scripting language due to compile time has been one of its few weakness IMO against other languages such as Python and Go. Will be interesting to see if this changes the game.
> Does this get around the issue of the BEAM taking a while to spin up?
I'd be interested in hearing the answer too.
One of the things that has held back Clojure's adoption as a general-purpose CLI scripting language has been the cost of JVM + Clojure bootstrapping. It's not long in the grand scheme of things, but 1 second matters a lot when chaining commands in the shell. There is now a CLI scripting version of Clojure that gets around this issue by running Clojure (and some bundled libraries) as native code through Graalvm native-image: https://github.com/borkdude/babashka
That’s awesome! The only other painpoint of using Elixir for ad-hoc script is terrible IEX experience.
Canceling a line that you made mistake in is nearly impossible without loosing the whole existing context, pasting multiline pipelines is a no-go. I hope that iex on par with irb will become reality someday.
That's cool, thanks. I always create dummy projects to be able to quick test a library or develop a few lines of code in the REPL and wished I could test them without doing a "mix new". Even better than that is the ability to script with libraries.
However, I would recommend a different name to prevent confusion with Donald Knuth's TeX: https://en.wikipedia.org/wiki/TeX