151–160 of 173 posts
Earlier quoted context omitted.
Or, even better, `./main`
That's not better but confusing as the "main" binary doesn't exist (The main point of go run), and you'd always have to type the full name as you can't autocomplete it.
Earlier quoted context omitted.
> Where does Go fit in here? Where you move past academic language discussion and start using the tooling. Typescript is a pretty nice language but the tooling around it is practically unusable. It's laughable how bad it is. Outside of browser work, you're going to pick Go – and still would even if they made the language 10x more flawed – over Typescript every time just to not have to deal with that ecosystem. Grante…
Can you elaborate on what's hard about TS tooling? It's really easy to just use `npx tsc`
Golang is such a elegant language. But comparing it to JavaScript isn't fair. JavaScript has paid my bills for years, but it's held together by collective hope. The only thing missing is a decent mobile framework. I'm using Fyne, but it just looks dated. At least for my current app it's functional though.
Eh, I still don't get it. Go seems too high level for low level work - use Rust, manage your own memory, no garbage collector. Go also seems too low level for high level work - use TypeScript with all the nifty ES6 features, powerful type system, exceptions, etc.. Where does Go fit in here?
You can solve most problems with if-else and loops. This wasn't something I was aware of before Go, but now I see how simple it is and can be.
It strips the problem domain down to its core because you're forced to express the solution in the simplest form it can be. I know a lot of Go haters throw vitriol for exactly this reason (see fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang), but the truth is simplicity really gets you 80% of the way and most of the time that's enough.
Earlier quoted context omitted.
have you ever used tinygo? I have been curious how much that project gets used. It seems to me that rust is probably going to be the language of choice some point in the future.
I looked at that recently for a project I'm working on, but walked away when I found that important parts of the net package are pretty much nonexistent on ESP32. You know, like net/http, for example... I might have misread the docs, but somehow I doubt it.
> Yeah, and then what happens if you want to use modern syntax like esmodule, or maybe you want to use types with typescript? You are going to have to use npm. I don't understand what the problem is here? Every installation of Node comes bundled with npm. If it doesn't, that is a package maintenance problem. > Fun fact: One of the understated features go run is that it will automatically download any dependencies the…
> Every installation of Node comes bundled with npm. If it doesn't, that is a package maintenance problem. Not really. Ubuntu's node comes without npm, and to install the latter it wants to get about a hundred of dependencies. Mind you, this is still one of the most popular distros. Would you call their approach "a problem"?
If you are using an unofficial repository, and that maintainer did not include npm in his Node package, then yes I would consider that a problem.
> to install the latter it wants to get about a hundred of dependencies
Yeah, as software engineers, let's discourage code reuse, shall we?
Node and npm are not trivial pieces of software. I expect it to have lots of dependencies. This is hardly surprising.
[0] https://nodejs.org/en/download/package-manager#debian-and-ub...
> Yeah, and then what happens if you want to use modern syntax like esmodule, or maybe you want to use types with typescript? You are going to have to use npm. I don't understand what the problem is here? Every installation of Node comes bundled with npm. If it doesn't, that is a package maintenance problem. > Fun fact: One of the understated features go run is that it will automatically download any dependencies the…
> I don't understand what the problem is here. Every installation of Node comes bundled with npm. If it doesn't, that is a package maintenance problem. Node and npm are two commands, and when you go to find packages, you will see people telling you to use pnpm, yarn, or npm. I would expect one tool to do this for me, especially for the most popular language in the world. > This feels like a massive antipattern. Why i…
Also, a proxy and a package registry are not the same thing.
Earlier quoted context omitted.
> Most of these examples don’t automatically fetch the dependencies. Quite frankly, I don't want to automatically fetch dependencies at the same time I am running the code . IMO those should be separate steps, and combining them together in one is not a good idea.
Why not ?
Running the code is a separate step from determining what code I am going to run; the latter includes determining exactly what versions of all dependencies I am going to run. The two should not be combined.
Earlier quoted context omitted.
> Most of these examples don’t automatically fetch the dependencies. Quite frankly, I don't want to automatically fetch dependencies at the same time I am running the code . IMO those should be separate steps, and combining them together in one is not a good idea.
"go mod download && go run ." What's the point in making `go run` error out when it already knows what dependencies to get and how to get them.
No: "go mod download" if I want to update dependencies; then look to see what got updated and how it will affect what I'm doing. Then "go run".
> What's the point in making `go run` error out when it already knows what dependencies to get and how to get them.
Because I don't care what "go run" knows. I care what code is going to run when I say "go run". I want that code to be the code I already know is there and understand. I don't want it to be some new code that "go run" downloads because it sees that an update to a dependency is available. Downloading that update and understanding what effects it has is something that I want to do before "go run", not as part of it.
Earlier quoted context omitted.
As an embedded developer I shudder to think of all of the work that would go into /runtime run source/ to have it build objects, link them into some kind of format, convert the format to a series of flash addresses and data, connect to my JTAG over a network, halt execution, erase the flash, load the executable file into flash, verify the load, and try to signal a PMIC or other chip to reset the device to start it ba…
You have to do that work anyway... Why not encode it in your build system? (Admittedly I have never tried this with a modern build system. My real world approach for that would be a janky phony rule in a Makefile, with a bunch of MAKE_VARS the user has to set on the cmdline/in the environment to set up the toolchain/serial port etc. But in principle I have always believed it should be possible to make this process as…
Why must everything be explicit? Wrap it all up into one var.
cmake -DBUILD_FOR=esp32 .
For other languages and build systems, a runtime run sourcefile is the easiest way to get someone going, leave the edge cases out. Just get it running so they can hack on it.
Earlier quoted context omitted.
Why not ?
Because I don't want the code I'm running to change out from under me when I tell it to run because some dependency got updated (or for any other reason, for that matter). That's a recipe for disaster. Running the code is a separate step from determining what code I am going to run ; the latter includes determining exactly what versions of all dependencies I am going to run. The two should not be combined.