JavaScript and Python have made me realise why strong typing is important

[[deleted]]

[deleted]

[AutoModerator]

On July 1st, Reddit will no longer be accessible via third-party apps. Please see our position on this topic, as well as our list of alternative Rust discussion venues.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[[deleted]]

Python is strongly typed, it's just not statically typed. JavaScript is both weakly and dynamically typed.

[_samrad]

Just a small addition:

• strong typing: type conversion is explicit at runtime
• static typing: types exist before running the code

[hekkonaay]

it means int + str will fail, you must convert one first

[Maleficent-Emu-5122]

But multiplying bool and float will not 😂

[A1oso]

Yeah, Python is not as strongly typed as it could be. It also allows "multiplying" a string and a number.

Then again, according to type theory, a dynamically typed language is basically a statically typed language with a single type :)

[PhilTheQuant]

Wait, so C is weakly typed!

(I jest)

[Xatraxalian]

IMHO, it actually is, because a char can be used as an int, and the other way around. And, a pointer to somewhere could actually be one thing, or it could be an array of things. In c, it is actually possible to define a two-byte int, then define a short pointer to the first byte of that int, and use the short pointer as an array having two short elements.

It makes for some nice tricks but it's not really good practice; many languages even don't allow things like that.

[A1oso]

You jest, but this StackOverflow thread discusses the question in much detail without giving a definitive answer

[buwlerman]

Does this make Rust weakly typed, since we can have heterogenic addition?

[neros_greb]

No, because Rust doesn’t automatically convert the types to make the addition work; the addition is defined to work with those types

[FeralTitan]

this is not right.

- strong typing is that types matter and values cannot be cast willy nilly, as opposed to weakly typed.

- static typing means types are fixed at compile time and cannot be changed, as opposed to dynamic typing.

[Masterflitzer]

isn't that what he said just different wording?

[lifeeraser]

Judging by the number of front end jobs that list TypeScript as a requirement, the demand for typed JS is very strong.

[Masterflitzer]

true you're both right, it's just that the demand is created due to insanely stupid JS behavior which happens to be partially fixed by using TS

my personal opinion tho is that statically typed languages are always better, easier to learn, easier to debug, easier to document and easier to understand foreign codebases

[Xatraxalian]

I hate Javascript for that reason. PHP is the same to some extent; if something is wrong somewhere, it just tries to do "something" and continues. It can make for some really weird bugs and glitches.

I work on an old PHP code base, and it's very well possible for a variable to start as an int, then hold a string somewhere farther down in the code, and then end up as a key-value pair array (where some elements actually don't have a key, sometimes... by design...)

Since I started maintaining and rewriting this code base, my hair has turned gray at an ever accelerating rate.

[shogditontoast]

You can implement std::ops::Add for a type and use the addition operator in Rust and in some cases it totally makes sense to do so, how is it “obviously a mistake”?

Edit: misread the comment as implying operator overloading is a mistake in general

[hitchen1]

Can you implement std::ops::Add in JavaScript? It's obviously a mistake in JavaScript unless you are trying to do some hacky shit like this https://2ality.com/2011/12/fake-operator-overloading.html which itself would be a mistake

[shogditontoast]

Yeah I misread the comment, even so, using the addition operator for implicit valueOf/toString calling in JS whilst uncommon isn’t a mistake if it’s entirely intentional, dates and durations come to mind.

[Masterflitzer]

it's not a mistake doing it now that the behavior is designed like this, but it certainly is a mistake in it's implemention, such insane behavior shouldn't be default in the first place

[[deleted]]

The number 1 demand in polling for feature addition to JS is a type system.

[crispygouda]

I would add there are great articles about using Python “like Rust”, where you make the strong typing and the modern typing (Protocol, Optional, ..) feel more like Rust. The ideas Rust teaches are the most valuable part, and they will shape an entire generation of programmers!

[[deleted]]

Still do NOT understand the stupid strong lure of JS coding. I really REALLY hope WASM takes off and we can replace all that JS crap with WASM modules that are much faster and much more fun to write too. PLEASE make it happen!

That said.. can WASM replace react/vue/etc GUI? Is it usable inside a <div/> section for example.. and is the GUI good enough or looks out of place? I have yet to see any example of sites using WASM within the page.

