51–60 of 173 posts
You can build the equivalent simple c++ program by just calling `make` with no arguments. Though TBF then you have to type ./a.out, and so then you want to do `make && ./a.out` and then...
Shell scripts ...
Go haters are in full display with this one. LOL "go run" is yet another wonderful feature of an awesome language.
Now, go run.
I don't think it's simple. Just `go run` would be far more simple. Right now I first have to figure out if its `go run .` or `go run cmd/main.go` or some other thing.
I don't think it's simple. Just `go run` would be far more simple. Right now I first have to figure out if its `go run .` or `go run cmd/main.go` or some other thing.
Or, even better, `./main`
All this plus talk about non-standard JS runtimes like Node, but no mention that this is how browsers have worked almost forever.
That, and the ability to cross-compile without installing a cross-toolchain for the target platform. Having spent an inordinate amount of time writing build systems and compiling/distributing cross-toolchains, this is a _huge_ deal.
For TypeScript, "deno run" seems much the same? (It's only a subset of the JavaScript ecosystem, but you can import a lot of npms nowadays.)
Tangentially related: I am currently scoping out an idea for how language models could be used to augment decompilers like Ghidra. At a surface level, this was partially an intellectually interesting project because it is similar to a language translation project, however instead of parallel sentence pairs, I will probably probably be creating a parallel corpus of "decompiled" C code which will have to be aligned to…
an interesting project. go contains many source artifacts which make decompilation a bit more straight forward as well. I havent seen anyone really attempt this for go, but would be notable research
Shout out out to Bun (and Deno too?) for allowing you to treat typescript as an interpreted language. Great for scripting with all the bells and whistles.
(Go is great, just pointing out that running TS does not actually require NPM anymore)
Earlier quoted context omitted.
This is a good tip! It also captures what has been frustrating about golang for me. The language feels a bit stuck between simple default cases and allowing complexity. I feel like there are two relatively distinct populations of go developer: those who love how easy it is to start (true!) and those who are frustrated by the compromises the language has made to allow for more complex cases (required!). There's also a…
I don't get it. The default case is simple (go run .), and the complex case (specifying the relevant .go files one by one) is a little bit more complex. What's frustrating with that?