3 ms·

> I have Go for the backend now, and using Typescript on the backend feels like a serious disservice to my productivity and happiness Interesting, I feel the o

> I have Go for the backend now, and using Typescript on the backend feels like a serious disservice to my productivity and happiness Interesting, I feel the opposite. To me, Go is cumbersome and missing a lot of the nice APIs that Deno provides. I've switched from Go to Typescript (Node, for now, but considering Deno for better tooling and better APIs) and feel way more productive. But I'm curious about what your experience with Deno itself was, apart from Typescript.

steve_adams_86 3y ago
> I'm curious about what your experience with Deno itself was I'd describe it as mostly good, but not good enough. I prefer it over Node as a server runtime for several reasons (more secure by default is a huge deal, simpler yet better tool chain which "just works", APIs which respect web standards, plugin system is really cool) , and if I had to build a project based around Typescript in a monorepo I'd almost certainly prefer deno over Node. One thing I really liked at first was how easily you can write executable scripts... I didn't expect to like it, but Typescript is very expressive and sane enough that writing a script with it is relatively pleasant. However, the real snag is that you need deno on a machine to run them... I love writing scripts with Go too, and it's arguably much nicer off the shelf, so that plus quickly lost its appeal as well. I prefer portability too much not to stick with bash, or otherwise publish executable binaries. Regardless, it's a cool feature if you're on a team which uses deno; using TS across the stack, even in your scripts (without the gnarly barrier of npm or some other script runner) seems like it could be legitimately capable and productive, but also ergonomic without significant compromise in most cases. > Go is cumbersome and missing a lot of the nice APIs that Deno provides I would have agreed a few years ago, but I know I was personally just "holding it wrong". Go is very powerful and easy to use in the right hands. However, it could only be that I do relatively simple tasks with it, or those the language designers intended. I don't doubt for a second that you had a bad experience with it for legitimate reasons; I only mean that I had a rough time with it because I didn't understand the language deeply enough. Admittedly, I wanted to use Go like I used Typescript. They're much different languages underneath, but sometimes it feels as though you should be able to design things in similar ways. It's typically not the case, though. The type system is far different, and the fact that it supports concurrency so primitively means a lot of its constructs are designed quite differently than intuition might inform you if you're coming from the Node world. Otherwise, they lack overlap in terms of how objects work, Go's lack of prototypical inheritance, and so on. When you put it all together they're far different from each other, and their patterns less fungible, than they seemed to me at a glance. However, I'm not a classically trained computer scientist so I've often been prone to holding languages wrong, so to speak, until error and extensive reading pounded a proper grasp and understanding into my mind. > the nice APIs that Deno provides I'm curious, what are these missing APIs from your perspective?

steve_adams_86 3y ago

> I'm curious about what your experience with Deno itself was I'd describe it as mostly good, but not good enough. I prefer it over Node as a server runtime for several reasons (more secure by default is a huge deal, simpler yet better tool chain which "just works", APIs which respect web standards, plugin system is really cool) , and if I had to build a project based around Typescript in a monorepo I'd almost certainly prefer deno over Node. One thing I really liked at first was how easily you can write executable scripts... I didn't expect to like it, but Typescript is very expressive and sane enough that writing a script with it is relatively pleasant. However, the real snag is that you need deno on a machine to run them... I love writing scripts with Go too, and it's arguably much nicer off the shelf, so that plus quickly lost its appeal as well. I prefer portability too much not to stick with bash, or otherwise publish executable binaries. Regardless, it's a cool feature if you're on a team which uses deno; using TS across the stack, even in your scripts (without the gnarly barrier of npm or some other script runner) seems like it could be legitimately capable and productive, but also ergonomic without significant compromise in most cases. > Go is cumbersome and missing a lot of the nice APIs that Deno provides I would have agreed a few years ago, but I know I was personally just "holding it wrong". Go is very powerful and easy to use in the right hands. However, it could only be that I do relatively simple tasks with it, or those the language designers intended. I don't doubt for a second that you had a bad experience with it for legitimate reasons; I only mean that I had a rough time with it because I didn't understand the language deeply enough. Admittedly, I wanted to use Go like I used Typescript. They're much different languages underneath, but sometimes it feels as though you should be able to design things in similar ways. It's typically not the case, though. The type system is far different, and the fact that it supports concurrency so primitively means a lot of its constructs are designed quite differently than intuition might inform you if you're coming from the Node world. Otherwise, they lack overlap in terms of how objects work, Go's lack of prototypical inheritance, and so on. When you put it all together they're far different from each other, and their patterns less fungible, than they seemed to me at a glance. However, I'm not a classically trained computer scientist so I've often been prone to holding languages wrong, so to speak, until error and extensive reading pounded a proper grasp and understanding into my mind. > the nice APIs that Deno provides I'm curious, what are these missing APIs from your perspective?