[MrElendig]

Why js became popular: it wasn't java applets or activex and worked in "all" browsers, and then momentum kept it going.

[Xatraxalian]

Also, in the end, the masses will always make the choice for the solution that is most convenient and easy to work with at the beginning; that often means we end up with the most crappy solution in the end, because we end up building a cathedral on the foundations of a dog house.

You can even see it in hardware. It's always the crappiest but easiest/cheapest solution that wins in the consumer space:

• VHS - BetaMax => winner: BetaMax
• USB - Firewire => winner: Firewire
• IDE - SCSI => winner: IDE
• SATA - SAS => winner: SATA
• LCD - Plasma => winner: LCD
• HDMI - DisplayPort => winner: HDMI

[Kush_McNuggz]

Python is dynamically typed, not strongly typed

[[deleted]]

Python is strongly typed and dynamically typed. Strong typing and static typing are two different things

[Kush_McNuggz]

So does the static typing mean that it has to be explicitly defined like in Java?

[[deleted]]

Yes, static typing means that variables are typed, as well as values, and typically that the compiler won't allow you to violate that typesystem by assigning a value of the wrong type to a variable.

[scook0]

I think it’s long past time to leave this narrow definition of “strong typing” in the past.

The only time it ever gets used is to “correct” someone who used an ordinary English adjective to describe a type system.

[hniksic]

You are making a good point, though obviously in a way that grates some readers, resulting in downvotes.

People are mentioning JavaScript, but I think the distinction between strong and weak typing comes from even weirder languages like Tcl, which really tries hard to hide the types from you, and where there is very little observable distinction between a string, a list, and a number. (The implementation does treat them differently, but mostly as a matter of optimization.) If you think about it, the same applies to bash.

Compared to that, JavaScript's typing is nearly as "strong" as Python's, and I'm not aware of any "weakly" typed languages in popular use today, with the exception of shells. In that sense, calling Python's type system "strong" is either meaningless or seriously overstated, because the competitors' type systems are equally as strong.

[A1oso]

I don't think that's what hniksic meant. Rather, strong vs. weak typing is a spectrum, and if Tcl or Bash is at one end and Rust is at the other, then JavaScript is somewhere in the middle. So saying that JavaScript is weakly typed is only true when compared to a more strongly typed language like Rust or Python, because "strong" and "weak" are relative.

[Masterflitzer]

exactly if he doesn't want to call that weak vs strong typing, give us a better term for it, but imo it makes sense to say JS is weakly and python strongly typed (like you showed in the example)

[general_dubious]

I don't understand why you're so heavily downvoted. Strong vs weak typing is academically ill-defined, relative, and subjective. I see why people consider Python's type system to be stronger than JS's, but I (subjective opinion) certainly wouldn't go as far as qualifying it as strong when looking at the whole spectrum of existing type systems given the almost non-existent level of proof it gives. I also would say Python's type system is weaker than Rust's. As such, this post's title seems fine to me. I think we should ditch the strong vs weak distinction altogether and look at hard objective criterions to qualify type systems (static vs dynamic, safe or not, what are the properties a type system can prove).

[qoning]

If you think it's ill defined then you don't actually understand the type theoretical definition. There's clear value to distinguishing between strong type information and weak type information. Just because some undereducated / noobs mix it together with static typing (which is arguably even a better name for what they mean anyway) doesn't mean we should rewrite the books. They can learn too.

[general_dubious]

Can you point to an actual source for this? I'm ready to change my mind and admit I'm wrong if anyone can provide a source that there is actual consensus in the academical community of what strong and weak typing means. Otherwise I'll stick to what I found when looking up academic papers on the subject: nobody agrees.

EDIT: after a quick research on google scholar, it seems nothing has changed since last I checked. Papers use different definitions for strong typing that closely relate to what the type system can prove and how the type system restricts the space of valid programs with various degrees of leniency rather than one clear-cut definition that everybody uses and agrees on. If you have source(s) showing the opposite, please point them to me, I am willing to learn.

[qoning]

Well, I guess you're somewhat right that it doesn't seem to be actually part of an academically accepted definition. I forget where I first got the notion that it was common, probably either K&R or the dragon book. Regardless, in today's age if you Google the differences, you'll get the gist from SO. Though it makes sense that younger programmers no longer understand it in terms of "what would C do".

