Overall I agree with what the author says, though I have a few further thoughts:
One might argue that writing types are time consuming, and the bugs are not an issue when programmer can cover those cases with automated tests.
These two arguments contradict each other and together are an argument for static typing, not against. Which just shows how weak these arguments are.
but a more powerful type of inference that can actually infer the whole type of a function by analyzing the body of the function.
This bit I am not convinced by. Inferring the API of a function from its body makes it harder to see breaking changes when you refactor the body. It can be useful for internal private helpers, but IMO public APIs should be explicit about their signature.
Functional Programming
I would go one step further here. It should support OOP and procedural paradigms as well. No single programming paradigm is best suited to all problems. Sometimes a mixed approach is best. Any language that heavily leans oneway at the expense of the others limits itself to the problems it can best solve. I do admit the far too many languages lean too much towards OOP at the expense of functional style.
So it is easy to push for a functional style over OOP in new languages. But I would be weary of purely functional language as well.
I don’t understand how types could be time consuming.
Some things are very easy to do in loosly typed languages - just as letting a function take a string or int, and then parsing that string into an int if a string was passed in. In a loosly typed language you can just call something like if typeof(input) but in a strongly typed language you often need a lot more boiler plate and extra wrapper types to say the function can only take an int or string - for instance in rust you might need to wrap them in a enum first or some how create a trait and implement that for each types.
This is quite a bit of extra upfront cost some of the time that really rubs people that are used to loosly typed languages the wrong way. So they think it is slow to work with types. But what they never seem to count is the countless hours you save knowing that when you read a value from something and pass it to a function that wants only an int, that the value is an int and you dont end up getting 2 + "2" = "22" and other suprising bugs in your program. Which results in less time debugging and writing tests for weird cases the compiler does not allow.
But all that extra time if often not counted as that is dissociated from the original problem at hand. And they are already used to this cost - people often notice a new cost, but don't notice a possibly bigger saving else where.
I never understood this argument. If your function is supposed to take an int, then parse your string before calling it?
There are reasons you might want to, such as you are constructing something that has a few different ways to create it. Like maybe a date, can parse it from a string, pass in each bit as a separate argument, take in a Unix timestamp.
A lot of languages encourage this with constructors as you can often only have one.
IMO it is far better to just have different functions for each type you want to build something from like how it is done in rust.
But when you come from a language that encourages the opposite it can seem clunky to have to define separate functions for each. And it can take a while to accept the different way of working.
I agree, but I imagine dynamic type fans would say they don't understand why explicitly stating types can be helpful.
Optional typing is pretty useful, especially if the tooling is such that it catches most issues. I use Python's optional typing quite a bit, and my general approach is to add types if the function is intended to be reused or if it took more than three seconds to figure out what it does. We also use Typescript, and typing isn't necessary there either.
If your type system is too strict, it can be really annoying to work with and make simple things take longer. If it's too loose, you'll introduce stupid bugs.
If your type system is too strict, it can be really annoying to work with and make simple things take longer.
Swift has entered the chat.
Yeah I think it’s a misunderstanding. There’s no way they aren’t encountering issues from dynamic types.
It can be nice not to have to worry about types when you are doing exploratory programming. For example, I once started by writing a function that did a computation and then returned another function constructed from the result of that computation, and then realized that I'd actually like to attach some metadata to that function. In Python, that is super-easy: you just add a new attribute to the object and you're done. At some point I wanted to tag it with an attribute that was itself a function, and that was easy as well. Eventually I got to the point where I was tagging it with a zillion functions and realized that I was being silly and replaced it with a proper class with methods. If I'd known in advance that this is where I was going to end up then I would have started with the class, but it was only after messing around that I got a solid notion of what the shape of the thing I was constructing should be, and it helped that I was able to mess around with things in arbitrary ways until I figured out what I really wanted without the language getting in my way at intermediate points.
Just to be clear, I am not saying that this is the only or best way to program, just that there are situations where having this level of flexibility available in the language can be incredibly freeing.
And don't get me wrong, I also love types for two reasons. First, because they let you create a machine-checked specification of what your code is doing, and the more powerful the type system, the better you can do at capturing important invariants in the types. Second, because powerful type systems enable their own kind of exploratory programming where instead of experimenting with code until it does what you want you instead experiment with the types until they express how you want your program to behave, after which writing the implementation is often very straightforward because it is so heavily constrained by the types (and the compiler will tell you when you screwed up).
From some of my own conversations with people they don't find it useful as a solo dev because they have to read the docs for dependencies even with types, and they only ever have to deal with their own code which they know we'll enough that they see types as a waste of time.
These two arguments contradict each other and together are an argument for static typing, not against. Which just shows how weak these arguments are.
The way I read it, he wasn't suggesting that was a good argument at all. He was just explaining what he believes dynamic type enthusiasts say.
This bit I am not convinced by. Inferring the API of a function from its body makes it harder to see breaking changes when you refactor the body. It can be useful for internal private helpers, but IMO public APIs should be explicit about their signature.
Well, in F# at least, this inference is the default. However, anybody can still fully type out the function signature. I think I get what you are saying, but in the case of a public API or interfaces the programmer can simply just add the type specifications.
I would go one step further here. It should support OOP and procedural paradigms as well.
Yea I somewhat agree with this. Though I mostly abhor OOP, it taken in small doses can be good. And procedural programming is always invaluable of course.
The way I read it, he wasn’t suggesting that was a good argument at all. He was just explaining what he believes dynamic type enthusiasts say.
Oh I read it the same way. I was just pointing out how much those two arguments contradict each other and that alone is almost enough of an argument without the extra ones the author gave. Though at the same time they are a bit of a straw man.
Well, in F# at least, this inference is the default. However, anybody can still fully type out the function signature. I think I get what you are saying, but in the case of a public API or interfaces the programmer can simply just add the type specifications.
But the problem with this being the default is most people wont go through the extra steps involved when they dont need to - which means you cannot really benefit from it most of the time. And the author implies that inferred types from bodies are always (or almost) the better option - which I disagree with.
Though I mostly abhor OOP, it taken in small doses can be good
Do you though? Or do you abhor inheritance. There are a lot of good ideas from OOP style code if you ignore inheritance (which was not originally part of the definition of OOP, in fact the original definition was very similar to some traits of function styles). It was only in later years and more modern times that OOP and inheritance was intertwined and IMO as a style it still has a lot to offer if you drop that one anti-feature.
The main argument against strictly typed languages imo isn't that types are time-consuming to write, it's that they forbid some otherwise valid programs. When writing down your types you are forced to write down some of the assumptions you make about your data (which is usually a good thing) but all assumptions aren't necessarily possible or ergonomic to express in your given programming languages type system.
Overall I have a strong preference for statically typed languages as they (usually) make code more readable and help prevent prevent bugs, but it's important to not strawman fans of dynamic types either!
Can you give any examples of such "otherwise valid programs"? Because a lot of times static typing also has ways to do everything dynamic typing can but it is just more difficult or (obviously) won't have the benefits of static typing.
I think the way some dynamically typed languages use maps is interesting. In most languages if you have a hashmap, all values have to have the same type. In a dynamic language you can have some members be methods, some members be values of potentially different types and so on. Of course, depending on what you want to achieve, you might be able to use a struct for example. A map is more flexible though. You can union two different maps, or you can have a function that takes a map that has either a or b. It's not necessarily impossible to express this in static types either, but there are many things here that quickly become tedious to do with types that Just Work in dynamically typed languages.
I've been liking Go. Reminds me of Python without the risk of filling my Linux install with dependencies.
So if there's a non-breaking security update of a dependency, all go apps depending on it need to be recompiled and relinked?
There's no way to link dynamically?
Rust does this too. In practice you just bump the lock file in rust and rebuild. It can be a bit rebuild heavy, but it's not too bad with a proper cache.
With regards to immutability and pure functions, I don't really care where the language falls on the scale the author defined so long as there is a way to easily express deeply immutable objects and pure functions. There are a ton of benefits of those two things and a lot of optimizations and assumptions that can be made with them. So I don't really care if everything is immutable by default but just being able to tell the compiler/runtime "Hey listen, this thing won't change ever, got it? So go crazy with passing it to threads and stuff" or "This function will 100% definitely return the same value if given the same input so if it takes a long time you can cache the result if you're able to." both seem very appealing.
Hey listen, this thing won’t change ever, got it? So go crazy with passing it to threads and stuff
I don't really care about that - none of the code I write is compute bound anyway. The CPU is generally twiddling it's thumbs idle for millions of cycles with occasional brief moments of activity when the SSD finally responds to the read operation that was requested an eternity ago. Or worse, it might be waiting on a network request.
I want immutability so I can, for example, make a copy of it and know my copy will always be the same as the original. In other words I want to be able to do my own caching/etc (possibly to avoid SSD access).
I'm surprised that he didn't mention Rust when talking about type inference. The way it does it is excellent.
The author wanted "a more powerful type of inference that can actually infer the whole type of a function by analyzing the body of the function", which Rust doesn't have by design.
Which I personally think is a good decision, although I like the clean looking syntax of Haskell, it's often not obvious what the function takes (which is why most are type annotating their function)
I really prefer rust's approach. The function signature is the contract. It makes it much easier to debug compared to overly generic pure functional code or c++ templates where everything is auto and perfect forwarded.
The only time in rust where this isn't true is with async functions. That's because the compiler adds a ton of sugar to make it easier to write.
Uh, not really? It's quite average compared to a complete inference like in Haskell and the likes.
I've become a big proponent of static typing and the functional programming paradigm, both of which solve the problem of figuring out what you're looking at.
With OOP and side effects you can receive a variable but still not know what it really is, is it modified somewhere before or after that you missed? Is it passed deep into nested functions that modify it? Who knows! With pure functions that goes away completely, you can easily inspect what goes into it.
Static typing also solves, among many other problems, this same issue. I've written a good deal of python, and anytime I go from rust, my current love affair, back to python I end up needing to take a break and go to my dog for emotional support. I've tried using mypy for static type analysis, I still use it, but it's very far from perfect; not least because many of the scientific libraries I use don't implement static type hints and are in fact written in such a way that implementing them would be difficult or nonsensical in some instances. It's a complete nightmare. The only solution would be every one of these libraries rewriting themselves, so not likely.
As someone who works extensively in Java, I agree, side-effects are tough and should be avoided in OOP. A lot of teams are moving toward more of an immutable object pattern as a standard, but its tough to enforce and adds a lot to the verbosity of the language.
Rust is a language I am currently in the process of learning and it seems great! 👍
TypeScript has become my go-to general-purpose option. Between Node.js & the web you can build anything (and share code between all these different domains), the JS ecosystem is huge so there's existing libraries & examples for everything, it gives you a good balance between productivity & performance (much faster to run than Python, much faster to write than Rust), and proper typing solves the rough edges of JavaScript without being so strict that you have to fight it.
I work with Kotlin, Rust, and Bash for various other specific things (e.g. Android apps, very low-level/high-performance code, and widely-compatible scripting) but 9 times out of 10 I'd reach for TypeScript if there isn't a special reason.
Rust is my goto language today. It dips its toes into a bit of everything I like doing (webdev, cli apps, etc) and I feel comfortable with it. I haven’t found a project where Rust would hold me back yet, but I’m assuming I will eventually.
I’m assuming I will eventually.
I somewhat doubt that. To me, it feels like Rust has consistently been getting better and better over the years with no end in sight! That said, I would be interested to hear any differing opinions.
Nothing is going to be the best at everything. Been programming for a long time and it’s a general truism that every cool new thing comes with a real trade off. I just haven’t found Rust’s yet.
Maybe I get lucky and the trade off is just all the weird community drama.
No it's not the best for everything (e.g. think about mental overhead, or sometimes syntactical overhead when programming in a very generic way, Haskell does a better job here IMHO), but it's so good in most areas that it's better IMHO to just stay in this one ecosystem for the entire stack (which I think is one of the main benefits of Rust, since tooling works so well...)
In my opinion, it depends on your goals and scope. If memory manipulation (Probably not the correct words), and/or every bit of performance matters, or it has a large scope, then one would pick Rust/C-lang. If development time and scope is small, something like Python is better.
Source: I used C++, C#, Python, and I use G'MIC (language very much geared for raster graphics processing).
I want to say Rust, but for some stuff it's probably very overkill. I love it, but there's a reason we don't use CPP for everything. (WASM may change things here but IDK)
Swift would be an excellent candidate for the title of "simpler Rust," but unfortunately it's doomed to rot in Apple's walled garden for all eternity.
Honestly, I would say TS (which I hate, but it's indispensable for many things) or any JVM/NET language (Kotlin, C#, both are good)
Does it matter if it is overkill as long as it doesn't slow you down too much.
I love it
Is a great reason to learn and use a language
which I hate
Is a great reason to avoid using it.
If you don't enjoy the tools you use them you are going to be far less motivated to work on things. Which will kill off a lot of projects.
There are something that TS is better at, but there are also a lot of things that rust is better at. Each languages haves different strengths and weaknesses. IMO both rust and TS are both fine general purpose languages to learn. Personally I would pick rust for most things though and would definitely favour it if I could only learn one language.
my opinion is a good language needs these qualities.
Portable, Safe, Fast, Easy.
which seems to be similar to the author of the article.
the language I have found to match the criteria the most is the D programming Language, its so mediocre in every area.
3 separate compilers, gcc llvm and mars backends.
can be as safe as you want it to be, with constructs for purity, GC, and contracts built in.
can be as fast as you want it to be it is a systems language and gives you all the necessary tools to go down to C level or below with a good in line assembly, but generally the idiomatic code is fast enough you dont need to go to the C level.
it is also very easy, you have a lot of C libraries and D libraries you can use and with a built in C compiler (currently beta) you can import C libraries easier, it also has a similar syntax to C so its very easy to rewrite C code in D, it has an optional GC so if you are going for max performance you can beta test algorithms quickly using the GC and when you are ready for max performance you can do it all manually, or you can use the feature to test what is using the GC so you can avoid the GC in loops, I did this in a game recently, I used the GC to setup all memory at the beginning and turned off the GC so I would never use it in a loop,
another nice feature is functional features that make the language cleaner to write.
I dont think this approach of being perfectly mediocre is necessarily the best but at least on paper its very good, and in practice there have been companies (specifically Weka Digital) that swear by the approach, they can use one language for both testing out ideas and the final product.
but again in a lot of cases you dont want a language that is good at everything you want one that is good for your use case.
also the article was very interesting, language design fascinates me and the article was a good read really enjoyed it. currently planning on learning Haskell and Zig soon should be fun to compare these once I am comfortable with them.
I so wish that D would have taken off :/
I used it at the time of the library split (there was a split in the community regarding the standard library, where Tango was the alternative). The compile time features of D were fantastic and they are still unmatched; as an example: For OpenGL (back then OpenGL 2.x) I could define the vertex attributes and had them checked at compile time when I started to fill the data with glMap! D templates and compile time code generation are on a whole new level, although it made tooling more difficult. If you know constexpr in C++, then this is nothing compared to what D has to offer.
yeah it has a really good blend of features, I think that it could have saved quite a few large companies a lot of money, as well, like facebook who keep re programming stuff, with D they could have used the same language and they would have very rarely re programmed anything, and when they did they would have been able to re use some code.
so I am quite surprised it didnt catch on, but it did have a few problems, one being it got relatively popular too quick before it could mature.
GC problems,
and being too experimental, a very good language is hidden behind a lot of features.
I agree on basically all points. Great article, nicely explained.
Typescript. Runs everywhere. Very active community. It’s the modern day Java.
I don't know I really hate when jumping to definitions in libraries, I often just land in the "typings" file. I also think that the type-system is often incoherent, has some weird side-effects and often leads to overengineering your typings... I just generally avoid Javascript based languages (which unfortunately is not really possible in frontend...)
Typescript has many shortcomings. About every language does. But it’s an undeniable very strong benefit that you can code the front and backend with it easily. It runs everywhere. It’s reasonably fast, for aws lambdas I found it had really good cold start time. I suspect because node is built on V8 which is highly optimized to get code running asap.
That accessibility and versatility makes it in my opinion the best general purpose language right now.
In backend I'm absolutely happy I can avoid it, there are more solid and more performant languages. I just can't program in the style I want without loosing massive performance in java/typescript, like in a functional composable style, it results in a mass of allocations, I hate it (because it looks cleaner and is a better architecture IMHO). Rust does a much better job here... I'm also not a huge fan of the type-system, it's super flexible, but has some incoherence, you tend to overengineer your types, no real ergonomic algebraic data types etc. It also has so many weird design decisions (e.g. prototypal inheritance) I don't understand and don't like...
I think Rust comes probably from the other direction, I can soon write my frontend in Rust without having much ergonomic loss (lets be honest, UI frameworks are currently more "solid(js)" in typescript than Rust, but I think that may change in the future...)
Probably should clarify. I think there are better languages in design and safety for backend.
However when it comes to a language you can pick up and crank out code for JS/TS is hard to beat. There’s libraries for everything and if your a full stack dev your probably really familiar with all the ends and outs.
If I have time and I want to make a solidly engineered product Rust is a better option. But often I’m pressed for time and TS can make a solid enough and performant enough product.
Do you have equivalent experience in both? I consider myself being faster in Rust nowadays than in Typescript (most likely because of the good tooling and the nice composable way the language is built.) But it probably depends on the type of the task I guess (e.g. if good libraries are available). But this stands obviously only in backend, writing UI as fast as with React or Solidjs or Svelte or vue or whatever (damn there are just too many frontend frameworks...) is certainly faster in Typescript.
Nah not equivalent. I’ve worked on rust for side projects and a few lower level networking things. Hard to get equivalent experience because my regular job is probably 60% frontend webapps.
Typescript being everywhere with strong libraries for even brand new tech is why I think it’s a great general purpose language. Whatever new product I’m integrating with always has a JS or TS library.
You don’t have to convince me Rust is a better language in so far as what it provides the programmer to make a working and correct program but I’d argue it’s not the best general purpose yet for many reasons that go beyond the design of the language and engineering. Such as availability, clients who pay me for code, and third party libraries
I am enjoying Swift.
Kotlin
Started Kotlin at my current job, coming from .NET. I'm impressed by Kotlin!
It really is an awesome language! I actually dont use it at work, but I've been learning it.
May I ask how your company uses it at work (not saying give exact company details, but a high level)?
Do you use it for web apps or Android?
Are any of your Devs migrating to it from Java?
Why are you moving to it from .NET?
It's a Healthcare app that companies use for their employees. They do the backend in kotlin and then write native apps for the mobile apps as well as have a website.
I thought I'd change up stacks when leaving my last job. It let me learn alot of new things.
The language itself certainly has a nice appeal, but I just don't like the JVM and inheritance styled OOP... it's personal... haha
The one you can use anywhere without much hassle and which you are most familar with.
For me it is PHP.
I second this as it's pretty easy to learn and the latest additions in PHP 8 have made it even better to use imo
Python is basically (IMO) C/C++ made easy.
Billions of libraries, works on even obscure hardware, simple syntax, no compiling(it's behinde the scene and just like always works) or linking etc. etc. etc.
Edit: this implies that C/C++ is the best language ever of course. Let the flame wars begin!
I very much disagree. In Python almost everything is abstracted away from you and it's dynamically and weakly typed. It's also interpreted.
Compare that to C which is literally one step above assembly, strongly and statically typed, as well as compiled.
They've got completely different use cases and have almost no overlap imo.
And yet I wouldn't touch C nowadays if I can avoid it anyhow. Zig (simple low level) and Rust (where e.g. C++ would be used, and for large higher level projects, as it really composes nicely) are IMHO the way modern systems programming is done
That's fine, but there are still plenty of use cases where you'd have to use C instead of anything else. I agree though, Rust is a better language than the monstrosity that is C++.
Starting a new personal project is different from what the industry requires. If you're working on integrated systems, guess which language you'll likely have to work with?
It's kind of like Typescript vs Javascript. There's zero reason to start a new project with Javascript, but there's still plenty of projects out there that use it.
Well depending on the "depth" of the stack Rust is probably the first choice by now for new projects in "the" industry (speaking of experience, a lot of companies are evaluating this choice now).
Have you tried Zig instead for low level stuff? It's a little bit simpler AFAIK and probably a good choice when the project doesn't get too big (in which case I would prefer Rust because of its safety guarantees). FFI is always an option...
With JSdoc and IDE support I can still understand why one would choose Javascript instead of Typecsript (having worked with both more extensively) and with e.g. https://github.com/tc39/proposal-type-annotations the boundaries will slowly fade. (mainly to avoid a massive stack of bundling and tooling software)
But I would absolutely avoid either honestly if possible Javascript (or the "static" typing Typescript is adding on top) is still not really comparable to a real strict statically typed language (apart from all the weirdness that consists in either). The way I want to program in it (functional, composable, avoiding this) is unfortunately relatively inefficient... I still don't get why it was "chosen" as the web language...
I don't use low level languages much anymore, but I'm glad to hear Rust is taking over for new projects (as it should imo)
. C++ is a monstrosity of a language that's overly complicated.
Maybe it's because it's the language I learned computer science in, but I feel (maybe hope is a better) that C will stick around. I firmly believe it's the best tool for students to learn how a computer intuitively works.
As for JS/TS, I only skimmed the github link you sent, but I don't understand how that's too different from TS. Seems to be a slightly different way of accomplishing static typing.
Also I mostly do front-end with TS, but what issues do you run into doing functional programming with TS out of curiosity? Never tried to do that
I firmly believe it’s the best tool for students to learn how a computer intuitively works.
Yeah C is certainly a language students should learn (in contrast to C++ IMHO). It's a dead simple language (well for what it is capable of at least, also to write a compiler for, which is a good academic task) that was very influential and is still here to stay for quite a while (not necessarily directly the language itself, but rather the ABI I think).
how that’s too different from TS
well it's really baked into the language, no intermediate transpiler or compiler is necessary, and the ecosystem should be a little bit nicer to use (as less bundling is necessary, which I kind of detest after having gone into that rabit hole a little bit too often and "wasted" quite some time with (configuring) it).
functional programming with TS out of curiosity?
It's not really issues, but I know that something like this:
is concise and reading like how it should be done, but it's just less efficient than just looping over the array and doing all the things in place (because every time filter or map or reduce or all the functional niceties is used, a new array is allocated and you want to absolutely avoid allocations if possible).
Javascript is a little bit dumb when it comes to allocations (in design itself, something like V8 can't really help here at least most of the time).
In Rust the same is often even more efficient than manually looping over, doing it in place it (probably because of aliasing guarantees). I saw a few interesting posts way back on reddit, that found this out, the (performance) equivalent imperative version was ugly to read. So the default way one would approach the problem in Rust is often also the most efficient, which is obviously very nice to have.
Or another thing I would like to use more often in Java/Typescript is factory functions, something like this:
function createMyObject(param1, param2) {
// do something with param1 and param2
// a few functions that could be seen as methods
function myMethod() {
param1 += 1 + param2;
}
return Object.freeze({
myMethod,
param1
})
}
But also here, everytime createMyObject is run, all of the stuff/methods inside is allocated again (instead of creating/compiling function references), maybe this can/will be optimized at some time (probably with a transpiler/compiler again, yay -.-).
So in general: writing nice (to read) code in Typescript/Javascript often leads to a lot of allocations, and I detest that a language is designed in a way where you want to write nice looking code but you're punished for it with inefficiency.
I've gotta say that was a really good argument and was incredibly well written.
Also very much agree with the compiler comment. Learned a lot from doing that project (twice actually) in college
Agree except Python is strongly typed.
In what way? Python has type hinting, but it's purely for linting and is not enforced at runtime. Python has always had dynamic duck typing.
Hi there! Looks like you linked to a Lemmy community using an URL instead of its name, which doesn't work well for people on different instances. Try fixing it like this: !programming@programming.dev
Hi there! Looks like you linked to a Lemmy community using an URL instead of its name, which doesn't work well for people on different instances. Try fixing it like this: !programming@lemmy.world/u/theherk) [@programming](https://programming.dev
Wow I pretty much disagree with everything you said haha. E.g. packaging/venv in python is absolute hell compared to something like cargo/crates in Rust. Try to manage a large project in python and you'll likely revise your answer (if you actually know all the nice alternatives out there...)
In my experience managing a large project comes down to having a consistent process/standards and enough experienced engineers in that language. Remove that and every single language leads to abominations.
I agree, that having a consistent process and good engineers is definitely most important, but a language itself definitely can guide you in the right direction. I think ironically Rust and C++ are good vice versa examples (unrelated to their target area, which happens to be the same (systems programming)), C++ has zillion ways to program in, finding the right and best way is definitely no easy task and requires massive experience in all kinds of paradigms, while Rust generally promotes you to do things in one/the "right" (IMHO) way, otherwise the borrow-checker annoys you all the time.
Yeah but a "good language" isn't some obscure, "better on the paper" language or some popular one, but one that has a large community, and not only in amateur circles.
That's why C/C++ is so hated but also so much used. Python is way easier but has the userbase and the libraries. If you don't need the speed, or memory management, you can do about anything with python.
Maybe Rust will take the place one day, or typescript, or kotlin, or JavaScript, or "insert new killer language" ...
Python is used by the research community, and by a whole slew of companies since a long time. You have a problem? You'll find the solution quickly.
Dealing with large projects? Go with C/C++ then ;-) I mean it's all about architecture.
And yet another time I disagree with pretty much all you've said.
you can do about anything with python.
And this thinking is why we have sloppy running UI with 10000 times the power of devices compared to say 20 years ago (where UI was not sloppy...).
Why sacrifice performance, language ergonomics(!) and write something in python for production?
I get why (AI) researchers are using it because it's easy to quickly hack stuff together, and prototype stuff.
But as soon as it's something larger with a bigger team you want to have static typing. because working in a team is pain in the ass with a untyped languages á la javascript or python. Also think about something like IDE tooling, it's so much more comfortable to use rust-analyzer (which I think really is generally the best LSP by now), compared to all the python tooling I tried (and that was a lot...).
Dealing with large projects? Go with C/C++ then ;-) I mean it’s all about architecture.
Sorry, but you sound a little bit unexperienced, I really would suggest learning a few more programming languages, it's not "all" about architecture. The languages/paradigms kind of suggest how you should layout your architecture, e.g. OOP by using classes (unfortunately often promoting the IMHO anti-pattern inheritance) , or functional by composing everything together without side-effects in functions.
C++ is absolutely the last language I would choose nowadays, it's an absolute techdebt mess, promoting all kinds of anti patterns IMHO (I've got roughly 10+ years of experience in it, for context). You really have to have a real good discipline and idea how to write programs to make a reasonable choice in architecture. And if you do it's ugly as hell anyways (using iterators for example is pain in the ass although you should do that). I just default to Rust, it's so much more comfortable than C++ in pretty much every aspect, way better designed language...
Really learning new languages also helps thinking about architectures/laying out your code in other languages, and generally helps improving your technical skill.
Interpreted language != Compiled language
Sure, but it does get compiler behind the scenes to pyx files.
Cython is a better equilavent as it does compile to C while enabling Python syntax. No one is arguing C or C++ is the best language. I'd even argue a perfect language does not exist. Simple syntax could be argued on a line to line basis, but forced indents is uncomfortable for some, and Julia could be argued to be better in that area. I'm one to hope Julia can take off.
Yeah Julia seems to be just python but better (no GIL if I have understood things correctly).
And lack of forced indentations. Forced indentations gets on my nerves even if I already gotten used to it. These day, all I use Python is small code snip test, and it's perfect for that as it strips out braces and other things which allows me to focus on a small code. I did used Python for slightly bigger things than that, but only to assist me with other coding languages, and I mainly used it for aiding into G'MIC scripting (Domain-Specific Language that is absolutely wonderful for raster graphics image processing).
Overall I agree with what the author says, though I have a few further thoughts:
These two arguments contradict each other and together are an argument for static typing, not against. Which just shows how weak these arguments are.
This bit I am not convinced by. Inferring the API of a function from its body makes it harder to see breaking changes when you refactor the body. It can be useful for internal private helpers, but IMO public APIs should be explicit about their signature.
I would go one step further here. It should support OOP and procedural paradigms as well. No single programming paradigm is best suited to all problems. Sometimes a mixed approach is best. Any language that heavily leans oneway at the expense of the others limits itself to the problems it can best solve. I do admit the far too many languages lean too much towards OOP at the expense of functional style.
So it is easy to push for a functional style over OOP in new languages. But I would be weary of purely functional language as well.
I don’t understand how types could be time consuming.
Some things are very easy to do in loosly typed languages - just as letting a function take a string or int, and then parsing that string into an int if a string was passed in. In a loosly typed language you can just call something like
if typeof(input)but in a strongly typed language you often need a lot more boiler plate and extra wrapper types to say the function can only take an int or string - for instance in rust you might need to wrap them in a enum first or some how create a trait and implement that for each types.This is quite a bit of extra upfront cost some of the time that really rubs people that are used to loosly typed languages the wrong way. So they think it is slow to work with types. But what they never seem to count is the countless hours you save knowing that when you read a value from something and pass it to a function that wants only an int, that the value is an int and you dont end up getting
2 + "2" = "22"and other suprising bugs in your program. Which results in less time debugging and writing tests for weird cases the compiler does not allow.But all that extra time if often not counted as that is dissociated from the original problem at hand. And they are already used to this cost - people often notice a new cost, but don't notice a possibly bigger saving else where.
I never understood this argument. If your function is supposed to take an int, then parse your string before calling it?
There are reasons you might want to, such as you are constructing something that has a few different ways to create it. Like maybe a date, can parse it from a string, pass in each bit as a separate argument, take in a Unix timestamp.
A lot of languages encourage this with constructors as you can often only have one.
IMO it is far better to just have different functions for each type you want to build something from like how it is done in rust.
But when you come from a language that encourages the opposite it can seem clunky to have to define separate functions for each. And it can take a while to accept the different way of working.
I agree, but I imagine dynamic type fans would say they don't understand why explicitly stating types can be helpful.
Optional typing is pretty useful, especially if the tooling is such that it catches most issues. I use Python's optional typing quite a bit, and my general approach is to add types if the function is intended to be reused or if it took more than three seconds to figure out what it does. We also use Typescript, and typing isn't necessary there either.
If your type system is too strict, it can be really annoying to work with and make simple things take longer. If it's too loose, you'll introduce stupid bugs.
Swift has entered the chat.
Yeah I think it’s a misunderstanding. There’s no way they aren’t encountering issues from dynamic types.
It can be nice not to have to worry about types when you are doing exploratory programming. For example, I once started by writing a function that did a computation and then returned another function constructed from the result of that computation, and then realized that I'd actually like to attach some metadata to that function. In Python, that is super-easy: you just add a new attribute to the object and you're done. At some point I wanted to tag it with an attribute that was itself a function, and that was easy as well. Eventually I got to the point where I was tagging it with a zillion functions and realized that I was being silly and replaced it with a proper class with methods. If I'd known in advance that this is where I was going to end up then I would have started with the class, but it was only after messing around that I got a solid notion of what the shape of the thing I was constructing should be, and it helped that I was able to mess around with things in arbitrary ways until I figured out what I really wanted without the language getting in my way at intermediate points.
Just to be clear, I am not saying that this is the only or best way to program, just that there are situations where having this level of flexibility available in the language can be incredibly freeing.
And don't get me wrong, I also love types for two reasons. First, because they let you create a machine-checked specification of what your code is doing, and the more powerful the type system, the better you can do at capturing important invariants in the types. Second, because powerful type systems enable their own kind of exploratory programming where instead of experimenting with code until it does what you want you instead experiment with the types until they express how you want your program to behave, after which writing the implementation is often very straightforward because it is so heavily constrained by the types (and the compiler will tell you when you screwed up).
From some of my own conversations with people they don't find it useful as a solo dev because they have to read the docs for dependencies even with types, and they only ever have to deal with their own code which they know we'll enough that they see types as a waste of time.
The way I read it, he wasn't suggesting that was a good argument at all. He was just explaining what he believes dynamic type enthusiasts say.
Well, in F# at least, this inference is the default. However, anybody can still fully type out the function signature. I think I get what you are saying, but in the case of a public API or interfaces the programmer can simply just add the type specifications.
Yea I somewhat agree with this. Though I mostly abhor OOP, it taken in small doses can be good. And procedural programming is always invaluable of course.
Oh I read it the same way. I was just pointing out how much those two arguments contradict each other and that alone is almost enough of an argument without the extra ones the author gave. Though at the same time they are a bit of a straw man.
But the problem with this being the default is most people wont go through the extra steps involved when they dont need to - which means you cannot really benefit from it most of the time. And the author implies that inferred types from bodies are always (or almost) the better option - which I disagree with.
Do you though? Or do you abhor inheritance. There are a lot of good ideas from OOP style code if you ignore inheritance (which was not originally part of the definition of OOP, in fact the original definition was very similar to some traits of function styles). It was only in later years and more modern times that OOP and inheritance was intertwined and IMO as a style it still has a lot to offer if you drop that one anti-feature.
The main argument against strictly typed languages imo isn't that types are time-consuming to write, it's that they forbid some otherwise valid programs. When writing down your types you are forced to write down some of the assumptions you make about your data (which is usually a good thing) but all assumptions aren't necessarily possible or ergonomic to express in your given programming languages type system.
Overall I have a strong preference for statically typed languages as they (usually) make code more readable and help prevent prevent bugs, but it's important to not strawman fans of dynamic types either!
Can you give any examples of such "otherwise valid programs"? Because a lot of times static typing also has ways to do everything dynamic typing can but it is just more difficult or (obviously) won't have the benefits of static typing.
I think the way some dynamically typed languages use maps is interesting. In most languages if you have a hashmap, all values have to have the same type. In a dynamic language you can have some members be methods, some members be values of potentially different types and so on. Of course, depending on what you want to achieve, you might be able to use a struct for example. A map is more flexible though. You can union two different maps, or you can have a function that takes a map that has either a or b. It's not necessarily impossible to express this in static types either, but there are many things here that quickly become tedious to do with types that Just Work in dynamically typed languages.
I've been liking Go. Reminds me of Python without the risk of filling my Linux install with dependencies.
So if there's a non-breaking security update of a dependency, all go apps depending on it need to be recompiled and relinked?
There's no way to link dynamically?
Rust does this too. In practice you just bump the lock file in rust and rebuild. It can be a bit rebuild heavy, but it's not too bad with a proper cache.
With regards to immutability and pure functions, I don't really care where the language falls on the scale the author defined so long as there is a way to easily express deeply immutable objects and pure functions. There are a ton of benefits of those two things and a lot of optimizations and assumptions that can be made with them. So I don't really care if everything is immutable by default but just being able to tell the compiler/runtime "Hey listen, this thing won't change ever, got it? So go crazy with passing it to threads and stuff" or "This function will 100% definitely return the same value if given the same input so if it takes a long time you can cache the result if you're able to." both seem very appealing.
I don't really care about that - none of the code I write is compute bound anyway. The CPU is generally twiddling it's thumbs idle for millions of cycles with occasional brief moments of activity when the SSD finally responds to the read operation that was requested an eternity ago. Or worse, it might be waiting on a network request.
I want immutability so I can, for example, make a copy of it and know my copy will always be the same as the original. In other words I want to be able to do my own caching/etc (possibly to avoid SSD access).
I'm surprised that he didn't mention Rust when talking about type inference. The way it does it is excellent.
The author wanted "a more powerful type of inference that can actually infer the whole type of a function by analyzing the body of the function", which Rust doesn't have by design.
Which I personally think is a good decision, although I like the clean looking syntax of Haskell, it's often not obvious what the function takes (which is why most are type annotating their function)
But Rusts type annotations have non the less its limitations, when excessively using traitbounds (but I hope that will be soon better with impl everywhere (see e.g. https://smallcultfollowing.com/babysteps/blog/2022/09/22/rust-2024-the-year-of-everywhere/))
I really prefer rust's approach. The function signature is the contract. It makes it much easier to debug compared to overly generic pure functional code or c++ templates where everything is
autoand perfect forwarded.The only time in rust where this isn't true is with async functions. That's because the compiler adds a ton of sugar to make it easier to write.
Uh, not really? It's quite average compared to a complete inference like in Haskell and the likes.
I've become a big proponent of static typing and the functional programming paradigm, both of which solve the problem of figuring out what you're looking at.
With OOP and side effects you can receive a variable but still not know what it really is, is it modified somewhere before or after that you missed? Is it passed deep into nested functions that modify it? Who knows! With pure functions that goes away completely, you can easily inspect what goes into it.
Static typing also solves, among many other problems, this same issue. I've written a good deal of python, and anytime I go from rust, my current love affair, back to python I end up needing to take a break and go to my dog for emotional support. I've tried using mypy for static type analysis, I still use it, but it's very far from perfect; not least because many of the scientific libraries I use don't implement static type hints and are in fact written in such a way that implementing them would be difficult or nonsensical in some instances. It's a complete nightmare. The only solution would be every one of these libraries rewriting themselves, so not likely.
As someone who works extensively in Java, I agree, side-effects are tough and should be avoided in OOP. A lot of teams are moving toward more of an immutable object pattern as a standard, but its tough to enforce and adds a lot to the verbosity of the language.
Rust is a language I am currently in the process of learning and it seems great! 👍
TypeScript has become my go-to general-purpose option. Between Node.js & the web you can build anything (and share code between all these different domains), the JS ecosystem is huge so there's existing libraries & examples for everything, it gives you a good balance between productivity & performance (much faster to run than Python, much faster to write than Rust), and proper typing solves the rough edges of JavaScript without being so strict that you have to fight it.
I work with Kotlin, Rust, and Bash for various other specific things (e.g. Android apps, very low-level/high-performance code, and widely-compatible scripting) but 9 times out of 10 I'd reach for TypeScript if there isn't a special reason.
Rust is my goto language today. It dips its toes into a bit of everything I like doing (webdev, cli apps, etc) and I feel comfortable with it. I haven’t found a project where Rust would hold me back yet, but I’m assuming I will eventually.
I somewhat doubt that. To me, it feels like Rust has consistently been getting better and better over the years with no end in sight! That said, I would be interested to hear any differing opinions.
Nothing is going to be the best at everything. Been programming for a long time and it’s a general truism that every cool new thing comes with a real trade off. I just haven’t found Rust’s yet.
Maybe I get lucky and the trade off is just all the weird community drama.
No it's not the best for everything (e.g. think about mental overhead, or sometimes syntactical overhead when programming in a very generic way, Haskell does a better job here IMHO), but it's so good in most areas that it's better IMHO to just stay in this one ecosystem for the entire stack (which I think is one of the main benefits of Rust, since tooling works so well...)
In my opinion, it depends on your goals and scope. If memory manipulation (Probably not the correct words), and/or every bit of performance matters, or it has a large scope, then one would pick Rust/C-lang. If development time and scope is small, something like Python is better.
Source: I used C++, C#, Python, and I use G'MIC (language very much geared for raster graphics processing).
I want to say Rust, but for some stuff it's probably very overkill. I love it, but there's a reason we don't use CPP for everything. (WASM may change things here but IDK)
Swift would be an excellent candidate for the title of "simpler Rust," but unfortunately it's doomed to rot in Apple's walled garden for all eternity.
Honestly, I would say TS (which I hate, but it's indispensable for many things) or any JVM/NET language (Kotlin, C#, both are good)
Does it matter if it is overkill as long as it doesn't slow you down too much.
Is a great reason to learn and use a language
Is a great reason to avoid using it.
If you don't enjoy the tools you use them you are going to be far less motivated to work on things. Which will kill off a lot of projects.
There are something that TS is better at, but there are also a lot of things that rust is better at. Each languages haves different strengths and weaknesses. IMO both rust and TS are both fine general purpose languages to learn. Personally I would pick rust for most things though and would definitely favour it if I could only learn one language.
my opinion is a good language needs these qualities. Portable, Safe, Fast, Easy.
which seems to be similar to the author of the article. the language I have found to match the criteria the most is the D programming Language, its so mediocre in every area.
3 separate compilers, gcc llvm and mars backends. can be as safe as you want it to be, with constructs for purity, GC, and contracts built in. can be as fast as you want it to be it is a systems language and gives you all the necessary tools to go down to C level or below with a good in line assembly, but generally the idiomatic code is fast enough you dont need to go to the C level.
it is also very easy, you have a lot of C libraries and D libraries you can use and with a built in C compiler (currently beta) you can import C libraries easier, it also has a similar syntax to C so its very easy to rewrite C code in D, it has an optional GC so if you are going for max performance you can beta test algorithms quickly using the GC and when you are ready for max performance you can do it all manually, or you can use the feature to test what is using the GC so you can avoid the GC in loops, I did this in a game recently, I used the GC to setup all memory at the beginning and turned off the GC so I would never use it in a loop,
another nice feature is functional features that make the language cleaner to write. I dont think this approach of being perfectly mediocre is necessarily the best but at least on paper its very good, and in practice there have been companies (specifically Weka Digital) that swear by the approach, they can use one language for both testing out ideas and the final product. but again in a lot of cases you dont want a language that is good at everything you want one that is good for your use case.
also the article was very interesting, language design fascinates me and the article was a good read really enjoyed it. currently planning on learning Haskell and Zig soon should be fun to compare these once I am comfortable with them.
I so wish that D would have taken off :/
I used it at the time of the library split (there was a split in the community regarding the standard library, where Tango was the alternative). The compile time features of D were fantastic and they are still unmatched; as an example: For OpenGL (back then OpenGL 2.x) I could define the vertex attributes and had them checked at compile time when I started to fill the data with glMap! D templates and compile time code generation are on a whole new level, although it made tooling more difficult. If you know constexpr in C++, then this is nothing compared to what D has to offer.
yeah it has a really good blend of features, I think that it could have saved quite a few large companies a lot of money, as well, like facebook who keep re programming stuff, with D they could have used the same language and they would have very rarely re programmed anything, and when they did they would have been able to re use some code. so I am quite surprised it didnt catch on, but it did have a few problems, one being it got relatively popular too quick before it could mature. GC problems, and being too experimental, a very good language is hidden behind a lot of features.
I agree on basically all points. Great article, nicely explained.
Typescript. Runs everywhere. Very active community. It’s the modern day Java.
I don't know I really hate when jumping to definitions in libraries, I often just land in the "typings" file. I also think that the type-system is often incoherent, has some weird side-effects and often leads to overengineering your typings... I just generally avoid Javascript based languages (which unfortunately is not really possible in frontend...)
Typescript has many shortcomings. About every language does. But it’s an undeniable very strong benefit that you can code the front and backend with it easily. It runs everywhere. It’s reasonably fast, for aws lambdas I found it had really good cold start time. I suspect because node is built on V8 which is highly optimized to get code running asap.
That accessibility and versatility makes it in my opinion the best general purpose language right now.
In backend I'm absolutely happy I can avoid it, there are more solid and more performant languages. I just can't program in the style I want without loosing massive performance in java/typescript, like in a functional composable style, it results in a mass of allocations, I hate it (because it looks cleaner and is a better architecture IMHO). Rust does a much better job here... I'm also not a huge fan of the type-system, it's super flexible, but has some incoherence, you tend to overengineer your types, no real ergonomic algebraic data types etc. It also has so many weird design decisions (e.g. prototypal inheritance) I don't understand and don't like...
I think Rust comes probably from the other direction, I can soon write my frontend in Rust without having much ergonomic loss (lets be honest, UI frameworks are currently more "solid(js)" in typescript than Rust, but I think that may change in the future...)
Probably should clarify. I think there are better languages in design and safety for backend.
However when it comes to a language you can pick up and crank out code for JS/TS is hard to beat. There’s libraries for everything and if your a full stack dev your probably really familiar with all the ends and outs.
If I have time and I want to make a solidly engineered product Rust is a better option. But often I’m pressed for time and TS can make a solid enough and performant enough product.
Do you have equivalent experience in both? I consider myself being faster in Rust nowadays than in Typescript (most likely because of the good tooling and the nice composable way the language is built.) But it probably depends on the type of the task I guess (e.g. if good libraries are available). But this stands obviously only in backend, writing UI as fast as with React or Solidjs or Svelte or vue or whatever (damn there are just too many frontend frameworks...) is certainly faster in Typescript.
Nah not equivalent. I’ve worked on rust for side projects and a few lower level networking things. Hard to get equivalent experience because my regular job is probably 60% frontend webapps.
Typescript being everywhere with strong libraries for even brand new tech is why I think it’s a great general purpose language. Whatever new product I’m integrating with always has a JS or TS library.
You don’t have to convince me Rust is a better language in so far as what it provides the programmer to make a working and correct program but I’d argue it’s not the best general purpose yet for many reasons that go beyond the design of the language and engineering. Such as availability, clients who pay me for code, and third party libraries
I am enjoying Swift.
Kotlin
Started Kotlin at my current job, coming from .NET. I'm impressed by Kotlin!
It really is an awesome language! I actually dont use it at work, but I've been learning it.
It's a Healthcare app that companies use for their employees. They do the backend in kotlin and then write native apps for the mobile apps as well as have a website.
I thought I'd change up stacks when leaving my last job. It let me learn alot of new things.
The language itself certainly has a nice appeal, but I just don't like the JVM and inheritance styled OOP... it's personal... haha
The one you can use anywhere without much hassle and which you are most familar with.
For me it is PHP.
I second this as it's pretty easy to learn and the latest additions in PHP 8 have made it even better to use imo
Python is basically (IMO) C/C++ made easy.
Billions of libraries, works on even obscure hardware, simple syntax, no compiling(it's behinde the scene and just like always works) or linking etc. etc. etc.
Edit: this implies that C/C++ is the best language ever of course. Let the flame wars begin!
I very much disagree. In Python almost everything is abstracted away from you and it's dynamically and weakly typed. It's also interpreted.
Compare that to C which is literally one step above assembly, strongly and statically typed, as well as compiled.
They've got completely different use cases and have almost no overlap imo.
And yet I wouldn't touch C nowadays if I can avoid it anyhow. Zig (simple low level) and Rust (where e.g. C++ would be used, and for large higher level projects, as it really composes nicely) are IMHO the way modern systems programming is done
That's fine, but there are still plenty of use cases where you'd have to use C instead of anything else. I agree though, Rust is a better language than the monstrosity that is C++.
Starting a new personal project is different from what the industry requires. If you're working on integrated systems, guess which language you'll likely have to work with?
It's kind of like Typescript vs Javascript. There's zero reason to start a new project with Javascript, but there's still plenty of projects out there that use it.
Well depending on the "depth" of the stack Rust is probably the first choice by now for new projects in "the" industry (speaking of experience, a lot of companies are evaluating this choice now).
Have you tried Zig instead for low level stuff? It's a little bit simpler AFAIK and probably a good choice when the project doesn't get too big (in which case I would prefer Rust because of its safety guarantees). FFI is always an option...
With JSdoc and IDE support I can still understand why one would choose Javascript instead of Typecsript (having worked with both more extensively) and with e.g. https://github.com/tc39/proposal-type-annotations the boundaries will slowly fade. (mainly to avoid a massive stack of bundling and tooling software)
But I would absolutely avoid either honestly if possible Javascript (or the "static" typing Typescript is adding on top) is still not really comparable to a real strict statically typed language (apart from all the weirdness that consists in either). The way I want to program in it (functional, composable, avoiding
this) is unfortunately relatively inefficient... I still don't get why it was "chosen" as the web language...I don't use low level languages much anymore, but I'm glad to hear Rust is taking over for new projects (as it should imo) . C++ is a monstrosity of a language that's overly complicated.
Maybe it's because it's the language I learned computer science in, but I feel (maybe hope is a better) that C will stick around. I firmly believe it's the best tool for students to learn how a computer intuitively works.
As for JS/TS, I only skimmed the github link you sent, but I don't understand how that's too different from TS. Seems to be a slightly different way of accomplishing static typing.
Also I mostly do front-end with TS, but what issues do you run into doing functional programming with TS out of curiosity? Never tried to do that
Yeah C is certainly a language students should learn (in contrast to C++ IMHO). It's a dead simple language (well for what it is capable of at least, also to write a compiler for, which is a good academic task) that was very influential and is still here to stay for quite a while (not necessarily directly the language itself, but rather the ABI I think).
well it's really baked into the language, no intermediate transpiler or compiler is necessary, and the ecosystem should be a little bit nicer to use (as less bundling is necessary, which I kind of detest after having gone into that rabit hole a little bit too often and "wasted" quite some time with (configuring) it).
It's not really issues, but I know that something like this:
is concise and reading like how it should be done, but it's just less efficient than just looping over the array and doing all the things in place (because every time
filterormaporreduceor all the functional niceties is used, a new array is allocated and you want to absolutely avoid allocations if possible). Javascript is a little bit dumb when it comes to allocations (in design itself, something like V8 can't really help here at least most of the time).In Rust the same is often even more efficient than manually looping over, doing it in place it (probably because of aliasing guarantees). I saw a few interesting posts way back on reddit, that found this out, the (performance) equivalent imperative version was ugly to read. So the default way one would approach the problem in Rust is often also the most efficient, which is obviously very nice to have.
Or another thing I would like to use more often in Java/Typescript is factory functions, something like this:
But also here, everytime
createMyObjectis run, all of the stuff/methods inside is allocated again (instead of creating/compiling function references), maybe this can/will be optimized at some time (probably with a transpiler/compiler again, yay -.-).So in general: writing nice (to read) code in Typescript/Javascript often leads to a lot of allocations, and I detest that a language is designed in a way where you want to write nice looking code but you're punished for it with inefficiency.
I've gotta say that was a really good argument and was incredibly well written.
Also very much agree with the compiler comment. Learned a lot from doing that project (twice actually) in college
Agree except Python is strongly typed.
In what way? Python has type hinting, but it's purely for linting and is not enforced at runtime. Python has always had dynamic duck typing.
@theherk @programming
Yes Python is dynamically typed but not weakly typed. Try
“foo” + 1.See https://wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language
Thanks, that makes sense.
@theherk @programming
Hi there! Looks like you linked to a Lemmy community using an URL instead of its name, which doesn't work well for people on different instances. Try fixing it like this: !programming@programming.dev
Hi there! Looks like you linked to a Lemmy community using an URL instead of its name, which doesn't work well for people on different instances. Try fixing it like this: !programming@lemmy.world/u/theherk) [@programming](https://programming.dev
Wow I pretty much disagree with everything you said haha. E.g. packaging/venv in python is absolute hell compared to something like cargo/crates in Rust. Try to manage a large project in python and you'll likely revise your answer (if you actually know all the nice alternatives out there...)
In my experience managing a large project comes down to having a consistent process/standards and enough experienced engineers in that language. Remove that and every single language leads to abominations.
I agree, that having a consistent process and good engineers is definitely most important, but a language itself definitely can guide you in the right direction. I think ironically Rust and C++ are good vice versa examples (unrelated to their target area, which happens to be the same (systems programming)), C++ has zillion ways to program in, finding the right and best way is definitely no easy task and requires massive experience in all kinds of paradigms, while Rust generally promotes you to do things in one/the "right" (IMHO) way, otherwise the borrow-checker annoys you all the time.
Yeah but a "good language" isn't some obscure, "better on the paper" language or some popular one, but one that has a large community, and not only in amateur circles.
That's why C/C++ is so hated but also so much used. Python is way easier but has the userbase and the libraries. If you don't need the speed, or memory management, you can do about anything with python.
Maybe Rust will take the place one day, or typescript, or kotlin, or JavaScript, or "insert new killer language" ...
Python is used by the research community, and by a whole slew of companies since a long time. You have a problem? You'll find the solution quickly.
Dealing with large projects? Go with C/C++ then ;-) I mean it's all about architecture.
And yet another time I disagree with pretty much all you've said.
And this thinking is why we have sloppy running UI with 10000 times the power of devices compared to say 20 years ago (where UI was not sloppy...).
Why sacrifice performance, language ergonomics(!) and write something in python for production? I get why (AI) researchers are using it because it's easy to quickly hack stuff together, and prototype stuff.
But as soon as it's something larger with a bigger team you want to have static typing. because working in a team is pain in the ass with a untyped languages á la javascript or python. Also think about something like IDE tooling, it's so much more comfortable to use rust-analyzer (which I think really is generally the best LSP by now), compared to all the python tooling I tried (and that was a lot...).
Sorry, but you sound a little bit unexperienced, I really would suggest learning a few more programming languages, it's not "all" about architecture. The languages/paradigms kind of suggest how you should layout your architecture, e.g. OOP by using classes (unfortunately often promoting the IMHO anti-pattern inheritance) , or functional by composing everything together without side-effects in functions.
C++ is absolutely the last language I would choose nowadays, it's an absolute techdebt mess, promoting all kinds of anti patterns IMHO (I've got roughly 10+ years of experience in it, for context). You really have to have a real good discipline and idea how to write programs to make a reasonable choice in architecture. And if you do it's ugly as hell anyways (using iterators for example is pain in the ass although you should do that). I just default to Rust, it's so much more comfortable than C++ in pretty much every aspect, way better designed language...
Really learning new languages also helps thinking about architectures/laying out your code in other languages, and generally helps improving your technical skill.
Interpreted language != Compiled language
Sure, but it does get compiler behind the scenes to pyx files.
Cython is a better equilavent as it does compile to C while enabling Python syntax. No one is arguing C or C++ is the best language. I'd even argue a perfect language does not exist. Simple syntax could be argued on a line to line basis, but forced indents is uncomfortable for some, and Julia could be argued to be better in that area. I'm one to hope Julia can take off.
Yeah Julia seems to be just python but better (no GIL if I have understood things correctly).
And lack of forced indentations. Forced indentations gets on my nerves even if I already gotten used to it. These day, all I use Python is small code snip test, and it's perfect for that as it strips out braces and other things which allows me to focus on a small code. I did used Python for slightly bigger things than that, but only to assist me with other coding languages, and I mainly used it for aiding into G'MIC scripting (Domain-Specific Language that is absolutely wonderful for raster graphics image processing).