And how would you describe your political tendencies? I have a theory that more MLs are gonna be into static typing and more anarchists are gonna be into dynamic typing.
Static typing > dynamic typing, imo. I mostly work with C/C++
I’m an ancom.
It's about choosing the right tool for the job. The job is programming and the tool is rust
Lol, ML forged in the fires of Haskell and spreading the gospel of Rust here.
Actually writing Rust for my job now. It’s nice.
Static is always better than dynamic.
You haven’t felt true pain than trying to debug a 20 year old Perl script to find out that someone accidentally passed in one to many zeros to a function which caused all the arguments to be off by one and the dynamic checker just rolled with it and blew up silently.
I think making dynamic languages so common for web apps is the real sin tbh, so many different types of data to deal with, where casting between different data types often causes unsound states and horrible inconsistencies. I'd go to bat in favor of dynamic typing for writing small scripts for automating simple tasks, but I have no clue how it became the standard for everything.
It's because Python and JS became the big web development languages and both of them use dynamic typing. Though Python tries to do a sort of inferred typing system with PEP standards and now type hinting.
I think in principle, having a loosely typed language is good, but in practice no one really follows the rules well enough. It puts too much trust in the programmer to do type checking themselves.
It would be best if it was static by default, and allowed for dynamic types to exist for handling weird inputs gracefully instead of immediately throwing type errors.
Marxist-Leninist, static typing for the win! You will use Rust, and you will like it, or else...
(Segmentation faults, null pointer dereferences, data races, garbage collector latency spikes)
I use Python and only use type hints in the most complicated parts of the code, which is less than. 10% of the codebase.
Don't really have a firm ideology
I use it everywhere because type hinting allows pylance to infer the type of a return value and let's you use the IDEs autocomplete functions
Sure, but most of the code that is not complex is very straightforward and a lot of it is just using
dictso it's just getting/setting via thefoo['bar']syntax so autocomplete isn't really helpful. Like I said the more complicated parts that have complex objects is where the real benefit isIf you're calling any methods on the values stored in those dicts it's still pretty useful. But if it's all primitive types then it's not going to help.
In our case it's all primitive types since we're mostly dealing with web inputs from Django, and then some Celery tasks for RPC and we use primitive types for the arguments because it's a simple data, complex operation kind of application
It also tells you what type is expected by a function if you set up Pylance right. Which means you're able to just mousehover on a function and see exactly what type it requires for each parameter and what type it returns.
That also lets other functions that use that function infer the return type and continue to offer syntax highlighting and code completion.
If you have an un-hinted return type, then it won't automatically highlight the primitive functions you can use.
It's absolutely not necessary, but it makes reading code so much easier later when everything i need to know it hinted at right there in the function call.
Most of the code that is being written is view classes or form classes for Django, so really there's not a lot of times where we are writing code directly that references those where autocomplete matters. Like, a great deal of our code is in
form_validmethods and you never call those in your code, the framework calls them.Same with Celery, where we have the code for the workers in a separate repository and we are calling
send_taskinstead of having aSignatureto directly callapplyonThat's fair, I'm usually writing a ton of tools and such from scratch and using an API for a very popular GIS software where getting those objects recognized properly saves me tons of headaches debugging because I now know I have a Point Geometry object and not a Point object based on proper type hinting in my utility functions.
Also means if I write some function that required a Point Geometry object and a Layout object to work, I can put it in the docstring and also type hint it so other programmers in the office are able to really quickly tell exactly what they need to provide for the function to work.
It's nice to have in that really rapid development situation for sure, my commits and changes usually have a 10-20 minute turnaround to get things working since everyone in production is using my main branch. I have all the other devs working on forks so they can isolate their code from the central repo that everyone is always referencing for their tools.
When you only have 5 minutes to debug a production tool, having a ton of built in links to the bajillion different methods Arc objects have is necessary.
static rust enthusiast, probably more of an ml type but i don't advocate any specific tendency.
reminder to everyone to not get into actual sectarianism in the comments.
ML. I almost completely write in Julia so my take is going to be a bit wonky/abnormal. For the kinds of stuff I write, having the option to static is great sometimes, but it makes it vastly easier to have the ability to dynamically type. If I had to worry about types more than I do it would probably result in a 33% increase in programming time.
Ancom in favor of static typing. I avoid reassigning variables at all, let alone with an object of a different type.
I'm also mostly in favor of static typing, but I think the major usecase of dynamic typing is having a broad sort of polymorphism, where you're free to think of variables just as what they can or can't do, even if they're immutable. Of course that behavior can still be implemented with statically typed languages with interfaces/traits but it's more work. It's worth noting that it is also much safer, and it helps you iron out your model's inconsistencies, where dynamic typing often hides that you're doing something that fundamentally shouldn't make sense.
ML. Static typing is great but sometimes I want to be more vague especially when I'm dealing with big ass template classes.
autocomes in handy big time. C++. Although if I'm writing in C the decision is basically made for meEver tried Rust? It has a pretty smart type inference engine that actually gives you feedback and in many IDEs you can have it autofill its inferences. Only time it kinda borks up is with iterators which tend to have extremely long type names since there might be multiple layers of generics and specifiers. But you can do something like
let res: Vec<_> = some_iterator.collect()and it figures out what goes in the _ for you.I haven't but Rust is definitely growing in the embedded space. I'll actually have to check it out sometime soon
It's growing everywhere
Hexbear runs on Rust, even, and I've found it pretty fun to peruse the repo and learn some things from it.
Good post. Strongly prefer static typing. Red not black. I like Typescript. Unfortunately I mostly write in Solidity, which has godawful type systems (only got typedefs like a year ago), no real objects, and no polymorphic structs.
ML. Dynamic, though i do use type hints most of the time
(i mostly use gdscript)