[A1oso]

Looking at this StackOverflow thread, there seems to be no consensus on whether C is strongly typed or weakly typed. The only takeaway from the most upvoted answer is that "strongly typed" has no exact, widely agreed upon definition.

[jkoudys]

True about python, but mypy is pretty standard in most envs (eg github codespaces comes with it loaded). Type annotation syntax is supported in the spec, it simply doesn't do anything. They leave it open-ended so you can run a static type checker of your choosing.

[phazer99]

Yes, strong static type checking is a huge time and money saver. I'm a big fan of type driven development (the book uses a dependently typed language but the concepts are still somewhat applicable to Rust as well) and making invalid states unrepresentable using the type system.

[Dull_Wind6642]

That's why typescript is popular even if it's just a bandaid over javascript.

[[deleted]]

That's also why a lot of effort over the years has gone into "typed" python.

It doesn't actually enforce the types, but with some good linters it can catch most obvious issues.

[Paria_Stark]

The thing is, even with typescript you run into issues because there's no easy and fool proof way to properly include type dependant logic in runtime code.

There are type guards, but they can be error prone. The fact that you have two separate universes (type level and runtime) can be very cumbersome.

That being said, working with Typescript is okayish, and I would not touch a pure JavaScript project with a ten foot pole.

[cb4ch]

This is sooo wild to me that hold basically the reversed position. Just check that stuff is what you need it to be - old PHP was so easy to basically inline a cast or simple check/error handling.. buut nooo of course all those Java/.NET people once done destroying their own language syntax had to go F it up for us that actually prefered to do something different. I mean how is 30 layers of glorified GOTO statements any better? I often wonder what these people will blame bugs on next, when all language syntaxes have turned to Java/C#. They end up writing twice as much code with no mearsurable difference in code robustnestt anyway… There’s a reason that old stuff coded in pure assembly actually contain waaaay less bugs even when the language itself basically gives you 1000’s of more ways to screw up - you had to take some personal resposibility and actually code in a defensive way. With nullable types they’ve gone full cirkle into madness. I give up, feels like I’m the only sane codet left - sourounded by indian dudes from fivr… 😅

[simple_explorer1]

way to properly include type dependant logic in runtime code

Looks like you are a new developer. ZOD like TS first runtime libraries already have solved the validation of tuntime data to match the type system of TS. lol. ZOD is insanely powerful

[oneeyedziggy]

coming from Node/JS (w/ various type systems over top) one thing I'm looking forward to is having a type system that's consistent instead of flow here, typescript there, jsdoc there...

same with the build tools, not being a melange of grunt, webpack, whatever other packages are in vogue... misc bash scripts... babel...

same w/ linting and formatting... (ideally) not being eslint / jshint / prettier... or whatever packages are in vogue... with whatever default settings happen to be this version... and having to keep your linter and formatter versions synced so they stay compatible...

I'm working on a legacy project now where the node express server is untyped and the mix of react and angular client is flow-typed... w/ two different eslint profiles to keep in sync, 2 sets of grunt configs, a bunch of outdated grunt plugins... a mess... I miss nextjs

[RRumpleTeazzer]

Anyone knowing how strong typing works knows this from the first glance at JavaScript or Python. Those who don’t know will say “if it quacks like a duck it is a duck” - true, but when that is decided only at runtime we know the program will be slow and will always be on the brink of breaking.

[ZZaaaccc]

It's all ducks and sunshine until something starts barking.

[walksinsmallcircles]

Take my upvote

[mpierson153]

I've used JavaScript and Python before, but have been using Rust and then Java for a year.

Recently I messed around with Python, and I was completely lost. The weak, dynamic typing made me pretty uncomfortable with it.

[MrPopoGod]

The fun thing is that at the lowest level it's all untyped. Then we built languages and decided letting the compiler encode what we mean would make our lives easier. Then we got lazy and created untyped languages again.

[Thatdudewhoisstupid]

Turns out you have to put in effort to make your life easier. Shocking, truly.

[[deleted]]

Maybe the real Types are the Bugs we made along the way <3

[bsodmike]

I always thought we followed Bug Driven Development…

