5 ms·

> I've heard generally good things about TypeScript, but I'd be concerned about its performance even if it is better than Python I wouldn't recommend Typescrip

> I've heard generally good things about TypeScript, but I'd be concerned about its performance even if it is better than Python I wouldn't recommend Typescript for CPU-bound tasks, but for I/O-bound tasks with complicated business logic it's type system is on the order of magnitude better than Go, and makes you able to get really close to the "make invalid states of the system a type error" ideal of functional languages like Haskell, while still being a lot more approachable.

nazka 4y ago
Talking about Haskell and stuff. You what I want? Rescript to replace entirely Typescript. That will be so much better.
- golergka 4y ago
  Personally, I love ML-family languages and would enjoy writing in Rescript more, indeed. But I write software not to enjoy the process, but to solve business needs. And using Rescript, Scheme or Haskell drastically limits the talent pool and rises the cost. Which, BTW, can be very good for some businesses, that would want to hire only the best programmers anyway and are ready to pay for it. But that's some, not all.
  - nazka 4y ago
    Yes I agree. Also if you know your business won't need a lot of dev, like stuff like Instagram where I think they were still at 60 engineers even after hitting 1B active users, it can also be a good thing to use a niche (but viable) language to attract some bright engineers and they will be thrilled to be able to have a job to use it. Now I don't have such startup (yet) so I can't do it :) I just wish ReScript would have gained traction and replaced Typescript. But who knows maybe it can still happen.
- still_grokking 4y ago
  I would endorse that. TypeScripts's type-system soundness holes kill the fun with that language very quickly, imho. That was a really big disappointment for me. A "static" language that compiles fine and than crashes at runtime with complete WTF-bugs is not much better than a dynamic language. You just can't trust the compiler and need to double check every line of code anyway. So there is not much additional value in this kind of "type safety". I would prefer Rescript of Scala.js anytime to TypeScript. Got really disillusioned by TS.
throwaway894345 4y ago
I sort of agree, but I also think type systems are somewhat overrated compared to performance, static compilation, native compilation, easy cross compilation, good tooling, expansive ecosystem (esp devoid of C dependencies). I think TS and Go are on par with respect to tooling and ecosystem, but I would rarely trade Go's static, native compilation model (distributing a single static binary is pretty awesome) for some extra type system features. Specifically, I posit that returns on type system features diminish--there's a ton of value in going from a dynamic type system to Go's pre-generics type system, but every addition thereafter offers decreasing value.
- golergka 4y ago
  > distributing a single static binary is pretty awesome It is, but does it really matter when you write backend? I've written and operated Node-based backends at scale, and I can't honestly remember any bugs or outages that would have been prevented by this. At the other hand, there's a lot of potential bugs and problems that didn't happen because proper usage of TS's type system prevented me from committing them.
  - hu3 4y ago
    > I've written and operated Node-based backends at scale. I'm interested in producing fullstack typesafe web projects using typescript on both backend and frontend. My question is how do you scale nodejs since it is single-threaded? Say I need 10k concurrent connections. These connections doesn't have to be all hammering the system at once but I need to accept 10k connections and perform something like 2k requests/s. How do I approach this? One server with clustered nodejs? pm2? I ask because there are a ton of outdated info on how to scale nodejs. Some rudimentary benchmarking with clustered or pm2 nodejs tells me that 95 response times go from 30ms to 1000ms once I hammer the server. Whereas Go and C# keep it under 100ms without any effort or extra tooling, just using standard library.
  - throwaway894345 4y ago
    I'm not claiming a single static binary is going to prevent bugs or outages. It's just a surprisingly nice property (though less-so on the backend). For example, because Go distributes as a single static binary, we can make scratch images that weigh in at only a couple of megabytes. This (alongside fast compilation) means we can iterate more quickly in the cloud (pulling images onto nodes and starting them is almost instantaneous). This is particularly helpful when you have an outage and you're trying to get things un-stuck (you can try a lot of things in a short amount of time). It's one of those things that aren't obviously valuable until you've tried it. Again, it's not the end-all-be-all, but it's a surprisingly nice property.
