Earlier quoted context omitted.
Channels are basically the primitive with which you can implement futures, thread-safe queues, etc. Can you elaborate on why you think async/await is easier (for you) to reason about than a goroutine and a channel?
Yes, An async function is explicitly async (in its definition). The syntax is obvious which is why JavaScript chose to go that route (rather than adopt channels at a language level for example). Plus, 95% of the time I care about the singular return value of a function - I just want something that's a function but async - and not a green thread that's using a channel to send information back. Both conceptually and in…
Ditching Go for Node.js
121–130 of 185 posts
Re: Ditching Go for Node.js
#122Re: Ditching Go for Node.js
#123Ryan Dahl, the creator of Node.js: "That said, I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever." Full interview: https://www.mappingthejourney.com/single-post/2017/08/31/epi...
Am I missing something? In the interview Ryan Dahl said that if he were to build a "massively distributed DNS server" he would not chose node. And then again "Node is not the best system to build a massive server web".
But he also said that for less massive projects Node could be the right fit.
Isn't that basically agreeing with the blog post?
I don't see what's your point.
Re: Ditching Go for Node.js
#124Earlier quoted context omitted.
I've found typescript an invaluable tool. Having worked on large backend codebases in both TS and JS, the difference is stark. The TS API in my case had something like 90% less errors, and those were all subtle bugs in business logic. On the other hand, the large JS API over time had all sorts of unexpected type errors and undefined behavior. I'm aware that this is anecdotal evidence, but TS is pretty much a no-brain…
> The TS API in my case had something like 90% less errors That sounds like a red flag to me. I hardly have any type related bugs in my pure JS server code. Must be a poor developer in the team. Too easy to blame JS for that.
I've only used TS on the frontend, but I had the same opinion as you until I dug into a couple of TS projects. I don't know if I've ever caused a JS production bug that was a type error at its core, but I've had plenty of bugs like that in development. TS lets me cut out those little dev cycles where I'll write some code, rebuild the app, then see an obvious error in the JS console when I run the app. That adds up to a lot of wasted time over a week of coding. Smart autocomplete and smart variable renaming is also really nice, and I have way more confidence refactoring a TS project than a JS one. I think using TS does result in fewer production bugs, but the big win for me has been having fewer development bugs.
Re: Ditching Go for Node.js
#125Computers.
Re: Ditching Go for Node.js
#126Earlier quoted context omitted.
I've found typescript an invaluable tool. Having worked on large backend codebases in both TS and JS, the difference is stark. The TS API in my case had something like 90% less errors, and those were all subtle bugs in business logic. On the other hand, the large JS API over time had all sorts of unexpected type errors and undefined behavior. I'm aware that this is anecdotal evidence, but TS is pretty much a no-brain…
> The TS API in my case had something like 90% less errors That sounds like a red flag to me. I hardly have any type related bugs in my pure JS server code. Must be a poor developer in the team. Too easy to blame JS for that.
Tests are also a red flag for the same reason. Just suck less, I always say!
Re: Ditching Go for Node.js
#127> Since go does not have generics or unions my only option right now is to decode message in a base message struct with just the @ JSON field and then based on that try to decode message in a full payload struct.
If he is in control of his protocol, why did he not shape it to suit his parser library? Instead of this:
message1 = { "@": "foo", "foo1": 1, "foo2": 2 }
message2 = { "@": "bar", "bar1": 1, "bar2": 2 }
message1 = { "foo": { "foo1": 1, "foo2": 2 } }
message2 = { "bar": { "bar1": 1, "bar2": 2 } }
type Mesage struct {
Foo *FooMessage
Bar *BarMessage
}
Re: Ditching Go for Node.js
#128Earlier quoted context omitted.
Hopefully, but all he said was "fanout" which could be either. He knows it's implemented wrong, that's the point of the article: that Go doesn't make it easy for him to implement it right. The only question is the degree of wrongness. :)
I don't think this criticism holds water since he opted for JavaScript. If he was having problems with goroutines and channels, he could have picked a Node-like architecture (single-threaded, callback-driven) and still likely enjoyed better performance (and optimization tooling!) than with Node. If his issue was Go's type system, then he shouldn't have chosen a language with a strictly worse type system. In other wor…
In Javascript you have the option to gradual type into Typescript which offers much better static typing than Go. So I wouldn't be too dismissive.
Also, the "just write Node-like code in Go" isn't a solution at all. You're back to fitting a square peg in a round hole.
Re: Ditching Go for Node.js
#129Earlier quoted context omitted.
You're comparing core libraries of Go with non-core libraries of Node.js. Since Go libraries are not versioned without a tool like dep, you're putting trust that master doesn't have breaking changes vs hoping the maintainer follows SemVer correctly. In fact, even the core Go team has problem with this and has to revert changes to things under golang.org/x/ when they break backwards compatibility.
Node's fs library changed within the last 2 years. I copy pasted code and it failed.
Example?
Re: Ditching Go for Node.js
#130> Since go does not have generics or unions my only option right now is to decode message in a base message struct with just the @ JSON field and then based on that try to decode message in a full payload struct. If he is in control of his protocol, why did he not shape it to suit his parser library? Instead of this: message1 = { "@": "foo", "foo1": 1, "foo2": 2 } message2 = { "@": "bar", "bar1": 1, "bar2": 2 } Do th…
I support ports of a Golang library and protocol that did this and I am very tired of having to suffer Go's anemic type system in every other language I work with.
Please stop infecting us with Go-specific type tags (that btw make the protocol versioning story much more complicated) and either demand Go support generics like every other modern statically typed language, or accept your language is ill-equipped for parsing and check if things = nil a lot more.
Don't advocate for pushing your tooling's problems out on your peers.