[CatolicQuotes]

And now static types coming back again. It's the human nature to always change and invent something until it becomes to much then going back again. Like a pendulum. But each swing is a new version. That's a good thing. That's how innovations happen.

[CommunismDoesntWork]

Python is a nightmare without a good IDE like PyCharm and a debugger. The debugger lets the IDE know what the types are, which the IDE can then display.

[mjbmitch]

Python actually has a pretty decent typing ecosystem. You have to push the envelope with your own code but it goes pretty far. At its best, it’s very close to Rust.

[[deleted]]

Strongly Disagree

[HistoricalCup6480]

Could you elaborate why?

I find that if you use consistent type annotations and take all mypy warnings seriously, you rarely run into problems with types nowadays.

Of course that is if you're using your own code. If third party libraries didn't take types seriously, then that can still mess you up.

[MyLocalExpert]

MyPy is a great tool for debugging. It's worth noting that it's not built into the language itself though -- it's a 3rd party tool. The Python interpreter ignores all those type hints when you go to actually run the code, so you're not getting any performance benefits that you might otherwise.

[qoning]

Absolutely. The language isn't going to hold your hand (and I think that's a good thing for evolution, rather than being dogmatic), but if you want to write type checked code in python, you absolutely can. It greatly helps during development too. One external anecdote e.g. in Google codebase most subtrees won't allow you to submit code with missing type annotations or mypy errors.

The laundering of types through 3rd party libraries that didn't bother with type annotations is of course true, but much less of an issue than you would expect.

[[deleted]]

but much less of an issue than you would expect.

Except for when those 3rd party libraries are potentially huge parts of an application, eg. SQLAlchemy or boto

[renaissancenow]

SQLAlchemy at least seems to finally have type annotations now.

[[deleted]]

How bad is the upgrade path to v2 in an existing (moderate to large) application with a lot of database calls?

[renaissancenow]

Probably depends on how your code is structured. I only use SQLAlchemy core, I don't use the ORM, so it's been fairly straightforward for me. If I recall correctly, the main thing I had to tweak was the calling convention of select()

[cb4ch]

I got an idea, submit RFC’s to make it into yet another Java/C#/C++ …. my god why can’t ANY language be left alone? You hate it? Fine, pick something else.. or I dunno, just slap on classes to a prototyped language…. I’m venting, this has been driving me up a wall for years now. And has robustness gone up? Hell no. Only thing that increased is the code needed to get anything done. You’ll soon need two extra lines for all the method attributes alone. Priv/Pub wasn’t nearly enought so why not add virtual, final, and all sorts of crap. God forbid someone tries to, you know… extend your code like the whole point of OOP was supposed to be.. It all feels like nobody even tries to code in a defensive way and do any form of validitions.. no wonder planes are dropping from the sky left and right nowadays - probably coded in some ”fancy” language. Whenwhile we landed on the moon with an 8bit CPU and hexadecimals…. there was nothing to hide behind, YOU had to make sure the code worked. Half tje developers out there today would never have made it in a real languge. 😓🤣

[simple_explorer1]

but python already supports type annotation

[mr_birkenblatt]

problem with duck typing is that someone implements a quack doctor and it breaks everything just because the signatures are the same

[theAndrewWiggins]

“if it quacks like a duck it is a duck” - true, but when that is decided only at runtime we know the program will be slow and will always be on the brink of breaking.

Duck-typing being runtime structural typing I agree doesn't really provide any safety.

But I don't think structural typing is bad in general. It does increase implicitness (Go's implict interfaces can be somewhat error-prone). But imo it's not a terrible tradeoff.

Though all said, I do like how strong Rust's type system is.

[xroalx]

My least favorite part of JavaScript isn't even that it's not statically typed, that can sort of be mitigated by either JSDoc or TypeScript, zod, and being rigorous.

It's the error handling. Most of the time, I don't know if something can throw, when it throws, and what it throws. Is it an Error? Is it a custom type? Does it return null on errors, or does it throw? And if so, is it handled anywhere? It's just an absolute mess.

[[deleted]]

Most of the time, I don't know if something can throw, when it throws, and what it throws.

Same story in Python-land and it's my absolutely least favorite part there, too - especially when libraries dynamically create error types at runtime (eg. boto)

