After working professionally on servers in Java, PHP, Node, Python, Ruby, Rust - I can confidently say it's all the same. Whenever one language has some significant superiority, the others copy that functionality anyway (whether in a library or as part of the language) The only significant factors are execution speed (Rust/Go with a clear advantage) and development speed (Python/Node with a clear advantage) In 95% of scenarios, it doesn't really matter
I have a few hundred hours of watch time on this channel and the biggest takeaway I have is "any time people claim some technology is worse than x and y it's just a skill issue" and it really stuck with me.
people should spend more time creating awesome stuff and showcasing their work than bashing other people for their tool choice. except for javascript programmers, who totally suck. :)
I had a project where they installed Windows 10 IoT core just because of single language productivity just because the department where R&D team was situated was in the C# department of the buiilding - despite the project was an embedded project. A whole team tried to work out how the hell to get the IoT core "properly" work (not just 256 colors, have network, etc), while I secretly gave the FULL task to two interns who coded the whole application in linux. They finished - not the prototype, but the app - in two weeks. Just imagine how much I had to explain what is being happening - especially that this task was supposed to take man-months :D
@@DavidSchmitt Oh and missed to add, but from the context it was clear that the interns never even used embedded linux before - just knew this secret human skill called reading documentation :D
Maybe someone should have told the C# department that .NET became cross-platform a few years ago...I hope you weren't the project manager in this, otherwise you can also blame yourself.
@@Asto508 Plus information is that the reason they literally wanted to use C# is to "create the GUI" in either UWP or something they supposedly "know" (according to management(tm)) So it was management thinking like an excel table: "what is in it that this department already knows" - and this was heightened by them being some kind of MS gold partner and advisors advising this IoT core bullshit to them haha. They literally couln't make the OS at all to work, the libraries in that environment literally did not work (at least not at the time) and just booting windows took like 120% of the resources of the little machine. All this for a "GUI" that literally had 2-3 buttons, some thing and a single screen... It was for a logistics appliance / equipment.
I say that I only use c++ because it makes me feel bigger brained than everyone, but it's really because I was traumatized learning it as my first language and don't want to learn others as a result.
no other language is as convoluted and messy as C++, rest assured, anything you learn afterwards will be easier than C++ (with the exception of maybe learning haskell and some other vastly different language from ur standard C like language)
i suggest you trying out python then, i actually used python yesterday to convert images into uint16_t C arrays for display ... after C++ using python will be such a joyful experience
C was one of my early languages, not my first, that would be Basic. But moved from C to C++, then from C++ to Pascal, and lots of others. What I can tell you things get easier when learning a new language, and I would argue becomes fun learning a new one. All the skills you have learned in C++ should easily transfer to most other languages, apart from Rust. :)
@@keithjohnson6510 rust is fairly easy, it had saner defaults than C++, u don't have to fight the language to get good behavior out of RAII and the language doesn't make expensive copies behind ur back rust only becomes "hard" if you try to write certain types of programs in safe mode when it should just be unsafe. the only people that think that rust is "hard" are people that tried it for 10 minutes,got annoyed at the borrow checker and left. Rust is more annoying to write cause the borrow checker is constantly in odds with u but other than that the language isn't really "hard". of course u might not always want Rust or might just not like it, which is ok. U can use something else, no one is forcing u to use rust
Oh man, the comment "How different is Go from JavaScript" lmao. At my previous employer, they absolutely refused to take my solution written in Python because no one on the Dev team knew Python (I was in QA). I spent two of my weekends rewriting it in C# with Thread primitives (because I had never written C# before, so I was winging it as best I could) and they still rejected it because they didn't have anyone qualified to QA my work. Suffice to say that I'm still salty about it to this day . At current employer, someone wrote a bulletproof web service in Go, and no one at the company writes Go anymore. Incidentally, I'm learning Go (after your frequent praise of it), and the engineer who was tasked with patching it recently said it was easy to learn and he doesn't get the fuss. Some people are just stubborn and unwilling to change.
That’s actually pretty valid. If no one knows Python , it is more expensive for the company. As programmers we generally don’t think about things like finance & availability of dev, but those are equally important too. When I started my company and less than < 25 people, I had strict rules: All in backend in Python, all infra in go, anything needs safety is Java and anything needs performance is C. FE is either jQuery (if tightly coupled with BE) or Ember. Mobile: all native - Swift and Kotlin
@@Qrzychu92 we were two people doing everything for 2 years. I didn’t code in Java, C and Kotlin. My cofounder did. I took care of BE, FE, Infra & iOS app. My co-founder took care of Security, Performance & Android apps. These are the only things we knew, and didn’t have the time to learn anything else .
@@BrunoCodeman " why don't you know formal logic yet dammit?! how the FUCK are you gonna be a FUCKING web dev without knowing formal logic?! Go pick up a logic textbook you shameful excuse for a frontend dev!!!!" - An unemployed CS grad "And NOT only that...WHERE is your calculus knowledge? You need THREE courses of calculus to even THINK actually WRITING javascript. You're supposed to just LOOK at javascript, and prove it using formally methods, ya DUNCE! Not actually write it!" "Where on GODS. GREEN. EARTH. Is your knowledge of fucking CHEMISTRY, BIOLOGY, PHYSICS?! You need AT LEAST ONE! DO you even know the simple difference between MOLES and GRAMS?? Programmers will NEED this in industry!" "Where is your philosophy knowledge?!! Plato? Socrates? Ring a bell??!" "Your LITERARY STUDIES?! HMMM??" "Do you even know if finite automata are turing complete???" "Feminism and french literature?! Bah. You wouldn't understand a WORD in that course!"
@@BrunoCodeman It REALLY depends 😂. I went to a bootcamp/trade school which taught C VERY heavily, and I mean HEAVY. Rewrote common libs, wrote printf, wrote a small kernal, DB, etc. It depends on where you go and what you learn, but i doubt any camp teaching javascript only, actually produces competent engineers. Thats just web dev and barely even that
"Deployment -- figuring out shouldnt' cost you any more than a day" In my experience the people who say this are those who commit AWS keys into git and get their AWS account immediately hacked.
@@nemanjatrivic9505 github actions, gitlab CI/CD or similar is just fine. One nice trick is make a runner in AWS (EC2 instance, EKS pod, whatever), use instance roles instead of IAM user. Now you're not exposing credentials directly. Downside you must harden the runner.
Gatekeeping is when you're an active 42 year old and the surgeon is reluctant to fix your shoulder because "these injuries are part of the natural ageing process"
Hi Prime, Thanks for all the info you put on your channel. Even though I am not a dev, I have learned a lot about the industry and how things work at a nuts and bolts level.
There is no getting around the fact that querying a relational database is a fundamentally different thing than just about everything that doesn't involve the DB. One language isn't enough if you care at all about getting the best performance out of your system.
This is nonsense. All we are doing is reading from and writing to memory. So long as a program can do that than you can optimize performance by doing just what you need in a way the computer can do the fastest it can. All languages just give varying degrees of control and boiler plate to do that.
WASM (and Blazor in particular) has allowed me to use C# on both the server and client-side. I've been very happy with it. I have a hate relationship with javascript. Yeah, I said it. Not love/hate, just hate. I'm old school and hate web development in general, but it refuses to die as we continue to twist and bastardize HTTP/S to do things it was never meant to do. From a business standpoint though? It's so damn convenient to have access to everybody with a browser and internet connection (see: everybody on the planet). My shared library I use for both server and client-side just works right out of the box. It continues to grow, and this is just my first go at it. As a game running server-side, I don't need (or want) my server-side logic on the client, but if I did, there's no reason it wouldn't work. As much as I hate MS, their .NET team has done an amazing job bringing C# / .NET into the browser. Nearly everything I know about .NET and C# just works, in both paradigms.
It sucks when I need the best UI library for something, and it's available just for React. I had to ditch using vue for the project because the React DndKit library was the best available. I never did a project this large, and just setting up the library was a pain, I'm learning React and Typescript and all of that front-end package mess. I never had such complexity with setting up my dev environment with python, surely, I get packages not being compatible with each other sometimes for things like Automatic1111 which I have to deal with even though I'm not even developing, I'm just using the thing as a user. (For generating images with Stable Diffusion).
Yes. HTML is a language even if it isn't a programming language. English is another language not mentioned in the video. Prime also kept interchanging "language" with "programming language" incorrectly as if he forgot about every other type of language. That said, config files and libraries are not languages of any kind. The single language article author should have said "technologies" or something sufficiently broad if he wanted to list non-languages like config files.
@@IARRCSim Yeah i'm just mostly coming to the defense of HTML and YAML, etc. YAML may be simple, but if you want to fully understand what you're writing, you still have to Read the Friendly Manual or some kind of thing to learn it.
The day I learned that I don't speak any languages, I only write in them... And all these years I have been thinking I speaking the languages Danish, English, few words of German and French just to find out they are not languages at all... Man what a let down :(.
If PHP is bad, then you haven't seen shit, it's one of the better languages out there and you're probably just malding because you hate its syntax @@BusinessWolf1
@@vitalyl1327 I mean sure, I'll concede that, I've never written Datalog. I'm not sure what to think of Datalog as a backend, I'd need to try it to see if it works. The fact it requires a DSL is still a step down. If I wanted that, I'd say C# extensions are the greatest (essentially adding static methods to the class definitions at any point), but I mentioned Linq, which is built on top of said extensions. The reason why is simply that Linq gives you the benefits of extensions without the drawbacks of writing them and footgunning yourself like you will inevitably do. It also doesn't require any external code.
about the orm argument, I generally just use orms to setup the db connection and then rawdog sql most of the time. The reason for that is simply: orms generally maintain the schma/anatomy of the db,tables etc. I just don't want to care about that and let the orm do that stuff.
2:53 protobuf and similar language-agnostic type definitions are way underappreciated and underutilised. Every project I've suggested starting with something like that might be a good idea has been shut down as unnecessary... and then in production there are constant bugs being patched with code to check the validity of the data both front end and back end
productivity is not the reason, cutting cost is, my flutter devs can do everything from the backend to the frontend to whatever. That's why I used flutter for my previous startup. Productivity plays a role, for instance, my flutter devs couldn't edit nodejs cloud functions and I'm not going to hire nodejs devs just to maintain few functions. But it's a cost game not a productivity game. At the end of the day, management pays the bills and salaries, so everything comes down to cost, no one cares about productivity, productivity is nice if it decreases the cost but it's not the main concern whenever we choose a language. I picked flutter back in 2018, when ti was in beta stages and I didn't know anything about it, all I know is it can publish web and apps, I needed both and couldn't afford to hire many devs.
If you want to do it all as a solo developer in a short time frame, yes single language increases your productivity but the quality and performance suffers. That being said productivity is a corporate measure, where there are teams dedicated to each section, so the single language doesn’t really matter. If you’re not a corporation, productivity should be lower on your list of concerns. Quality should be your main concern, that’s where you will beat out the corporations.
i think the question here what is "short time frame" sometimes u see ppl overstaying their welcome in one language. i think for me when someone can make any professional project its time to move from language focus to project focus.
I learn of so many new programing concepts that I have to search up what they are, why they are useful, and how to use them because I feel like I am just a script kiddie when I listen to Prime's videos.
Spicy take: I regret ever going anywhere near the JavaScript / TypeScript ecosystem. Should have just gone with Go, while learning Rust (when finer control is required) Heck. I think Python would have been a better investment because of all the AI trends. Also not learning C sooner was a dumb move on my part.
5:22 Sometimes it takes me more time than it should to realize that I've been blessed to have a professor that teaches me programming at university and is close to the real world (and is also one of the world's leading experts in parallelization)
Type safety, single language productivity, and languages like Python with authoritarian tabbing requirements are all just copes for not being a better programmer. You don't need all these fancy things that greatly restrict you in an attempt to reduce errors if you just don't make errors. If you routinely write code that's too hard for you to debug, you need to write less complex code, you don't need to switch to a less powerful language that does more hand-holding.
@11:00 this is why everyone says frontend web developers aren't real programmers. It's about what they don't know that they don't know.* *Usually any elementary computer science at all or that HTML isn't programming
23:57 but muh OrderByDescending , that's a weird take as the only difference is whether or not you bother to have an OrderByDescending function added to the array prototype, it's just a wrapper for a sort in most languages. And both are NOT onelines for legibility on purpose, and in deployment both can still become one line when shipped, if not outright minified.
My favorite part of your videos are the inevitable moment when you get an alert and you proceed to say I forgot to turn off alerts lol. I think it happens in every single one of your videos.
Yup and Zod are very useful in vanilla JS, as they are runtime "type safety". However, after some thought, it turns out that Zod and Yup can provide features that are impossible in compile time type safety. When interacting with an unknown API, where it is unreliable, sometimes it may have proper types and sometimes not. Compile time types are indispensible and extremely important due to the efficiency they bring, but they cant cover all scenarios. Another case that Yup would cover that static types don't is with input coercions. If your data is invalid, you just get an error and it stops. With Yup, you can force it to be valid, but just log the errors without crashing. All in all, it is better to have both rather than just one.
At the very least don’t be out here chasing the next big tech, and adding languages to the list JUST cuz some new API is Shinier than yours 😂❤ Some guys legit just get bored with being able to do their job in an appropriate amount of time 😂
saying that it's not a "real" language or that it's not for backend is the gatekeeping part. It can be as bad as you want it to be, it's still a real language, and can be used for the backend.
@@jakobhetland4083 Having an opinion or saying something (especially when it's a fact hehe) is not gatekeeping, because it is not "trying to control who gets particular resources, power or opportunities and who does not"(Cambridge dictionary). Stating an opinion by anyone is not gatekeeping unless acted on. If a boss would fire someone because they believe that js is good for a server that would be gatekeeping. If a person would harass others because of their opinion that would be gatekeeping.
That hot take around 30 mins where you say “if someone says JavaScript isn’t a real language and you get so discouraged you stop programming maybe you should stop programming” is my favorite thing you’ve ever said. I use js practically every day. But opinions can’t hurt you! ❤ sticks and stones man
The gatekeeping conversation was really bad to witness. Prime example of how it is absolutely impossible to have meaningful conversation between one person and a thousand monkeys on typewriters. The conversation STARTED because Primeagen disagreed with the author that he said Javascript was not a real language, saying the author should've said something along the lines of "a language designed for the backend" or something like that. People in chat "probably" (I can't assume I know what they were thinking, ofc, but am steelmanning their position) said it was bad gatekeeping in this case because the author apparently created a gate beyond which all "real" programming languages are, and JS is out of this gate, so the author is gatekeeping the status of "real" programming language to javascript. I'm sure that Primeagen agrees this is a stupid take, and there is no real way to logically defend this position. JS is a programming language whether we like it or not. Is the gate between "real" programming languages and "not real" a good gate to keep? Well, sure. Just like thePrimeagen at the beginning talking about YAML, and however many conversations we can have about HTML, and the argument on turing completeness etc., but never in a million years no one will seriously say Powerpoint is a programming language. But JS is a programming language by any (reasonable, imo) measure. But then of course, people got rustled because if all they know is JS and someone is out there saying JS is not a "real" programming language, then they might feel like the person is saying they are not "real" programmers. All of which does not bare in the whole conversation. The whole discussion of what is gatekeeping, what is the gate, how is it being kept, prime talking about the person feeling welcomed or giving up programming, most of what I saw in chat... ALL OF IT was people talking past eachother. The author, by saying JS is not a "real" programming language, created a gate and kept JS out of it. ThePrimeagen had his take that the author shouldn't have used the wording he did. Chat said that what the author did was gatekeeping. It APPEARS thePrimeagen saw the comments about gatekeeping and thought it was about the separation between back and front end that was being kept, and argued from that position. "saying other programming languages are better for the backend is not gatekeeping". Chaos ensued and no-one learned nothing.
Also wanna share some of my experiences here. I'm (still) a mobile dev with a focus on android for now. My career began at a small outstuff company with Android and Kotlin, with some background experience (python and cpp). I knew that I wanted to stick with android for a while, but the CEO and my mentor wanted me to learn swift and ios after 1 year I spent with kotlin/java. Their offer was "get laid off or learn this shit", so I as a poor student started to learn a new platform and language. About half a year later I was again dragged to learn flutter for new projects. My salary was the same all this time, but I had no choice at the moment because dropping only money income is risky. This was a nightmare, I switched context so often that I couldn't get good at least with one technology. It may be the same mobile development, but to really understand a technology you need to work with it for a while. It is good to have a broad range of skills, but 1) don't start a new technology at the beginning of your career and 2) use technologies you like or you (eventually) get paid for
21:31 Yes, of course you can do N+1 with LINQ, or you can throw an exception at the orm level every time someone does N+1. Then all N+1 will be explicitly specified by you in the code. In js you'll have to run the request and look at the generated code to find out. So there is a difference in the feedback loop with the ORM: c# - when you type, js - in production. (I haven’t written C# for more than 8 years, today probably C# servers are generated with chatgpt, so no one cares about N+1)
30:38 and this is why i still use nano. I have been given a lot of crap for using it (yes yes yes, it mangles long lines. I get it), but the longer I've been in the field, and have become Senior in my role, it's just another tool. Sure, vim is "neckbeard approved," but when you come to me asking me why your terraform sucks ass, you'll see nano and like it.
This article takes me back to some other topic you covered. You are most productive in the language you are most comfortable with. There may be a language that solves your specific problem perfectly, but if it takes you forever to understand it, you could spend that time being productive in your comfort zone and then revisit the idea when it's not critical for delivery. That said, I've had to change the language I use at each new job, so I am uniquely familiar with picking the "right" language for the job, and feel comfortable switching. That said, I don't fault someone for being a "one-trick [language] pony". I have seen experts do crazy things in their language of choice, while I'm usually writing bog-standard code that is as-intended.
Uhhh... Isn't the argument for single language related to the cost of hiring and ease of integration? If anything it means companies don't have to hire two developer to do front end and backend and even if you do have such teams, they have a common language/understanding and therefore no compatibility issues. I.e. Javascript object is a javascript object.
I don't understand what the Protobuf argument has to do with anything. You still need to define and redefine types, and maintain those definitions between your applications. That gets more and more unwieldy as the application grows, without exception. Also, obviously, codegen tools exist that can ease the difficulty of this process, but that's yet another layer of complexity you're adding to your stack that you may or may not need to maintain.
The language libraries, ecosystem, and community support matter more than familiar syntax. Syntax is the least important factor when building anything. Matching the needs of the problem being solved is everything.
Libraries and ecosystem only matter to the glue "programmers" who just bolt libraries together. They are not needed anyway and will be replaced with stochastic parrots. Real engineers care much less about any third party libraries and frameworks.
@@vitalyl1327That’s not true, mostly everyone needs to interface with middleware, OS, or hardware. And redoing commodity code isn’t something “real programmers” do, it’s a waste of time. If you are a game engine dev, you are going to use DirectX or Vulkan and shader languages. That’s usually C++. If you are an AI developer, you are probably going to use a mix of Python, C++, and cuda. If you are an iOS developer, you may be using Swift. The problem being solved and support needed is what matters. People that reuse high quality components and pick the best tools for the problem are “real developers” Lots of languages support calling other libraries that weren’t authored in that language, but sometimes the shim code is more work and more problematic than using one of the natural languages the rest of the community uses to solve that problem.
@@vitalyl1327 outside of lib languages have domain that they shine in because they view the world differently which let them be better at type of project. c is better for system programming because of it simplicity, C++/rust give u more complexity and reward u with features which make large lib ecosystem easier to make, etc... i think one should focus on trying to see what language fit the project rather then the opposite. there a lot of stuff in C++ that is really just rewritten ur own core stuff and extend that by using 3rd big lib that can solve almost anything, u can find almost anything under the sun, i don't think it say much about u being real engineer or not but rather what world view fit better the project. for example C++ is clear winning for robotic and games
I hate half-assed stuff. Either the same SAME, or totally different. "The same but a few differences here and there" is the worst. People talk about "mental context switching", if you works for both FE and BE, context switch is inevitable. And if i gonna switch anyway, i want them to be completely different "JS on the browser" vs "JS in Node". Juggl your mind between those subtle differences is a much worse experience than have something completely different. When I see PHP or Java, my mind immediately switch to "backend mode", when I see JS/ TS my mind immediately switch to "frontend mode". That the experience I want
I don't think that protobuffs are going to be able to make it so that when I remove a property from an object type in my backend code I will instantly be able to see what bugs it will cause in my frontend. I'm assuming I would have to manually export the definitions from my backend repo and then manually trigger code generation for the corresponding typescript interfaces. Setting all this up is not trivial either.
That is a failure of your process. You do not update one system without updating the other - meaning you check to see your proto files agree before deploying anything. Ever.
@@kevinb1594 I think you are missing the point. With full stack typescript i get instant feedback in my editor. I don't have to make any PRs, I don't have to run any commands, I type something and in about 2-3 seconds the ts compiler running in the background in watch mode draws squigly lines under all the places affected by my change.
@@kaanatakan Ok? Those aren't exactly the same issue. Protobuf ensure the contract between your backend/microservices/apis are in alignment. Has nothing to do with linting. Assuming your backend is the source of truth, you removing that property IS the correct, updated contractual change.
ive been using gamemaker for my frontend and nodejs for my backend for a video game ive been developing for a while and it is nice because they are different languages with different strengths, but are gml is really just javascript even with the same syntax so the communication goes very smoothly, and can integrate lots of middleware to my game
It's a programming language, a domain specific programming language, not a general purpose one tho, no need to trust me on that, just open the blink source code of Chromium and search for the grammar parser for both CSS and HTML in there, there's a tokenizer and parser for both. HTML is parsed and outputs to a DOM tree, and CSS becomes the CSSOM which both are used by the browser, they were implemented using... yeah, that's right, compiler theory. See HTMLTokenizer.cpp and CSSTokenizer.cpp for a start.
Protobuf, msgpack are not workarounds. But it is indeed a new significant component to your system. When you start a small project, you probably would like to have it in 1 language, with less hustle. When the project grows and matures, you’ll need to encode your protocols - that’s where the protobuf comes in.
after moving to protobufs with basic validation built into the message definitions themselves with protovalidate i cant image going back to loosey goosey JSON for the wire format
the energy in the first 5 minutes of this video is so tense I hate it. Because it reminds me of the circles I go in my mind when I think about things at work that annoy me, and I know it's unhealthy.
20:00 So relatable, I only used camelCase until I started writing ruby, the rule is snake case and I hated It. But It ended up being the thing I like the most
Yaml can have schema definitions, and almost anywhere you see Yaml used the project also has jinja or go templates. Of the markup languages, yaml is the most likely to have real logic running right next to it.
I legit don’t think I’ve ever shared a type. I’m still always using zod on both sides. This argument is also bs because node apis are different than the browser. Req/res, buffers vs array buffers, etc. A good use case for backend js is something like serverless functions with a runtime that uses browser apis. But this isn’t a replacement for a real server. Like okay I guess you could have a bun server since I think that does use browser apis. But bun will never actually catch on let’s be real
django man, just feels like home. I mostly write javascript but goddamn its so tempting to use django for everything that involves web enterprise apps.
I have worked on pure TS (in monorepo w/ shared packages) and mixed language projects this past year and I do find pure TS workflow less redundant and faster. However TS is only as strong as the weakest link -- can't have cheats like "any" and codebase must rigidly ensure that runtime type safety is assured (zod, valibot, etc) so there is 100% confidence that types are what they say they are, with verification at every boundary. Its best to think of TypeScript as a sophisticated linter for JS. Codebases where n00bs have littered it with type lies and cheats obliterate the advantage.
8:30 HTML is a markup language, CSS is a style sheet, Tailwind is a framework, SQL is a query language, prisma is an ORM, Vite is a bundler, Docker is a container, Vercel is a cloud hosting platform among other things. I get that you need multiple tools but the only programming languages in this list is Javascript and Typescript 😂
Maybe a bit of a hot take, but I don't think we should argue about what the industry standards should be based on how beginners will be able to handle it. The arguments that center around it being easier for beginners really implies to me that single language stacks are something that you grow out of. If that isn't the case then why aren't we telling people to move to a different backend? It is so clearly not about beginners imo.
8:29 7 languages? not every frontend is a web frontend and not e every web frontend has a Javascript framework - you can render your app in a canvas or years ago in an applet.
really love how you start by trying to understand the actual point behind their... points, instead of just basing everything off of your own. empathy is rare in robot world
I've been using HTML and CSS for 20+ years and have been exposed to JS and PHP quite a bit. Recently I embarked on the journey to learn more about programming. It was and is DAUNTING. I don't know how it's possible to find any joy in that unless you literally LIVE programming.
using Dart for mobile and web dev with Flutter ( no html , no css; just Dart ) , and Dart on server is IMHO a real joy, and can certainly be a productivity win for a solo developer or even a small team
Yep, dart is extremely underrated and has been for years. It's one of those languages that I use every chance I can. I do understand why the JavaScript community rejected dart when it first came out, after all it was backed by Google and they were trying to monopolize the internet (and they still are). If it was released by any other company or group, It would have been amazing had it been embedded in every browser as a JS alternative. I vehemently hate JavaScript and typescript is not much better.
If you're doing a crud app perhaps. Using a language created to do mobile apps to perform db operations on the backend is asking for problems later on and sometimes right away
Dart was originally designed as a language that runs in a dedicated VM. It wasn't designed for mobile, Flutter is just a framework they built for Dart to act as a GUI wrapper. Flutter for frontend is fine but not necessarily amazing beyond certain use cases. Dart on the backend is basically just newer/shinier C#. It was designed for it, it's the frontend where it was always sort of designed for but never found its footing and it took until Flutter for it to see any serious uptake
@@superderpyderps fair, but my point is, the tools designed to use Dart with (AKA Flutter) are more mature than the backend one's. And I say this as I worked In project where the tech lead was pushing to use Dart on mobile/backend (to handle same language in fron/back). This was 3 years ago. He was eventually fired and we ended building the backend with Java. There are tools/languages that are inherently better for backend for a bunch of reasons
In the startup and MVP world, Javascript is hard to contend against. One language can setup up your app, website and backend and infrastructure on AWS with tools like Amplify. You quickly update and add features and can have a lean team as you gain traction. As you grow then you can really understand how users are interacting with your software and optimize accordingly, instead of optimizing beforehand and making assumptions about unknowns. If you took this approach at a startup or when validating a market, you'd be optimizing in places you don't have to and costs would be higher for more devs when resources are precious. Once established then you obviously want to optimize and use the best language for the job.
I can't believe my bank is gatekeeping me from having unlimited credit at 0% APR. This is horrible!
8 หลายเดือนก่อน
0:20 ah... No one actually put any real world thought into this topic except a ideologically convinced human typed a prompt into a machine and got something that sort of makes a case for him without ever needing to understand the reality of it. Very based article..
A lot of great points in this video/article. However I feel i must add an exception to the conversation. I sometimes build videogames in my spare time. For one (web/canvas) game in particular I wanted to prevent client side cheating, but also keep lag/latency to a minimum. I ended up sharing the exact same POJO GameObject or whatever I called it on both client and server. I then ran the exact same game loop on both ends. The client was then able to run the game loop and defer to any updates sent down by the server. This actually ended up being wonderful for lots of reasons. If there were no updates for some period of time, the client loop would continue along happily, while simultaneously not being trusted at all.
The thing I've experienced is that a polyglot is perfectly fine as long as you are adhering to the boundaries. Our frontends are Angular / TypeScript and our backends are C#. I think the argument is more about having different languages within the same boundary. We aim to use the same language / tools for each backend. If we need to deviate from those tools for the backend the project had better have a really good reason as to why, and "because I like it" isn't a good reason. Otherwise, it makes sense. Have different languages for the different areas and try not to mix languages / tools within an area. It's a huge pain when one product is using Angular, React, jQuery, etc. all in the same product.
I think i get why people called it gate keeping, think about the situation like this: *"Real programmers"* | Fictional Gate | *"Not real programmers"* "You only know javascript, you can't pass to the *Real Programmers* side"! | Fictional Gate | "Awn Maan!" Obs: This is just an illustration of the thought process, that does not mean I think javascript developers aren't real programmers.
In my early programming days, I was complaining about the lack of basic features in a certain language and someone gave me some wise advice: "Use the right tool for the job, not every tool is meant for every job." Any good programmer should be capable of picking up most any language and figure it out rather quickly. This goes for tools and APIs as well. We as programmers need to be able to intuit how the system works beneath these abstractions. If you cannot do this, you are not a programmer yet. Be the master of your machine, not a slave to your tools.
@@thinkingcitizen I think all programmers should learn C and ASM sooner rather than later but I don't recommend either as a first language. Learning is easier when you can isolate concepts. Novices should start with a simpler language that has a low barrier to entry. Just getting a C program to build and understanding how to link, let alone dealing with unsafe pointers and such, is not a novice task. More progress will be made by biting off only as much as you can chew and the nuances of build processing is a distraction from the task of learning how to think like a programmer.
In one company we started to write services in Node so frontend people can join on the backend fun. In the end, only backend people touched them and were grumpy about it, do not recommend.
Man I find the twitch chat so funny. It's like watching a StackOverflow discussion in real time. Quite often devs are just highly opinionated, smart people who always think they're right and are often reluctant to change. I've been a dev for 15+ years. More often than not I assume I'm wrong or that other people certainly know better than me. I'm not for a second suggesting that we should hang off the words of anybody, in particular content creators, but to be so blankly dismissive of things you clearly haven't worked with will always be a bizarre trend in development imo
My biggest reason of not picking up multiple languages is just the fear of forgetting. The more you have to remember the more you have to google.. like I've gotten Javascripts syntax down pretty well. What it can, and can't do. Now say I pick up python or go . I'm going to slowly start forgetting the syntax, and pitfalls. I mean I've learned as a web dev that Google is inevitable. The complexity of program is from the just VAST amount of options. You could dedicate the rest of your life to the Javascript ecosystem, and never fully learn it all. Thank the lord we have stamdards. The amount of ways to make 1 thing is just CRAZY. I say pick up another language when performance becomes an issue, or maybe just to broaden your toolbelt? I guess lol.
Having same validation code on both sides is literally the only argument I've heard for having same language, and it's the one Prime mentioned too. Doesn't sound like a super critical thing worth ditching everything for and try to shoehorn JS everywhere
You know what kills productivity? Developers that write code with ONE FILE MENTALYTY , no code format , 0 separation of concern and DUPLICATE EVERYTHING. Have you code with people with that mentality?
I think IDLs should be used more commonly in projects. They can become easier to use (and if they were used more commonly that would happen naturally) but they easily solve the problem of wanting to share types between your languages by moving that to code gen. I think there are 3 good reasons to use a single language and they're even stronger reasons when you look at writing your entire backend in 1 language v. multiple. 1. You can share developers - freer movement of skills and expertise between teams, devs with very strong runtime knowledge of a langug 2. You can share libraries - multiple languages means you now need multiple versions of your circuit breaker or s3 facade library. 3. Tooling - Your static/dynamic code analysis tooling only needs to be built for 1 language.
8:32, dude, literally in the name: Hyper Text Markup *Language* 8:48, Doesn't make the statement the writer gave false, he said "languages", note "programming languages" **Edit:** lol, just noticed I types note instead of not. leaving it there because it's amusing XD
Article aside (good content!), thank you for that very concise explanation why you dislike the term Gatekeeping, sometimes you say shit that turns me off and getting your actual thought process with it often makes it more understandable or even agreeable
In the main codebase I work in pretty much all of the JSON we work with is validated at runtime using JSON schemas. It works well but something like protobuf frankly seems better for validating for type safety while a JSON schema can validate for structure.
By single language, do you mean write front-end, back-end, db etc, in Javascript ? Because it reminds me of this excerpt from the blog "Coding Horror": Atwood's Law is a humorous observation made by Jeff Atwood, a software developer and blogger, which states that "any application that can be written in JavaScript, will eventually be written in JavaScript."
As someone that’s actually built a production project using (reluctantly) full stack typescript, I can tell you all the mentioned arguments for the one lang stack here are wrong. It’s not at all about code reuse or even type safety (although I have been abusing trpc because I’m too lazy for anything else). For me anyway it boils down to context switching. I need to work on both the BE and FE. I know both technologies and have used them for years (regardless of languages). So for me it’s more important to not have to think about going from “array.map((v) => killMe(v))” to “[kill_me(v) for v in array]” (yes I’m aware there’s map in Python). Then there’s also tooling. I don’t have a build process for the BE but at least I can use the same tsconfig file and have the same linting on both sides. God forbid I’d have to deal with setting up tsconfig, vite, black, pyright/mypy, ruff, etc then have to update my version of node in the fe and update my versions of Python in the BE. Sure, I’m not 2x productive by using full stack Ts; sure my mental health has probably halved since using full stack Ts; but I am perhaps 2-5% faster. And in a tiny team (just me), that makes a difference. The idea of hiring FE devs to do BE or that I can only have type safety this way or even that I’d be reusing code was never part of the equation as those are all nonsense. My recommendation to anyone thinking about using Ts full stack: just use htmx and save yourself the trouble man, it’s not worth your sanity
If you have really solid validation on one end, you effectively have it on both. I have rust on the backend and as a result I know exactly what im getting from the server in my typescript code, and vice versa, if im sending something wrong from typescript, rust will let me know in no uncertain terms, in fact it will be so desperate to let me know, it will be in a panicked state.
After working professionally on servers in Java, PHP, Node, Python, Ruby, Rust - I can confidently say it's all the same. Whenever one language has some significant superiority, the others copy that functionality anyway (whether in a library or as part of the language)
The only significant factors are execution speed (Rust/Go with a clear advantage) and development speed (Python/Node with a clear advantage)
In 95% of scenarios, it doesn't really matter
yes but for scaling its better to use popular languages. Good luck scaling with haskell. Finding java, js, python devs are a dime a dozen
No Node Bun?
For the record we use JavaScript front and back. Approximately zero code is shared.
The actual reason is sharing developers. Not code.
Oh man, this is too good 😂❤
@@Macheako What am I missing?
Much easier to find a ton of JavaScript devs.
@@mattburgess5697 nah man lol I actually enjoyed that last sentence
Unless I'm missing something? lol
@@Macheako Nah it just read like you thought I was being a big dumb stupid. Just one of those things. Tone in text, etc.
"You're not authenticated. You need to suck it."
This should definitely be the detail returned in a 401 response.
epic response.
True
🤣
you are giving me stupid ideas :D
That will just make me horny when I see it.
I have a few hundred hours of watch time on this channel and the biggest takeaway I have is "any time people claim some technology is worse than x and y it's just a skill issue" and it really stuck with me.
Everything is a skill issue if you think about it...
As long as you remember that some skills are more useful or productive than others.
usually. Tank is just worse than swerve. somebody might get that. that somebody might disagree though.
people should spend more time creating awesome stuff and showcasing their work than bashing other people for their tool choice. except for javascript programmers, who totally suck. :)
@@pavlebnlife is?
I had a project where they installed Windows 10 IoT core just because of single language productivity just because the department where R&D team was situated was in the C# department of the buiilding - despite the project was an embedded project.
A whole team tried to work out how the hell to get the IoT core "properly" work (not just 256 colors, have network, etc), while I secretly gave the FULL task to two interns who coded the whole application in linux. They finished - not the prototype, but the app - in two weeks. Just imagine how much I had to explain what is being happening - especially that this task was supposed to take man-months :D
Brilliant 😂😂😂
@@DavidSchmitt Oh and missed to add, but from the context it was clear that the interns never even used embedded linux before - just knew this secret human skill called reading documentation :D
@@u9vata that IS a secret skill these days... ;-)
Maybe someone should have told the C# department that .NET became cross-platform a few years ago...I hope you weren't the project manager in this, otherwise you can also blame yourself.
@@Asto508 Plus information is that the reason they literally wanted to use C# is to "create the GUI" in either UWP or something they supposedly "know" (according to management(tm))
So it was management thinking like an excel table: "what is in it that this department already knows" - and this was heightened by them being some kind of MS gold partner and advisors advising this IoT core bullshit to them haha. They literally couln't make the OS at all to work, the libraries in that environment literally did not work (at least not at the time) and just booting windows took like 120% of the resources of the little machine.
All this for a "GUI" that literally had 2-3 buttons, some thing and a single screen... It was for a logistics appliance / equipment.
I say that I only use c++ because it makes me feel bigger brained than everyone, but it's really because I was traumatized learning it as my first language and don't want to learn others as a result.
no other language is as convoluted and messy as C++, rest assured, anything you learn afterwards will be easier than C++ (with the exception of maybe learning haskell and some other vastly different language from ur standard C like language)
i suggest you trying out python then, i actually used python yesterday to convert images into uint16_t C arrays for display ... after C++ using python will be such a joyful experience
@@FlanPoirot Apart from Rust. :)
C was one of my early languages, not my first, that would be Basic. But moved from C to C++, then from C++ to Pascal, and lots of others. What I can tell you things get easier when learning a new language, and I would argue becomes fun learning a new one. All the skills you have learned in C++ should easily transfer to most other languages, apart from Rust. :)
@@keithjohnson6510 rust is fairly easy, it had saner defaults than C++, u don't have to fight the language to get good behavior out of RAII and the language doesn't make expensive copies behind ur back
rust only becomes "hard" if you try to write certain types of programs in safe mode when it should just be unsafe. the only people that think that rust is "hard" are people that tried it for 10 minutes,got annoyed at the borrow checker and left.
Rust is more annoying to write cause the borrow checker is constantly in odds with u but other than that the language isn't really "hard".
of course u might not always want Rust or might just not like it, which is ok. U can use something else, no one is forcing u to use rust
Oh man, the comment "How different is Go from JavaScript" lmao. At my previous employer, they absolutely refused to take my solution written in Python because no one on the Dev team knew Python (I was in QA). I spent two of my weekends rewriting it in C# with Thread primitives (because I had never written C# before, so I was winging it as best I could) and they still rejected it because they didn't have anyone qualified to QA my work. Suffice to say that I'm still salty about it to this day .
At current employer, someone wrote a bulletproof web service in Go, and no one at the company writes Go anymore. Incidentally, I'm learning Go (after your frequent praise of it), and the engineer who was tasked with patching it recently said it was easy to learn and he doesn't get the fuss.
Some people are just stubborn and unwilling to change.
inb4 "Neither of them is C; therefore they're identical."
That’s actually pretty valid. If no one knows Python , it is more expensive for the company.
As programmers we generally don’t think about things like finance & availability of dev, but those are equally important too.
When I started my company and less than < 25 people, I had strict rules:
All in backend in Python, all infra in go, anything needs safety is Java and anything needs performance is C. FE is either jQuery (if tightly coupled with BE) or Ember. Mobile: all native - Swift and Kotlin
@@train_xcdude, that's almost one tech stack per person :D
@@Qrzychu92 we were two people doing everything for 2 years. I didn’t code in Java, C and Kotlin. My cofounder did.
I took care of BE, FE, Infra & iOS app. My co-founder took care of Security, Performance & Android apps. These are the only things we knew, and didn’t have the time to learn anything else .
People need to stop obsessing over what they learned in a bootcamp
based
People should stop thinking they're ready to work as developers just by taking bootcamps and not having a degree
@@BrunoCodeman "
why don't you know formal logic yet dammit?! how the FUCK are you gonna be a FUCKING web dev without knowing formal logic?! Go pick up a logic textbook you shameful excuse for a frontend dev!!!!"
- An unemployed CS grad
"And NOT only that...WHERE is your calculus knowledge? You need THREE courses of calculus to even THINK actually WRITING javascript. You're supposed to just LOOK at javascript, and prove it using formally methods, ya DUNCE! Not actually write it!"
"Where on GODS. GREEN. EARTH. Is your knowledge of fucking CHEMISTRY, BIOLOGY, PHYSICS?! You need AT LEAST ONE! DO you even know the simple difference between MOLES and GRAMS?? Programmers will NEED this in industry!"
"Where is your philosophy knowledge?!! Plato? Socrates? Ring a bell??!"
"Your LITERARY STUDIES?! HMMM??"
"Do you even know if finite automata are turing complete???"
"Feminism and french literature?! Bah. You wouldn't understand a WORD in that course!"
@@BrunoCodeman It REALLY depends 😂. I went to a bootcamp/trade school which taught C VERY heavily, and I mean HEAVY. Rewrote common libs, wrote printf, wrote a small kernal, DB, etc. It depends on where you go and what you learn, but i doubt any camp teaching javascript only, actually produces competent engineers. Thats just web dev and barely even that
@@BrunoCodeman never been to a bootcamp nor have a degree and I make 85k 🙂
"Deployment -- figuring out shouldnt' cost you any more than a day" In my experience the people who say this are those who commit AWS keys into git and get their AWS account immediately hacked.
he did qualify it with (something like) "if you've done it before"
What's the alternative? I know, spending a month creating deployment pipeline in Jenkins.
I feel like in my experience, people who say that don't work at companies that disallow you from making AWS secrets manager keys...
@@nemanjatrivic9505if it was ever that easy I’d be out of a job 😂
@@nemanjatrivic9505 github actions, gitlab CI/CD or similar is just fine. One nice trick is make a runner in AWS (EC2 instance, EKS pod, whatever), use instance roles instead of IAM user. Now you're not exposing credentials directly. Downside you must harden the runner.
Gatekeeping is when you're an active 42 year old and the surgeon is reluctant to fix your shoulder because "these injuries are part of the natural ageing process"
"you are not an athlete" -Louis CK
Deck the dude and then tell him it's a natural part of the growing process. Now he'll know not to be such an asshole.
Hi Prime, Thanks for all the info you put on your channel. Even though I am not a dev, I have learned a lot about the industry and how things work at a nuts and bolts level.
I managed to clean up my kitchen and Primegen didn't even get past the title of that article.
this will be the top comment
china #1
@@ThePrimeTimeagen i am the china
Yes
Bing chilling
Let's go!
I like your pep talk on feelings. Something everyone tries to work on and fix in high school. Just a good skill for everyone to have.
There is no getting around the fact that querying a relational database is a fundamentally different thing than just about everything that doesn't involve the DB. One language isn't enough if you care at all about getting the best performance out of your system.
Relational Algebra really is very different than any Type System (most type systems are based on Set Theory) or Imperative/OO programming language.
This is nonsense. All we are doing is reading from and writing to memory. So long as a program can do that than you can optimize performance by doing just what you need in a way the computer can do the fastest it can. All languages just give varying degrees of control and boiler plate to do that.
@@thelaw3536 in real life, what you claimed is nonsense. It's a completely different paradigm; the language is irrelevant.
C in the front, Elm in the back and TOML to query my DB made of barrels of salty water
@@adambickford8720 its like "technically correct" but in a "you should just write every program in asm" kind of way
WASM (and Blazor in particular) has allowed me to use C# on both the server and client-side. I've been very happy with it. I have a hate relationship with javascript. Yeah, I said it. Not love/hate, just hate. I'm old school and hate web development in general, but it refuses to die as we continue to twist and bastardize HTTP/S to do things it was never meant to do. From a business standpoint though? It's so damn convenient to have access to everybody with a browser and internet connection (see: everybody on the planet). My shared library I use for both server and client-side just works right out of the box. It continues to grow, and this is just my first go at it. As a game running server-side, I don't need (or want) my server-side logic on the client, but if I did, there's no reason it wouldn't work. As much as I hate MS, their .NET team has done an amazing job bringing C# / .NET into the browser. Nearly everything I know about .NET and C# just works, in both paradigms.
I also hate JS. You are not alone.
javascript was a mistake
Blazor and more importantly webassembly are awesome.
I did a side job with a web server, shared api, and mobile app (Xamarin) all in C#…
And I’d do it again! 😂❤
It sucks when I need the best UI library for something, and it's available just for React. I had to ditch using vue for the project because the React DndKit library was the best available. I never did a project this large, and just setting up the library was a pain, I'm learning React and Typescript and all of that front-end package mess.
I never had such complexity with setting up my dev environment with python, surely, I get packages not being compatible with each other sometimes for things like Automatic1111 which I have to deal with even though I'm not even developing, I'm just using the thing as a user. (For generating images with Stable Diffusion).
He never said “programming language”, he just said “language”
Yes. HTML is a language even if it isn't a programming language. English is another language not mentioned in the video. Prime also kept interchanging "language" with "programming language" incorrectly as if he forgot about every other type of language. That said, config files and libraries are not languages of any kind. The single language article author should have said "technologies" or something sufficiently broad if he wanted to list non-languages like config files.
@@IARRCSim Yeah i'm just mostly coming to the defense of HTML and YAML, etc. YAML may be simple, but if you want to fully understand what you're writing, you still have to Read the Friendly Manual or some kind of thing to learn it.
Brazil mentioned?
Bonjour, monsiuer.
The day I learned that I don't speak any languages, I only write in them... And all these years I have been thinking I speaking the languages Danish, English, few words of German and French just to find out they are not languages at all... Man what a let down :(.
The fact that no one is mentioning PHP is hilarious.
Laravel is quite possibly the best web tool ever made, sadly it's built for the worst web language ever to grace the corporate world
If PHP is bad, then you haven't seen shit, it's one of the better languages out there and you're probably just malding because you hate its syntax @@BusinessWolf1
@@BusinessWolf1Bang for buck in terms of ecosystem Laravel is hard to beat. I don’t do it anymore, but I built my career on PHP.
@@BusinessWolf1 language which quickly becomes a good language actually
When Prime said "people don't think of PHP as where great things happen," I lol'd.
i hate programming
What are you doing here ?
@@azhar_waheed hating
You mean you hate JS
me too man
WE* hate programming
I enjoy listening to conversations about strong typing versus dynamic typing in e.g. web dev. It makes me appreciate Common Lisp so much.
I love that the guy was "subtly" shilling C#. Linq is one of the greatest inventions known to men.
Linq is sort of meh when you think of all the Datalog eDSLs.
@@vitalyl1327 I mean sure, I'll concede that, I've never written Datalog. I'm not sure what to think of Datalog as a backend, I'd need to try it to see if it works. The fact it requires a DSL is still a step down. If I wanted that, I'd say C# extensions are the greatest (essentially adding static methods to the class definitions at any point), but I mentioned Linq, which is built on top of said extensions. The reason why is simply that Linq gives you the benefits of extensions without the drawbacks of writing them and footgunning yourself like you will inevitably do. It also doesn't require any external code.
System.Linq is pretty intuitive, even as someone whose only experience w/ C# is Unity development.
@@IndigoTeddy I started C# with winform and stuff like that, but I really got into it due to Unity development.
.Net sucks though
about the orm argument, I generally just use orms to setup the db connection and then rawdog sql most of the time. The reason for that is simply: orms generally maintain the schma/anatomy of the db,tables etc. I just don't want to care about that and let the orm do that stuff.
The gate is "you are gatekeeping me from feeling good about myself"
2:53 protobuf and similar language-agnostic type definitions are way underappreciated and underutilised. Every project I've suggested starting with something like that might be a good idea has been shut down as unnecessary... and then in production there are constant bugs being patched with code to check the validity of the data both front end and back end
productivity is not the reason, cutting cost is, my flutter devs can do everything from the backend to the frontend to whatever. That's why I used flutter for my previous startup. Productivity plays a role, for instance, my flutter devs couldn't edit nodejs cloud functions and I'm not going to hire nodejs devs just to maintain few functions. But it's a cost game not a productivity game.
At the end of the day, management pays the bills and salaries, so everything comes down to cost, no one cares about productivity, productivity is nice if it decreases the cost but it's not the main concern whenever we choose a language. I picked flutter back in 2018, when ti was in beta stages and I didn't know anything about it, all I know is it can publish web and apps, I needed both and couldn't afford to hire many devs.
If you want to do it all as a solo developer in a short time frame, yes single language increases your productivity but the quality and performance suffers. That being said productivity is a corporate measure, where there are teams dedicated to each section, so the single language doesn’t really matter. If you’re not a corporation, productivity should be lower on your list of concerns. Quality should be your main concern, that’s where you will beat out the corporations.
i think the question here what is "short time frame" sometimes u see ppl overstaying their welcome in one language.
i think for me when someone can make any professional project its time to move from language focus to project focus.
I learn of so many new programing concepts that I have to search up what they are, why they are useful, and how to use them because I feel like I am just a script kiddie when I listen to Prime's videos.
Spicy take: I regret ever going anywhere near the JavaScript / TypeScript ecosystem. Should have just gone with Go, while learning Rust (when finer control is required)
Heck. I think Python would have been a better investment because of all the AI trends. Also not learning C sooner was a dumb move on my part.
If you work with Requests and Responses in the front end...it does translate to working with Requests and Responses on the backend....
Yesss 418! I'm a Teapot!
The "sir, this is a Wendy's" of server responses
5:22 Sometimes it takes me more time than it should to realize that I've been blessed to have a professor that teaches me programming at university and is close to the real world (and is also one of the world's leading experts in parallelization)
It's funny that he doesn't remember 401 but remembers 418
I mean, I'll remember 418 for the rest of my life 😂😂😂😂😂
Type safety, single language productivity, and languages like Python with authoritarian tabbing requirements are all just copes for not being a better programmer. You don't need all these fancy things that greatly restrict you in an attempt to reduce errors if you just don't make errors. If you routinely write code that's too hard for you to debug, you need to write less complex code, you don't need to switch to a less powerful language that does more hand-holding.
what is that all and mighty powerful language? Haskel? C++? C?
@@enkvadrat_ Things like C and PHP are pretty good. Never tried Haskell.
@11:00 this is why everyone says frontend web developers aren't real programmers.
It's about what they don't know that they don't know.*
*Usually any elementary computer science at all or that HTML isn't programming
I have my big brain discovery, nobody actually speaks a 100% of their language, and neither should be exected from programming languages.
Data Scientist on the edge
Edge the data scientist
how long can the data-scientist (be on the) edge ?
@@MkrabsDepends on if he's caged or not
@@Mkrabs maybe edge computing
@@TheOriginalBlueKirbybruh. Y’all unhinged 🦫🦫🦫🥵🥵🥵
Towards the end, this reminds me so much of all the discussions I've had about what "gaslighting" means.
Middleware is the Request’s therapist helping it get its shit together
23:57 but muh OrderByDescending , that's a weird take as the only difference is whether or not you bother to have an OrderByDescending function added to the array prototype, it's just a wrapper for a sort in most languages.
And both are NOT onelines for legibility on purpose, and in deployment both can still become one line when shipped, if not outright minified.
My favorite part of your videos are the inevitable moment when you get an alert and you proceed to say I forgot to turn off alerts lol. I think it happens in every single one of your videos.
Yup and Zod are very useful in vanilla JS, as they are runtime "type safety". However, after some thought, it turns out that Zod and Yup can provide features that are impossible in compile time type safety.
When interacting with an unknown API, where it is unreliable, sometimes it may have proper types and sometimes not.
Compile time types are indispensible and extremely important due to the efficiency they bring, but they cant cover all scenarios.
Another case that Yup would cover that static types don't is with input coercions. If your data is invalid, you just get an error and it stops. With Yup, you can force it to be valid, but just log the errors without crashing.
All in all, it is better to have both rather than just one.
From my experience the closer you can get to one, the better. Only extending when it makes sense
At the very least don’t be out here chasing the next big tech, and adding languages to the list JUST cuz some new API is Shinier than yours 😂❤
Some guys legit just get bored with being able to do their job in an appropriate amount of time 😂
Saying that javascript is bad for the backend is not gatekeeping. It's telling the truth
Even if it's gate keeping it's good. Don't want JS only devs anywhere near backend
people use ruby on the backend, they will be ok with JS
I am working on a client project which is in js backend. 😂😂 It's billion dollar company.
Js sucks
saying that it's not a "real" language or that it's not for backend is the gatekeeping part. It can be as bad as you want it to be, it's still a real language, and can be used for the backend.
@@jakobhetland4083 Having an opinion or saying something (especially when it's a fact hehe) is not gatekeeping, because it is not "trying to control who gets particular resources, power or opportunities and who does not"(Cambridge dictionary). Stating an opinion by anyone is not gatekeeping unless acted on. If a boss would fire someone because they believe that js is good for a server that would be gatekeeping. If a person would harass others because of their opinion that would be gatekeeping.
I reckon Primeagen could do a pretty good Jack Nicholson impression if he gave it a go.
Edit - Middleware is between request and response
That hot take around 30 mins where you say “if someone says JavaScript isn’t a real language and you get so discouraged you stop programming maybe you should stop programming” is my favorite thing you’ve ever said. I use js practically every day. But opinions can’t hurt you! ❤ sticks and stones man
The gatekeeping conversation was really bad to witness. Prime example of how it is absolutely impossible to have meaningful conversation between one person and a thousand monkeys on typewriters.
The conversation STARTED because Primeagen disagreed with the author that he said Javascript was not a real language, saying the author should've said something along the lines of "a language designed for the backend" or something like that.
People in chat "probably" (I can't assume I know what they were thinking, ofc, but am steelmanning their position) said it was bad gatekeeping in this case because the author apparently created a gate beyond which all "real" programming languages are, and JS is out of this gate, so the author is gatekeeping the status of "real" programming language to javascript. I'm sure that Primeagen agrees this is a stupid take, and there is no real way to logically defend this position. JS is a programming language whether we like it or not.
Is the gate between "real" programming languages and "not real" a good gate to keep? Well, sure. Just like thePrimeagen at the beginning talking about YAML, and however many conversations we can have about HTML, and the argument on turing completeness etc., but never in a million years no one will seriously say Powerpoint is a programming language.
But JS is a programming language by any (reasonable, imo) measure.
But then of course, people got rustled because if all they know is JS and someone is out there saying JS is not a "real" programming language, then they might feel like the person is saying they are not "real" programmers.
All of which does not bare in the whole conversation. The whole discussion of what is gatekeeping, what is the gate, how is it being kept, prime talking about the person feeling welcomed or giving up programming, most of what I saw in chat... ALL OF IT was people talking past eachother.
The author, by saying JS is not a "real" programming language, created a gate and kept JS out of it.
ThePrimeagen had his take that the author shouldn't have used the wording he did.
Chat said that what the author did was gatekeeping.
It APPEARS thePrimeagen saw the comments about gatekeeping and thought it was about the separation between back and front end that was being kept, and argued from that position. "saying other programming languages are better for the backend is not gatekeeping".
Chaos ensued and no-one learned nothing.
Also wanna share some of my experiences here. I'm (still) a mobile dev with a focus on android for now. My career began at a small outstuff company with Android and Kotlin, with some background experience (python and cpp). I knew that I wanted to stick with android for a while, but the CEO and my mentor wanted me to learn swift and ios after 1 year I spent with kotlin/java. Their offer was "get laid off or learn this shit", so I as a poor student started to learn a new platform and language. About half a year later I was again dragged to learn flutter for new projects. My salary was the same all this time, but I had no choice at the moment because dropping only money income is risky. This was a nightmare, I switched context so often that I couldn't get good at least with one technology. It may be the same mobile development, but to really understand a technology you need to work with it for a while. It is good to have a broad range of skills, but 1) don't start a new technology at the beginning of your career and 2) use technologies you like or you (eventually) get paid for
21:31 Yes, of course you can do N+1 with LINQ, or you can throw an exception at the orm level every time someone does N+1. Then all N+1 will be explicitly specified by you in the code. In js you'll have to run the request and look at the generated code to find out. So there is a difference in the feedback loop with the ORM: c# - when you type, js - in production. (I haven’t written C# for more than 8 years, today probably C# servers are generated with chatgpt, so no one cares about N+1)
30:38 and this is why i still use nano. I have been given a lot of crap for using it (yes yes yes, it mangles long lines. I get it), but the longer I've been in the field, and have become Senior in my role, it's just another tool. Sure, vim is "neckbeard approved," but when you come to me asking me why your terraform sucks ass, you'll see nano and like it.
Jesus Christ you're evil. I would grudgingly respect the dedication if I saw this at my job.
This article takes me back to some other topic you covered. You are most productive in the language you are most comfortable with. There may be a language that solves your specific problem perfectly, but if it takes you forever to understand it, you could spend that time being productive in your comfort zone and then revisit the idea when it's not critical for delivery.
That said, I've had to change the language I use at each new job, so I am uniquely familiar with picking the "right" language for the job, and feel comfortable switching. That said, I don't fault someone for being a "one-trick [language] pony". I have seen experts do crazy things in their language of choice, while I'm usually writing bog-standard code that is as-intended.
Uhhh... Isn't the argument for single language related to the cost of hiring and ease of integration? If anything it means companies don't have to hire two developer to do front end and backend and even if you do have such teams, they have a common language/understanding and therefore no compatibility issues. I.e. Javascript object is a javascript object.
I don't understand what the Protobuf argument has to do with anything. You still need to define and redefine types, and maintain those definitions between your applications. That gets more and more unwieldy as the application grows, without exception.
Also, obviously, codegen tools exist that can ease the difficulty of this process, but that's yet another layer of complexity you're adding to your stack that you may or may not need to maintain.
The language libraries, ecosystem, and community support matter more than familiar syntax.
Syntax is the least important factor when building anything. Matching the needs of the problem being solved is everything.
Libraries and ecosystem only matter to the glue "programmers" who just bolt libraries together. They are not needed anyway and will be replaced with stochastic parrots. Real engineers care much less about any third party libraries and frameworks.
@@vitalyl1327Quick, build Vulkan from scratch!
@@vitalyl1327That’s not true, mostly everyone needs to interface with middleware, OS, or hardware. And redoing commodity code isn’t something “real programmers” do, it’s a waste of time.
If you are a game engine dev, you are going to use DirectX or Vulkan and shader languages. That’s usually C++.
If you are an AI developer, you are probably going to use a mix of Python, C++, and cuda.
If you are an iOS developer, you may be using Swift.
The problem being solved and support needed is what matters.
People that reuse high quality components and pick the best tools for the problem are “real developers”
Lots of languages support calling other libraries that weren’t authored in that language, but sometimes the shim code is more work and more problematic than using one of the natural languages the rest of the community uses to solve that problem.
@@vitalyl1327 outside of lib languages have domain that they shine in because they view the world differently which let them be better at type of project.
c is better for system programming because of it simplicity, C++/rust give u more complexity and reward u with features which make large lib ecosystem easier to make, etc... i think one should focus on trying to see what language fit the project rather then the opposite.
there a lot of stuff in C++ that is really just rewritten ur own core stuff and extend that by using 3rd big lib that can solve almost anything, u can find almost anything under the sun, i don't think it say much about u being real engineer or not but rather what world view fit better the project.
for example C++ is clear winning for robotic and games
@@vitalyl1327 Real engineers also seldom do common full stack projects. What's your point?
I hate half-assed stuff. Either the same SAME, or totally different. "The same but a few differences here and there" is the worst.
People talk about "mental context switching", if you works for both FE and BE, context switch is inevitable. And if i gonna switch anyway, i want them to be completely different
"JS on the browser" vs "JS in Node". Juggl your mind between those subtle differences is a much worse experience than have something completely different.
When I see PHP or Java, my mind immediately switch to "backend mode", when I see JS/ TS my mind immediately switch to "frontend mode". That the experience I want
I don't think that protobuffs are going to be able to make it so that when I remove a property from an object type in my backend code I will instantly be able to see what bugs it will cause in my frontend. I'm assuming I would have to manually export the definitions from my backend repo and then manually trigger code generation for the corresponding typescript interfaces. Setting all this up is not trivial either.
That is a failure of your process. You do not update one system without updating the other - meaning you check to see your proto files agree before deploying anything. Ever.
@@kevinb1594 I think you are missing the point. With full stack typescript i get instant feedback in my editor. I don't have to make any PRs, I don't have to run any commands, I type something and in about 2-3 seconds the ts compiler running in the background in watch mode draws squigly lines under all the places affected by my change.
@@kaanatakan Ok? Those aren't exactly the same issue. Protobuf ensure the contract between your backend/microservices/apis are in alignment. Has nothing to do with linting. Assuming your backend is the source of truth, you removing that property IS the correct, updated contractual change.
ive been using gamemaker for my frontend and nodejs for my backend for a video game ive been developing for a while and it is nice because they are different languages with different strengths, but are gml is really just javascript even with the same syntax so the communication goes very smoothly, and can integrate lots of middleware to my game
HTML is a language, but is not a programming language
It's a markup language, it's literally in the name. Hypertext markup language.
HTML is a programming language, it's 2024 let it go already
htmx called said ur mom's not a programming language
@@dforj9212 Markdown is a programming language, it's 2024 let it go already
It's a programming language, a domain specific programming language, not a general purpose one tho, no need to trust me on that, just open the blink source code of Chromium and search for the grammar parser for both CSS and HTML in there, there's a tokenizer and parser for both.
HTML is parsed and outputs to a DOM tree, and CSS becomes the CSSOM which both are used by the browser, they were implemented using... yeah, that's right, compiler theory.
See HTMLTokenizer.cpp and CSSTokenizer.cpp for a start.
Protobuf, msgpack are not workarounds. But it is indeed a new significant component to your system. When you start a small project, you probably would like to have it in 1 language, with less hustle. When the project grows and matures, you’ll need to encode your protocols - that’s where the protobuf comes in.
after moving to protobufs with basic validation built into the message definitions themselves with protovalidate i cant image going back to loosey goosey JSON for the wire format
the energy in the first 5 minutes of this video is so tense I hate it. Because it reminds me of the circles I go in my mind when I think about things at work that annoy me, and I know it's unhealthy.
Womp womp womp
20:00 So relatable, I only used camelCase until I started writing ruby, the rule is snake case and I hated It. But It ended up being the thing I like the most
Yaml can have schema definitions, and almost anywhere you see Yaml used the project also has jinja or go templates. Of the markup languages, yaml is the most likely to have real logic running right next to it.
I legit don’t think I’ve ever shared a type. I’m still always using zod on both sides.
This argument is also bs because node apis are different than the browser. Req/res, buffers vs array buffers, etc.
A good use case for backend js is something like serverless functions with a runtime that uses browser apis. But this isn’t a replacement for a real server.
Like okay I guess you could have a bun server since I think that does use browser apis. But bun will never actually catch on let’s be real
You're using totally separate zod structs for the same data?!?!
django man, just feels like home. I mostly write javascript but goddamn its so tempting to use django for everything that involves web enterprise apps.
I have worked on pure TS (in monorepo w/ shared packages) and mixed language projects this past year and I do find pure TS workflow less redundant and faster. However TS is only as strong as the weakest link -- can't have cheats like "any" and codebase must rigidly ensure that runtime type safety is assured (zod, valibot, etc) so there is 100% confidence that types are what they say they are, with verification at every boundary. Its best to think of TypeScript as a sophisticated linter for JS. Codebases where n00bs have littered it with type lies and cheats obliterate the advantage.
8:30 HTML is a markup language, CSS is a style sheet, Tailwind is a framework, SQL is a query language, prisma is an ORM, Vite is a bundler, Docker is a container, Vercel is a cloud hosting platform among other things. I get that you need multiple tools but the only programming languages in this list is Javascript and Typescript 😂
there was not "programming" in the text refering to the languages, all of those are in a way languages, just not everyone is a programming language.
Or just use languages with javascript transpilers like clojure.
Idk why transpiling is always ignored when its alot better than javascript supersets.
Maybe a bit of a hot take, but I don't think we should argue about what the industry standards should be based on how beginners will be able to handle it. The arguments that center around it being easier for beginners really implies to me that single language stacks are something that you grow out of. If that isn't the case then why aren't we telling people to move to a different backend? It is so clearly not about beginners imo.
8:29 7 languages? not every frontend is a web frontend and not e every web frontend has a Javascript framework - you can render your app in a canvas or years ago in an applet.
really love how you start by trying to understand the actual point behind their... points, instead of just basing everything off of your own. empathy is rare in robot world
I've been using HTML and CSS for 20+ years and have been exposed to JS and PHP quite a bit. Recently I embarked on the journey to learn more about programming. It was and is DAUNTING. I don't know how it's possible to find any joy in that unless you literally LIVE programming.
using Dart for mobile and web dev with Flutter ( no html , no css; just Dart ) , and Dart on server is IMHO a real joy, and can certainly be a productivity win for a solo developer or even a small team
Flutter is so nice. I hate html and css and JavaScript
Yep, dart is extremely underrated and has been for years. It's one of those languages that I use every chance I can. I do understand why the JavaScript community rejected dart when it first came out, after all it was backed by Google and they were trying to monopolize the internet (and they still are). If it was released by any other company or group, It would have been amazing had it been embedded in every browser as a JS alternative. I vehemently hate JavaScript and typescript is not much better.
If you're doing a crud app perhaps. Using a language created to do mobile apps to perform db operations on the backend is asking for problems later on and sometimes right away
Dart was originally designed as a language that runs in a dedicated VM. It wasn't designed for mobile, Flutter is just a framework they built for Dart to act as a GUI wrapper. Flutter for frontend is fine but not necessarily amazing beyond certain use cases. Dart on the backend is basically just newer/shinier C#. It was designed for it, it's the frontend where it was always sort of designed for but never found its footing and it took until Flutter for it to see any serious uptake
@@superderpyderps fair, but my point is, the tools designed to use Dart with (AKA Flutter) are more mature than the backend one's. And I say this as I worked In project where the tech lead was pushing to use Dart on mobile/backend (to handle same language in fron/back). This was 3 years ago. He was eventually fired and we ended building the backend with Java. There are tools/languages that are inherently better for backend for a bunch of reasons
In the startup and MVP world, Javascript is hard to contend against. One language can setup up your app, website and backend and infrastructure on AWS with tools like Amplify. You quickly update and add features and can have a lean team as you gain traction. As you grow then you can really understand how users are interacting with your software and optimize accordingly, instead of optimizing beforehand and making assumptions about unknowns. If you took this approach at a startup or when validating a market, you'd be optimizing in places you don't have to and costs would be higher for more devs when resources are precious. Once established then you obviously want to optimize and use the best language for the job.
I can't believe my bank is gatekeeping me from having unlimited credit at 0% APR. This is horrible!
0:20 ah... No one actually put any real world thought into this topic except a ideologically convinced human typed a prompt into a machine and got something that sort of makes a case for him without ever needing to understand the reality of it.
Very based article..
11:20 J2EE was able to create n-tier servers and all the tiers communicated over Java server beans and Java message beans ,dude.
A lot of great points in this video/article. However I feel i must add an exception to the conversation. I sometimes build videogames in my spare time. For one (web/canvas) game in particular I wanted to prevent client side cheating, but also keep lag/latency to a minimum. I ended up sharing the exact same POJO GameObject or whatever I called it on both client and server. I then ran the exact same game loop on both ends. The client was then able to run the game loop and defer to any updates sent down by the server. This actually ended up being wonderful for lots of reasons. If there were no updates for some period of time, the client loop would continue along happily, while simultaneously not being trusted at all.
The thing I've experienced is that a polyglot is perfectly fine as long as you are adhering to the boundaries. Our frontends are Angular / TypeScript and our backends are C#. I think the argument is more about having different languages within the same boundary. We aim to use the same language / tools for each backend. If we need to deviate from those tools for the backend the project had better have a really good reason as to why, and "because I like it" isn't a good reason. Otherwise, it makes sense. Have different languages for the different areas and try not to mix languages / tools within an area. It's a huge pain when one product is using Angular, React, jQuery, etc. all in the same product.
I think i get why people called it gate keeping, think about the situation like this:
*"Real programmers"* | Fictional Gate | *"Not real programmers"*
"You only know javascript, you can't pass to the *Real Programmers* side"! | Fictional Gate | "Awn Maan!"
Obs: This is just an illustration of the thought process, that does not mean I think javascript developers aren't real programmers.
In my early programming days, I was complaining about the lack of basic features in a certain language and someone gave me some wise advice: "Use the right tool for the job, not every tool is meant for every job."
Any good programmer should be capable of picking up most any language and figure it out rather quickly. This goes for tools and APIs as well. We as programmers need to be able to intuit how the system works beneath these abstractions. If you cannot do this, you are not a programmer yet. Be the master of your machine, not a slave to your tools.
Just learn C first and then the rest fall into place
@@thinkingcitizen I think all programmers should learn C and ASM sooner rather than later but I don't recommend either as a first language. Learning is easier when you can isolate concepts. Novices should start with a simpler language that has a low barrier to entry. Just getting a C program to build and understanding how to link, let alone dealing with unsafe pointers and such, is not a novice task. More progress will be made by biting off only as much as you can chew and the nuances of build processing is a distraction from the task of learning how to think like a programmer.
When they made the expression "If all you have is a hammer everything looks like a nail" they never met a javascript developer
man, prime really can't read that well lol. at 7:52 mark the writer said "languages" in air quotes
In one company we started to write services in Node so frontend people can join on the backend fun. In the end, only backend people touched them and were grumpy about it, do not recommend.
Man I find the twitch chat so funny. It's like watching a StackOverflow discussion in real time. Quite often devs are just highly opinionated, smart people who always think they're right and are often reluctant to change. I've been a dev for 15+ years. More often than not I assume I'm wrong or that other people certainly know better than me. I'm not for a second suggesting that we should hang off the words of anybody, in particular content creators, but to be so blankly dismissive of things you clearly haven't worked with will always be a bizarre trend in development imo
My biggest reason of not picking up multiple languages is just the fear of forgetting. The more you have to remember the more you have to google.. like I've gotten Javascripts syntax down pretty well. What it can, and can't do. Now say I pick up python or go . I'm going to slowly start forgetting the syntax, and pitfalls. I mean I've learned as a web dev that Google is inevitable. The complexity of program is from the just VAST amount of options. You could dedicate the rest of your life to the Javascript ecosystem, and never fully learn it all. Thank the lord we have stamdards. The amount of ways to make 1 thing is just CRAZY. I say pick up another language when performance becomes an issue, or maybe just to broaden your toolbelt? I guess lol.
Having same validation code on both sides is literally the only argument I've heard for having same language, and it's the one Prime mentioned too. Doesn't sound like a super critical thing worth ditching everything for and try to shoehorn JS everywhere
Some projects exist to let you write validation rules that are agnostic to the language, like protovalidate.
Regex validation ftw…
No problems there!
You know what kills productivity? Developers that write code with ONE FILE MENTALYTY , no code format , 0 separation of concern and DUPLICATE EVERYTHING. Have you code with people with that mentality?
32:48 "Stop gatekeeping their gatekeeping"
That made me laugh more that it should.
I think IDLs should be used more commonly in projects. They can become easier to use (and if they were used more commonly that would happen naturally) but they easily solve the problem of wanting to share types between your languages by moving that to code gen.
I think there are 3 good reasons to use a single language and they're even stronger reasons when you look at writing your entire backend in 1 language v. multiple.
1. You can share developers - freer movement of skills and expertise between teams, devs with very strong runtime knowledge of a langug
2. You can share libraries - multiple languages means you now need multiple versions of your circuit breaker or s3 facade library.
3. Tooling - Your static/dynamic code analysis tooling only needs to be built for 1 language.
8:32, dude, literally in the name: Hyper Text Markup *Language*
8:48, Doesn't make the statement the writer gave false, he said "languages", note "programming languages"
**Edit:** lol, just noticed I types note instead of not. leaving it there because it's amusing XD
Noted
29:50 I would like to point out that prime went on this rant about gatekeeping because someone in his chat made a joke lol
what's real funny is to this day prime still doesn't understand what gatekeeping is but still tries to tell everyone else they're wrong
Article aside (good content!), thank you for that very concise explanation why you dislike the term Gatekeeping, sometimes you say shit that turns me off and getting your actual thought process with it often makes it more understandable or even agreeable
In the main codebase I work in pretty much all of the JSON we work with is validated at runtime using JSON schemas. It works well but something like protobuf frankly seems better for validating for type safety while a JSON schema can validate for structure.
By single language, do you mean write front-end, back-end, db etc, in Javascript ? Because it reminds me of this excerpt from the blog "Coding Horror": Atwood's Law is a humorous observation made by Jeff Atwood, a software developer and blogger, which states that "any application that can be written in JavaScript, will eventually be written in JavaScript."
As someone that’s actually built a production project using (reluctantly) full stack typescript, I can tell you all the mentioned arguments for the one lang stack here are wrong. It’s not at all about code reuse or even type safety (although I have been abusing trpc because I’m too lazy for anything else). For me anyway it boils down to context switching. I need to work on both the BE and FE. I know both technologies and have used them for years (regardless of languages). So for me it’s more important to not have to think about going from “array.map((v) => killMe(v))” to “[kill_me(v) for v in array]” (yes I’m aware there’s map in Python). Then there’s also tooling. I don’t have a build process for the BE but at least I can use the same tsconfig file and have the same linting on both sides. God forbid I’d have to deal with setting up tsconfig, vite, black, pyright/mypy, ruff, etc then have to update my version of node in the fe and update my versions of Python in the BE. Sure, I’m not 2x productive by using full stack Ts; sure my mental health has probably halved since using full stack Ts; but I am perhaps 2-5% faster. And in a tiny team (just me), that makes a difference. The idea of hiring FE devs to do BE or that I can only have type safety this way or even that I’d be reusing code was never part of the equation as those are all nonsense.
My recommendation to anyone thinking about using Ts full stack: just use htmx and save yourself the trouble man, it’s not worth your sanity
00:15 wtf is that alien code? freakin me out a little bit actually...
If you have really solid validation on one end, you effectively have it on both. I have rust on the backend and as a result I know exactly what im getting from the server in my typescript code, and vice versa, if im sending something wrong from typescript, rust will let me know in no uncertain terms, in fact it will be so desperate to let me know, it will be in a panicked state.
Javascript was a mistake
True
25:27 They could just add escaped " to send a string instead of text and that is valid json :)