Hacker News Reader

Comment by vosper | Hacker News Reader

And if you want types then Typescript is a lot nicer than using Python's typing stuff.

I used to love Python's list comprehensions etc, but since JS got .map, .filter, and all the other new things I really don't miss them. My impression of async is that it's much nicer in JS than in Python.

In the new version of my employer's web app we are moving from JS front-end with Python (Flask) backend to using as much Typescript as possible, and only using Python where we need data-sciency / ML libraries. We'll call out to it from our Typecript backend as-needed, but will do as little in Python (and especially in Pandas) as possible.

View on HN

Same - I still like Python for scripting, and Scala is still the language I have most fun coding in, but … JavaScript got decent, and TypeScript got really good. I used to want Python in the browser, but no longer see the need.

TypeScript is just a terrific choice for basically any web SPA. My current company is full stack TS (React/TS/MobX on the web, React Native/TS/MobX on mobile, RESTful Express/TS/Postgres/Redis services), and it’s the most productive, straightforward stack I’ve ever used. Perfectly decent performance too. A single language that is legitimately a great choice for most use cases on the web, mobile and backend, hard to compete with that.

I have a similar language preference. Do you think a RESTful TypeScript backend is more productive than a Scala alternative?

Yeah, I think even when engineers are fully ramped up, a well written TS backend is a bit more productive than a well written Scala one. They’re actually decently similar languages, both are expressive languages with expressive type systems and an OOP/FP mix, but I’d say TS has a bit less boilerplate/overhead, the libraries tend to be simpler to learn/use, and it compiles faster.

The biggest efficiency gains, though, are:

- Much faster training/ramp up time for new devs with TS vs Scala

- You can use the same language on the FE and BE, makes it easier for individual devs to do full stack work

The main downsides of TS vs Scala are:

- Scala is faster and more efficient, performance wise. Have to spend more on TS services to serve the same amount of traffic, and if you have heavy computation that’s parallelizeable, Scala is wayyyyy better at that

- As you get into more niche use cases, you just can’t beat the JVM library ecosystem, there are high quality libraries for EVERYTHING. The Node ecosystem is very good too, but not as good as the JVM ecosystem

- TS/Node stack traces are useless compared to Scala/JVM stack traces

Overall, I’ve got ~7 years of professional Scala experience, love the language, but if I was starting a startup today, I’d go full stack TypeScript.

It appears to be a pretty fantastic time for full-stack development and solo founders.

For me, the context switch between client and server was always difficult using a Scala/TypeScript setup (startup).

As you said, unless you rely on some niche technology only available on the JVM, it‘s probably more productive to go full stack TypeScript. For perf-heavy workloads I would probably pick Rust instead of Scala.

I can't compare to Scala, but unless you know you need an API for a web frontend then I would take a look at tRPC or other "zero API" systems (Blitz is another one, but I'm a little unclear on where they are in their pivot).

It's a little hard to describe how magical it feels to actually use. It completely removes needing to think about an API. You don't think about endpoints, about (de)serialization, about the mechanics of fetching, or how arguments are passed. You just call you functions by name from the front-end. All your types are preserved so that if you change the signature of your backend function Typescript will catch it everywhere on front-end. If you use react-hook-form then you can export the zod validators that you wrote for the backend and import them to the frontend, and now your client-side code is using the exact same validator as your backend does. Change your server side validation and now your client-side form won't compile and you'll know exactly why.

Honestly it feels like the missing link in fullstack dev to me. Typescript brought the types and the compiler, and tRPC makes it feel like your entire back and front-end are one system.

Very interesting, I didn‘t know about tRPC yet. I remember in the early days of ScalaJS there were similar ambitions, but I believe it never really caught on.

I will definitely give it a go, thanks.

I prefer Python over Javascript in almost every way. But python's async is a dumpster fire. It's quite natural in Javascript.

Unfortunately Javascript makes you do almost everything async, no choices. Which makes you think that way. Which is awkward to start with and can lead to a lot of strange corner cases. In python unless you're really trying to squeeze performance out of a system you almost never need async.

It doesn't help that it feels like pythons async ecosystem doesn't really know how it works. There is all sorts of blocking code in python async libraries and no one seems bothered by it.

I guess it could be that they just don't care about this type of thing to begin with and have no idea why they are using async other than they heard "it is faster". Meanwhile I am pulling my hair out trying to squeeze a more reqs/s out of an on premise server.

I want to love async. But it’s a nightmare to debug. To this day I still cannot debug tortoise ORM. I dont understand why I can await so easily in my browsers JS console but not in pdb.

python's async mostly works as long as you're using async-native libraries. if you can await it, it's okay. it only gets disastrous when you have to start mangling callback code into promises.

although i really do love javascript's ability to await synchronous functions without it causing any errors. i'm sure it's less performant, but sometimes i just don't care.

I want to use Python more often but having to care about significant white space is a much bigger downer for me than the async being a "dumpster fire" and I also don't think async in Python is so bad.

I'm saying this as someone who has been programming in many languages since more than 20 years.

What kind of editor do you use for writing code? If you need to "care" about significant white space, it might be that you're simply using the wrong tool for the job. Working with Python since 2.4 (among tens of other languages) I honestly don't remember a single situation where I had to care...

It depends, I like using vim on a remote computer and use IntelliJ locally. It usually breaks when I'm trying to refactor, copying and pasting etc.

I was using Vim for a few years and later switched to Emacs. Both provide commands for handling indentation of lines and blocks of code. You just paste and select/mark a block, then indent or unindent until the first line of the block is aligned with the preceding line in a place where you pasted the code. It's true that you can't auto-indent on paste, though. Still, it never slowed me down noticeably. It's a trade-off, to be sure: you need to align indents manually, but then you don't ever have to deal with things like this:

    if (sth)
        sth1();
        sth2();

Yeah, the thing is, if you do forget to align things, which is a thing if your eyes are not the sharpest, weird things can happen, especially when you are writing scripts as if there's no tomorrow. Those experiments usually end up being written for the node.js runtime because I really, really hate aligning lines when I'm writing one-off scripts.

Well, Python is in general not the greatest language for one-off scripts, so it's not strange to use something else for this use case. I definitely never felt your pain, though. I think I'd have to see you edit a Python file live to understand what makes it problematic for you (for example: what width of an indent do you use? wouldn't increasing the width help you notice misalignment? and if it's about seeing/noticing, can't you make your editor display whitespace?).

In my experience, there's no syntax that would be free of gotchas and pain points - I tend to accept them, and if I'm going to work with a particular syntax more than once, I write a bit Elisp to make working around them as seamless as possible.

I totally have this problem with yaml. I wish vim had a line-these-things-up button, kinda like how % lets you bounce around in parenthesis - something like that for leading-whitespace alignment.

Reply on news.ycombinator.com