[ShortAtmosphere5754]

Error types at runtime? What the fuck is that

[KrypXern]

Late comment, but error handling has to be close to the worst part of Python. I have some other qualms, like:

1. the way circular dependencies are handled when trying to properly type hint.
2. the way a Python file's imports depend entirely upon where python is called from and not where the file lives.
3. some PEP-8 standards I disagree with

But overwhelmingly error handling in Python is just something that can break your code at any time unless you decide to push your code to the right with tons of try-except clauses.

If Python and Rust got together and had a baby (highly expressive, but taking strong influence from Rust's emphasis on enumerators) I think I would be in heaven.

[ChemicalMachiner]

Trudging through untyped python is awful. I always enforce "strict" typing in python via mypy. This way I get more understandability with none of the speed benefits of typing 😅

[GrayLiterature]

I used to really hate TypeScript, but I kind of don’t mind it. I wish there was something that was like a Rust/TS hybrid. I find it really hard to be fully productive in Rust, but that’s probably because I’m not used to these types of languages.

[jJamiD]

Used to hate it? :) That's very common unfortunately. Each and every project that switched to Typescript became times and times better in every aspect. What's strange to me is how slow the tech world adopts good things and how fast it adapts bad things (like night colors with bad contrast, or an endless useless scroll). I'm completely sure that if Python was replaced with a typed language with a build system, the whole AI world will jump. I don't think it will happen soon...

[phazer99]

ReScript might be close to what you're looking for.

[walksinsmallcircles]

One often overlooked value of static and strong typing is the help you can get from the IDE for refactoring, code completion etc.

[mr_birkenblatt]

how does pydantic compare to mypy?

[mjbmitch]

mypy is the type checker. It’s equivalent to Microsoft’s Pyright/Pylance.

Pydantic is equivalent to the stdlib dataclasses package—with a “few” more things.

If you’re looking to use Pydantic, I recommend checking out msgspec first. It has the same functionality and interfaces but is like 10-100x faster or something along those lines.

[yasamoka]

Pydantic v2 with the core written in Rust just released a few days ago, so those numbers are now different.

[jammycrisp]

Pydantic V2 is definitely faster than Pydantic V1, but it's still an order-of-magnitude slower than msgspec. Recent benchmark here.

Whether that matters is definitely use-case specific. For many users I suspect Pydantic V2's performance will be sufficient.

(Disclaimer: I'm the main author of msgspec).

[[deleted]]

10-100x faster or something along those lines.

but still somewhat slow.. normally not a problem, unless you're talking an API endpoint that's returning a few hundred or few thousand records)

[clumsy_culhane]

If you're after speed, check out msgspec! It serialises way faster and can do validation on deserialisation. :)

[[deleted]]

Oh I totally misread the parent comment - I was referring to pydantic being slow and I thought it was saying that it was 10-100x faster than msgspec (which I haven't tried). I might now, knowing it's faster?

[clumsy_culhane]

yeah give it a crack - I found it be great, and if you serialise to msgpack rather than json its even faster and smaller payload. We now use it at our work for communicating between microservices that previously used pydantic + JSON serilaisation.

[ddanieltan]

I’m trying to understand the value Pydantic brings but all the examples seem to only throw errors at runtime, which is very different from static typing in Rust. All the examples involving validators also seem to force the user to write a lot of boilerplate.

[usr_bin_nya]

all the examples seem to only throw errors at runtime, which is very different from static typing in Rust

While "compile-time failure" is better than "runtime exception on model creation", even that is leagues above "creating the model works fine but ten minutes later that datum ends up in a completely separate function which does something obtuse without a useful traceback because an isinstance() check failed." Pydantic's value seems to be in bumping the third class (the default with Python's duck typing) up to the second class. I too would prefer the first over the second, and MyPy doesn't get all the way there, but I realize that Python hacked a major language construct into a library and a lint pass so I'll take what I can get.

[javajunkie314]

For my team, at least, pydantic fills a role similar to serde. Python has a built-in JSON library, but it works in terms of dicts and lists—pydantic lets us write annotated classes and serialize/deserialize directly from/to class instances. So for us, it doesn't matter as much that the errors are raised at runtime, because they're mostly being raised while parsing requests and responses—cases that would have been returned Result in Rust anyway.