xmonkee 4y ago
I am launching my startup on Typescript (backend and frontend). So far, it's been an amazing experience - I can define the problem in terms of types even before I start writing any executable code, and refactoring is a breeze if you make your types hard enough. There are mature libraries, you can share code between the two sides, infinite options for PaaS providers who can "just deploy" a typescript codebase. As a solo dev, it's saving me an incredible amount of time to go to market. I've had experience with large codebases in Python, Java, Go and Javascript before. Python - as everyone already said, just sucks. Refactoring is a nightmare, you have to test every single line of code for any sort of dependability and that makes refactoring even harder. It allows for too much meta-programming and within 3-6 months your codebase is legacy. Java is just not fun to write for me, but Kotlin is kinda fun and I could see myself choosing that. The problem is that my product deals with a lot of deeply nested, user-defined objects, and converting JSON (or YAML, or XML) to POJOs is a verbosity nightmare. I just fucking really hate Go. I can't explain it, but I find the language infuriating. It somehow manages to be less expressive, more verbose and more straight up boring than all the other options.
- throwaway894345 4y ago
  > I just fucking really hate Go. As a Go fanboy, this made me chuckle. :) > I can't explain it, but I find the language infuriating. It somehow manages to be less expressive, more verbose and more straight up boring than all the other options. I sort of get it. I think people fixate too much on the for loops and the `if err != nil` boilerplate, but there's definitely some validity with respect to "how to properly annotate errors" and emulating enums (in the Rust sense of the word) is pretty error prone and it still doesn't get you exhaustive pattern matching. The stuff I like about Go: * Single static, native binaries - being able to just send someone an executable is pretty nice, not needing to make sure people have the right libs and runtime installed is phenomenal. * Great tooling. I love that the Go tool takes a list of dependencies. Unlike Gradle/CMake/etc I don't have to script my own build tool in a crumby/slow imperative DSL. * Compilation speed. Go compiles really fast. * Small language, easy learning curve. Any programmer can read just about any Go project with very little experience. Any Go programmer can jump into any other Go project and be productive immediately (no extensive configuration of IDE or build tools or anything like that). You can also write surprisingly abstract code without reaching for generics, but you will likely have to change your programming habits. * Value types done right. Most other mainstream languages don't have them, and the ones that do very often implement them poorly (e.g., IIRC in C# you can define a type as a struct or a class and only structs can be value types, and classes are more idiomatic). * Go eschews inheritance and prefers data-oriented programming over object-oriented programming (although OOP is poorly defined and some people think it means "anything with dot-method syntax"). * I'm just more productive in Go than any other language Stuff I don't like about Go: * No enums * I wish there were fewer tradeoffs between abstraction and performance * Needs a better system for annotating errors * Doesn't run on embedded systems (although I've heard good things about TinyGo) * Doesn't make me feel as clever (this is a nice property for professional software development, but for hobbies not so much) On balance, I think Go is the better language, but I can also understand why it chafes people. Different strokes. :)

nazka 4y ago

Talking about Haskell and stuff. You what I want? Rescript to replace entirely Typescript. That will be so much better.

golergka 4y ago
Personally, I love ML-family languages and would enjoy writing in Rescript more, indeed. But I write software not to enjoy the process, but to solve business needs. And using Rescript, Scheme or Haskell drastically limits the talent pool and rises the cost. Which, BTW, can be very good for some businesses, that would want to hire only the best programmers anyway and are ready to pay for it. But that's some, not all.
- nazka 4y ago
  Yes I agree. Also if you know your business won't need a lot of dev, like stuff like Instagram where I think they were still at 60 engineers even after hitting 1B active users, it can also be a good thing to use a niche (but viable) language to attract some bright engineers and they will be thrilled to be able to have a job to use it. Now I don't have such startup (yet) so I can't do it :) I just wish ReScript would have gained traction and replaced Typescript. But who knows maybe it can still happen.
still_grokking 4y ago
I would endorse that. TypeScripts's type-system soundness holes kill the fun with that language very quickly, imho. That was a really big disappointment for me. A "static" language that compiles fine and than crashes at runtime with complete WTF-bugs is not much better than a dynamic language. You just can't trust the compiler and need to double check every line of code anyway. So there is not much additional value in this kind of "type safety". I would prefer Rescript of Scala.js anytime to TypeScript. Got really disillusioned by TS.

throwaway894345 4y ago

I sort of agree, but I also think type systems are somewhat overrated compared to performance, static compilation, native compilation, easy cross compilation, good tooling, expansive ecosystem (esp devoid of C dependencies). I think TS and Go are on par with respect to tooling and ecosystem, but I would rarely trade Go's static, native compilation model (distributing a single static binary is pretty awesome) for some extra type system features. Specifically, I posit that returns on type system features diminish--there's a ton of value in going from a dynamic type system to Go's pre-generics type system, but every addition thereafter offers decreasing value.

