5 ms·

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 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. :)
- AmpsterMan 4y ago
  I am still fairly early in my career. I've worked mostly in Java, but my current job is a mix of Python for E2E testing, PHP and JS for application work. Go is my preferred language for tools. My favorite language is by far Java with Go a close second. I dislike the others. The only thing I wish Go had is more functional support, but only in the style of Java's fluent API. I strongly dislike PHP, JS, and Python functional style and would almost prefer they not exist.
  - zeroc8 4y ago
    I on the other hand like the fact that Go keeps things simple and primitive. Don't need those functional constructs at all, allthough I'm using them quite often in Typescript. But for Go - please no. Go is like C. Adding things just makes it worse.
reitanqild 4y ago
> 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 don't hate it like you, I just find it amazingly backwards, and I think I can explain why: The community has the same persistence as certain teachers when it comes to locking things down and making things harder than necessary for no good reason, all for our own good. Prime example: announcing a supposedly cutting edge language without generics in 2009, launching version 1.0 without it in 2012, 8 years after notoriously conservative Java got it, then waiting until 2022 before listening, that is some hardcore teacher mentality IMO.
- xmonkee 4y ago
  Yeah, honestly I would respect them more if they never added generics. Still wouldn't use it. I haven't tried go-with-generics but I can't imagine it can be a good addition so late in the game.
  - reitanqild 4y ago
    Was absolutely a brilliant addition to Java. I haven't used Go for years but it was sorely lacking last time. Are you sure you aren't suffering from the Stockholm Syndrome?
Xeoncross 4y ago
> I can define the problem in terms of types even before I start writing any executable code This is how code is supposed to be written. Sort out the logic first, don't write the actual implementation details until later (models, http handlers, file parsers). The support for this type of SOLID design is much more common in Go than in Typescript projects which often seem to inherit bad practices from Javascript developers.
blueslurpee 4y ago
We have similar experiences. I absolutely love Typescript. But I don’t like Node very much. So I keep TS in the browser. I’ve been looking at Nim or Scala for the backend. It’s either that, or just dive into Rust. It really seems if you don’t want to use Node, Java, or Go the available choices for a statically typed backend get quite slim.
- deleted 4y ago
  [deleted]
- ithrow 4y ago
  What don't you like about nodejs? seems like a solid choice for most things, the only use one language (nodejs/browser) is very attractive (besides SQL).
- xmonkee 4y ago
  Look at Kotlin if you haven't. Sure, "it's just Java" but really it's not. A good example is the collections all have an astoundingly uniform API and everything can map into everything else. It's really quite enjoyable.
- elcritch 4y ago
  If you like doing compile time things with types like typescript enables then Nim is fantastic. I've been learning Rust recently and I'm continually disappointed with how little compile time or type based stuff you can do.
  - formerly_proven 4y ago
    With prior C++ experience it's easy to equate C++ templates and Rust generics (similar syntax - usually does similar things - quack like ducks etc.); I know I did. And through this lens generics will soon seem very limited compared to templates. But the underlying reason for this is because C++ templates aren't generics - they're much closer semantically to hygienic, declarative macros. C++ templates are based around rules like SFINAE and allowing multiple alternatives and the compiler will work out which is the most-specific match that works. C++ templates (even with concepts) are unconstricted - when you give a template a type, there aren't any checks enforced by the language about the types; many templates have a list of requirements and you, the programmer, have to check them, unless the template itself has guards and checks the types. Through this lens, the semantic equivalent of C++ templates in Rust isn't generics, but macro_rules! - but for most uses of C++ templates you would rather use generics and traits.

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. :)

AmpsterMan 4y ago
I am still fairly early in my career. I've worked mostly in Java, but my current job is a mix of Python for E2E testing, PHP and JS for application work. Go is my preferred language for tools. My favorite language is by far Java with Go a close second. I dislike the others. The only thing I wish Go had is more functional support, but only in the style of Java's fluent API. I strongly dislike PHP, JS, and Python functional style and would almost prefer they not exist.
- zeroc8 4y ago
  I on the other hand like the fact that Go keeps things simple and primitive. Don't need those functional constructs at all, allthough I'm using them quite often in Typescript. But for Go - please no. Go is like C. Adding things just makes it worse.

reitanqild 4y ago

> 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 don't hate it like you, I just find it amazingly backwards, and I think I can explain why: The community has the same persistence as certain teachers when it comes to locking things down and making things harder than necessary for no good reason, all for our own good. Prime example: announcing a supposedly cutting edge language without generics in 2009, launching version 1.0 without it in 2012, 8 years after notoriously conservative Java got it, then waiting until 2022 before listening, that is some hardcore teacher mentality IMO.

xmonkee 4y ago
Yeah, honestly I would respect them more if they never added generics. Still wouldn't use it. I haven't tried go-with-generics but I can't imagine it can be a good addition so late in the game.
- reitanqild 4y ago
  Was absolutely a brilliant addition to Java. I haven't used Go for years but it was sorely lacking last time. Are you sure you aren't suffering from the Stockholm Syndrome?

Xeoncross 4y ago

> I can define the problem in terms of types even before I start writing any executable code This is how code is supposed to be written. Sort out the logic first, don't write the actual implementation details until later (models, http handlers, file parsers). The support for this type of SOLID design is much more common in Go than in Typescript projects which often seem to inherit bad practices from Javascript developers.

blueslurpee 4y ago

We have similar experiences. I absolutely love Typescript. But I don’t like Node very much. So I keep TS in the browser. I’ve been looking at Nim or Scala for the backend. It’s either that, or just dive into Rust. It really seems if you don’t want to use Node, Java, or Go the available choices for a statically typed backend get quite slim.

deleted 4y ago
[deleted]
ithrow 4y ago
What don't you like about nodejs? seems like a solid choice for most things, the only use one language (nodejs/browser) is very attractive (besides SQL).
xmonkee 4y ago
Look at Kotlin if you haven't. Sure, "it's just Java" but really it's not. A good example is the collections all have an astoundingly uniform API and everything can map into everything else. It's really quite enjoyable.
elcritch 4y ago
If you like doing compile time things with types like typescript enables then Nim is fantastic. I've been learning Rust recently and I'm continually disappointed with how little compile time or type based stuff you can do.
- formerly_proven 4y ago
  With prior C++ experience it's easy to equate C++ templates and Rust generics (similar syntax - usually does similar things - quack like ducks etc.); I know I did. And through this lens generics will soon seem very limited compared to templates. But the underlying reason for this is because C++ templates aren't generics - they're much closer semantically to hygienic, declarative macros. C++ templates are based around rules like SFINAE and allowing multiple alternatives and the compiler will work out which is the most-specific match that works. C++ templates (even with concepts) are unconstricted - when you give a template a type, there aren't any checks enforced by the language about the types; many templates have a list of requirements and you, the programmer, have to check them, unless the template itself has guards and checks the types. Through this lens, the semantic equivalent of C++ templates in Rust isn't generics, but macro_rules! - but for most uses of C++ templates you would rather use generics and traits.