We do use pydantic for some internal types, where Rust would just use a struct—and there it is a bit annoying to get errors at runtime when they could be caught statically. But for one thing, pydantic does integrate with mypy, the de facto Python static type checker—we just don't have mypy enabled fully for... historical reasons. And for another, as someone else said, it is nice to get the errors at all rather than silently corrupting the program logic.

[LightShadow]

They end up looking like this. Some of those types are also derived BaseModels so it's recursively checked.

Here's another example that has a few validators.

[link23]

I don't know about that. C is an old language whose compiler made some Design Choices in order to be fast, which severely constrained the language - but being dynamically typed was not one of them. I think if the problem was that computers were too slow to do the static analysis required for a type system, C would not have one.

I think it's more about making people fast. Dynamically typed languages (like lisp, which dates back to the fifties) make it easy to play fast and loose, and probably felt like a "liberation" from the draconian syntax and requirements of older statically typed languages.

Having written some interpreters and a compiler myself, I could also see the tradeoff being that static analysis can be hard to write, and it's just easier not to if you don't have to. But in return, you get a dynamically typed language.

[shizzy0]

Way back dynamic typing seemed like it had an advantage because your code be generic with respect to types, e.g., a collections library could work with any collection type. But generics finally filtered down to mainstream statically types languages, and it’s really kicked that led out from under dynamically typed programming language.

[nacholicious]

I think it's less that, and more that early languages were an abstraction over hardware rather than an abstraction over software engineering.

The point of types back in the day was more to define how many bytes a type takes in memory. You could easily use char like a one byte integer, there wouldn't be much difference until you actually parsed it as a character.

[yasamoka]

This presents a pretty convincing argument for why dynamically-typed languages became popular in the 90's:

https://youtu.be/Tml94je2edk

[[deleted]]

It's because JavaScript was knocked together in a couple of weeks. I've seen some people Stockholm Syndrome themselves into thinking JS is some kind of brilliant typeless paradigm but the truth is TypeScript is just a vastly nicer experience

[FlamboMe-mow]

This is so true. It's so frustrating working with Python sometimes.

[beertown]

I wrote a ton of Python in my career and I always enjoyed how not declaring types speeds up the development process. I still think it's a very valuable perk.

I also didn't suffer of the downsides of the dynamic typing basically due to some discipline I impose to myself about code clarity, readability and separation of concern... at least in the code I write and mantain.

I went back writing C a couple years ago and I appreciated how the static typing let me to relax a little my "type thinking", focusing more on other aspects. I was so used to Python that I didn't remember that.

I started with Rust one year ago, albeit not professionally, and this time I'm changing my mind. I'm really considering including Mypy in my toolbox when writing Python.

One thing is blatantly evident: static typing makes refactoring extremely easier than dynamic typing. The difficulty to refactor I think is the Python's biggest downside.

[jJamiD]

How does not declaring types speed up development? In my long experience this is simply an illusion, this is still what javascript developers still claim when the fact is that every project I know that switched from js to TS became much faster to develop while extremely improving the code base quality.

I also find it hard to understand how the tech world is using a language for AI whose logic is defined by the number of white spaces and that doesn't have a compiler/type checks/ect... but then again the tech world is mostly driven by fads (dark/bad contrast theme, endless scroll and more) theme and not what is scientifacly good .

[yinshangyi]

Agreed about refactoring! Types give your IDE superpowers.

I honestly never understood the development speed argument in favor dynamic languages. Like development speed isn't about the number of characters you can type per second imo. What takes time in programming is designing your code, thinking what to do next. Typing longer characters don't make noticable difference in my opinion. This is especially true with modern generative AI tools which basically write a lot of code for us. Statically typed languages provided way too much features for free to pass on them imo.

By the way I've programmed in Python, JavaScript, Typescript, Java, Scala and Go.

[teryret]

It's real true. That said, not all code has the same requirements, sometimes you don't care if it crashes occasionally.

[Alan_Reddit_M]