golergka 4y ago
> distributing a single static binary is pretty awesome It is, but does it really matter when you write backend? I've written and operated Node-based backends at scale, and I can't honestly remember any bugs or outages that would have been prevented by this. At the other hand, there's a lot of potential bugs and problems that didn't happen because proper usage of TS's type system prevented me from committing them.
- hu3 4y ago
  > I've written and operated Node-based backends at scale. I'm interested in producing fullstack typesafe web projects using typescript on both backend and frontend. My question is how do you scale nodejs since it is single-threaded? Say I need 10k concurrent connections. These connections doesn't have to be all hammering the system at once but I need to accept 10k connections and perform something like 2k requests/s. How do I approach this? One server with clustered nodejs? pm2? I ask because there are a ton of outdated info on how to scale nodejs. Some rudimentary benchmarking with clustered or pm2 nodejs tells me that 95 response times go from 30ms to 1000ms once I hammer the server. Whereas Go and C# keep it under 100ms without any effort or extra tooling, just using standard library.
- throwaway894345 4y ago
  I'm not claiming a single static binary is going to prevent bugs or outages. It's just a surprisingly nice property (though less-so on the backend). For example, because Go distributes as a single static binary, we can make scratch images that weigh in at only a couple of megabytes. This (alongside fast compilation) means we can iterate more quickly in the cloud (pulling images onto nodes and starting them is almost instantaneous). This is particularly helpful when you have an outage and you're trying to get things un-stuck (you can try a lot of things in a short amount of time). It's one of those things that aren't obviously valuable until you've tried it. Again, it's not the end-all-be-all, but it's a surprisingly nice property.

xmonkee 4y ago

I am launching my startup on Typescript (backend and frontend). So far, it's been an amazing experience - I can define the problem in terms of types even before I start writing any executable code, and refactoring is a breeze if you make your types hard enough. There are mature libraries, you can share code between the two sides, infinite options for PaaS providers who can "just deploy" a typescript codebase. As a solo dev, it's saving me an incredible amount of time to go to market. I've had experience with large codebases in Python, Java, Go and Javascript before. Python - as everyone already said, just sucks. Refactoring is a nightmare, you have to test every single line of code for any sort of dependability and that makes refactoring even harder. It allows for too much meta-programming and within 3-6 months your codebase is legacy. Java is just not fun to write for me, but Kotlin is kinda fun and I could see myself choosing that. The problem is that my product deals with a lot of deeply nested, user-defined objects, and converting JSON (or YAML, or XML) to POJOs is a verbosity nightmare. I just fucking really hate Go. I can't explain it, but I find the language infuriating. It somehow manages to be less expressive, more verbose and more straight up boring than all the other options.

throwaway894345 4y ago
> I just fucking really hate Go. As a Go fanboy, this made me chuckle. :) > I can't explain it, but I find the language infuriating. It somehow manages to be less expressive, more verbose and more straight up boring than all the other options. I sort of get it. I think people fixate too much on the for loops and the `if err != nil` boilerplate, but there's definitely some validity with respect to "how to properly annotate errors" and emulating enums (in the Rust sense of the word) is pretty error prone and it still doesn't get you exhaustive pattern matching. The stuff I like about Go: * Single static, native binaries - being able to just send someone an executable is pretty nice, not needing to make sure people have the right libs and runtime installed is phenomenal. * Great tooling. I love that the Go tool takes a list of dependencies. Unlike Gradle/CMake/etc I don't have to script my own build tool in a crumby/slow imperative DSL. * Compilation speed. Go compiles really fast. * Small language, easy learning curve. Any programmer can read just about any Go project with very little experience. Any Go programmer can jump into any other Go project and be productive immediately (no extensive configuration of IDE or build tools or anything like that). You can also write surprisingly abstract code without reaching for generics, but you will likely have to change your programming habits. * Value types done right. Most other mainstream languages don't have them, and the ones that do very often implement them poorly (e.g., IIRC in C# you can define a type as a struct or a class and only structs can be value types, and classes are more idiomatic). * Go eschews inheritance and prefers data-oriented programming over object-oriented programming (although OOP is poorly defined and some people think it means "anything with dot-method syntax"). * I'm just more productive in Go than any other language Stuff I don't like about Go: * No enums * I wish there were fewer tradeoffs between abstraction and performance * Needs a better system for annotating errors * Doesn't run on embedded systems (although I've heard good things about TinyGo) * Doesn't make me feel as clever (this is a nice property for professional software development, but for hobbies not so much) On balance, I think Go is the better language, but I can also understand why it chafes people. Different strokes. :)