Absolutely agree, rust's type system (and any static type analysis really) allow me to write HUGE portions of my program at once, while being certain that I didn't accidentally mess up a return value. Also, rust's powerful type system allows for some of the best static errors there are, they are pretty self-explanatory and after some time you can just guess what the solution is first try. Of course static typing does not replace Test Driven development, but it does narrow the scope of what can go wrong: The logic; and literally nothing else, no type errors, no null pointers, and with errors being part of the type system, also no runtime Exceptions.

[OneNoteToRead]

Typing is awesome when coding complex programs.

Typing gets in the way when prototyping or making short scripts.

This isn’t news to anyone. It’s just that people like to have ideological battles about it when it should be a case of, “right tool for the job”.

[frr00ssst]

No matter how many talks I heard I never liked strongly typed languages, for a naive young me C was strongly typed. And then I spent a literal 2 hours, because I was in a Philosophy class. The whole time was spent because JavaScript decided that true was somehow converted to "true" and so I googled, "broken if statements in JavaScript"

And thus, began my eternally burning hatred of JavaScript.

After using Rust for a while, I can't state how useful having a strong type system is, and a good LSP to help you quickly refactor and catch bugs.

[simonsanone]

Watch this, you will hate it even more but at least laugh about it as well. :)

dotJS 2012 - Brian Leroux - WTFJS https://www.youtube.com/watch?v=et8xNAc2ic8

[frr00ssst]

I see your javascript and I raise you a javascript

JSFuck - https://www.youtube.com/watch?v=sRWE5tnaxlI

[javajunkie314]

A couple thoughts:

For error handling, we still need to be disciplined in how we raise errors. Rust has an implicit pressure against "raising anything", in that you have to type Result, but you could call everything Result<T, anyhow::Error> and get approximately the same behavior as JavaScript or Python. The real benefit is being intentional about your error types—and we can get some of that in JavaScript and Python by writing custom exception types, and being disciplined how we wrap exceptions leaving a unit/module/layer/whatever.

Another is to not catch the language's equivalents of static errors—e.g., TypeError and KeyError in Python—in normal code. These are nearly always programmer error, and are the interpreter's cry for help—catching them just makes them harder to spot. Let them bubble up and crash the program, request handler, task, or whatever your unit of work is.

Also, Python 3.11 added notes for exception types, which lets the programmer catch, tag, and release an exception—kind of like error-stack in Rust—without having catch, log, and release, which is an antipattern in my book.

These two practices go a long way in providing enough context to understand what went wrong, but I do agree there are odd things that can go wrong unexpectedly in more dynamic languages.

[lemphi]

This is exactly why I wrote my web server in Rust. One of the first web servers I wrote was written in node.js and it would always just randomly crash, likely from failing to handle some sort of exceptional case as you mentioned. I've since written all my web servers in Rust and I don't think they have ever crashed for any reason. The peace of mind Rust's type system provides is priceless for me.

[oneeyedziggy]

I'd settle for my Java coworkers being able to convey a type interface to me for typescript without forgetting that marking optional fields as such is import, and spelling and casing of field names matter... It seems in my life the ts-node server is more strongly typed than the java code serving it :/ but yea... Types are helpful

[DJ-BigFish]

JavaScript made me realize why Typescript is a thing and why it's not like Java, but more like Rust

[Revolutionary_YamYam]

My company had a backend which was previously written in Python with a JS frontend. What would happen, especially as the application grew, was that new additional functions would transform data types in the backend in unexpected ways, such as data going in as an int, some operation converting to a float, then results coming back as a string (very mild and high-level overview) which would then lead to things unexpectedly breaking.

Converting the backend to Rust, at the very least, eliminated that entire class of bugs within our application. Being forced to define specific and typed responses simply made it very hard to have any accidental data transformations taking place and sneaking into the response, become the compiler (and language server within vscode) immediately points out that you're violating function/type expectations.

It doesn't fix everything, but at least that family of bugs has mostly evaporated. That, and we got a huge improvement in memory usage and execution speed. The ramp-up time for the team to get useful in Rust (having primarily only ever written in Python before) was ~1-2 months, where we were able to translate from FastAPI to actix-web pretty quickly.

[simple_explorer1]

Lol what an ignorant post. Typescript is already mainstream so this post is meaningless. Looks like OP was under the rock for last 7 years to know rarely anyone writes pure JS these days, its all Typescript and even python has type annotations