Pfft, weak. VHDL on an FPGA, hook your network transceiver straight up no driver chip. Anything less and your leaving performance on the table. Plan to go straight to custom asics as soon you hit version 1.1
Microservice Take: Write a monolith out of modules, the modules should talk between one another using a defined interface, and they shouldn't share DB tables. If you need to you can always spin these modules off to be microservices. However, imo, you probably won't need to.
It's called Umbrella app on Phoenix/elixir ecosystem. It's a clever idea but most devs create a spaghetti codebase out of this so it's hard to recommend
One of the most impressive demos I have seen was with Erlang (beam VM). The guy introduced a while true bug, that took 100% of the CPU, however, the server still responded normally. Not only that, he then connected to the server, found out the process that was causing trouble, and killed it, making the server run normal again.
@@Deemo_codes you win the internet today. reason: providing search terms which IMMEDIATELY took me to the relevant blog post / video. Everyone: LEARN FROM THIS PERSON!
And then you could build NIFs in Rust that would run computation heavy tasks within Erlang/Elixir backend if required (normally these would be coded in C, but Rust seems a safer choice)
All that is true about the actor model in Gleam is also the same in Erlang and Elixir - it's just the BEAM VM. By the way, it is named Gleam because it rhymes with BEAM.
@@d_6963 which language can outperform C#? Rust, Golang have the capability. But they are not comparable with C# because they are suitable for more Lower level stuffs.
@28:01 bricks are actually layed that way and it's called a header course. It's used to tie the stretcher courses (the normal orientation bricks) together for structural rigidity
Re: "Early Return" - mapping and flatMapping monads does that. If your result type is a monad, you just map or flatMap the success case. That mapping will never execute if the result isn't a success, so it's equivalent to an early return. Several functional languages have special syntax to avoid nesting for sequential flatMapping (e.g. Haskell's do-notation, Scala's for-comprehension) - gleam's "use"-expressions do a version of the same kind of thing: avoid nesting when handling result types.
This does not necessarily solve the same problem - without an early return, you basically have to keep nesting code in your if/else chain (or case, or whatever gleam uses). Early return is usually just an easy way to break out of the function early without having to keep nesting and indenting logic branches.
@@dylan_the_wizard I'm not sure I understand. An early return by definition is inside some form of conditional - you still write code after that (that's what makes it "early"). When it comes to avoiding having to nest code to handle (computations returning) results - that's exactly what Haskell's do-notation and scala's for-comprehension do for monads.
@@DumblyDorrthis isn’t Haskell. If you don’t have early return you need to keep nesting cases. Early return lets you just add more cases underneath instead of indenting to the right.
Sometimes when Prime talks a lot and seemingly with a lot of conviction about something I feel like what is actually happening is that he's trying to convince himself about what he is saying.
Nah, it's your insecurities poking their noses. Projecting your own uncertainties with his convictions being a sign of his lack of confidence. And in my humble opinion, him talking a lot might just be a sign of him being a streamer, just a thought, I'm not really sure. But boy he does sure looks like someone who would stream.
Of course, types are everything. Types infer methods and it is good when the computer sees what it is working with. You can always pass the right class type to the right function.
Java... To be precise: a JAR file with the www resources and config file embedded inside. You'll end up with a single file that's your entire web package, and it runs on any system.
@@thapr0digy Overstated problem. You shouldn't be throwing nearly enough errors to the point where that becomes a processing or memory bottleneck. If it is, that's a skill issue
@@EvileDik I once made a HTML live chat without JavaScript. The java server would keep the Sockets open to send new messages, and browsers just happily append the latest bytes to their DOM. A side-discovery was that as long as you don't close the connection for the main page, the webdev tools would be mostly unusable.
I mean I could do all of this with Java Spring Boot in like 10 lines of code... Use the Right tool for the problem but ignore Spring Boot for some reason.
Yeah, no doubt you can do that having spend 5-10 years memorizing Spring Boot framework-specific APIs. I personally like/love libraries there I have IDE-Autocomplete and can write productive code after 10-30 min of reading the docs instead of wasting days trying to understand and wrestle with Spring Boot Idiosyncrasies.
i just googled Java Spring Boot and learned that it's a tool you can use Spring apps, and Spring apps are apps that you can just run. well.. ok, i guess... (not really.... shrugs...) sometimes i feel like these technologies are just trying to be obtuse...
@@AloisMahdalSpring is a backend framework. Period. It still needs a server to recieve and send http rewquests. Springboot is the Spring framework delivered in an opinionated docker aware package with integrated tomcat server and a few more bells and whistles.
I think we tend to gravitate towards languages that tries to fix languages we've been using, while still be familiar enough with it. I started of coding in Python 6-7 years ago, and even though I have studied Java, C, Haskell in actual classes and even written one or two Rust and Go projects, it never felt "home". I got too accustomed to indentations and multi-paradigm concepts in Python. Recently, I started to use and like nim, and I think it's because it fixes some problems of Python while still being similar enough (at least on the surface, the language has so much more flexibility because of metaprogramming and its ease in making a c wrapper). Anyway that's probably why people switched to JS to TS (without actually switching much) as well... they are used to it and wanted to use something that's better.
Here's the thing. I used to love Java. I also realized it has flaws when looking under the hood. I like OOP, but then I did remember at some point overengineering a class diagram before even doing anything... Kotlin is neat though, but I don't feel like I have excuses to use it as much.
I've stopped trying to fix languages with other languages (I've suffered enough, looking at you, React!). People are the problem, including me. We tend to create what I call "code entropy". This is why I build numerous small C# libraries that each have 1 responsibility. I can tell which packages I use more often based on the version numbers. 😊 And the one with the highest would be my Types nuget package that has extension methods for LINQ, quick null-free string parsing methods (with optinal fallback params), and a special Dump method that prints json to console whenever I'm debugging, but also returns the object so it never breaks control flow or causes eye-bleed. So, basically, for me, 'fixing' my favorite language worked out great for me. I can solve complex problems really fast in LINQ, dive into directories asynchronously with a few keystrokes, debug without stopping or pausing execution, and more odds and ends I'm forgetting because I'm high on coffee ☕️ 😳
3:40 Beauty is just our human brain trying to reward us for what it considers worth of pursuing and attractive. If you do not pursue beauty in your code, you will get burn out very quickly, because nobody likes to work on ugly code. Now, beauty is subjective and it has nothing to do with clean code. Beauty can be a hacky way to achieve something but that hacky way fits so perfectly well that it is beautiful.
"Do things that are beautiful", but also "no one cares about your code - all that maters is the result". I can't think of a way to resolve this contradiction if you ONLY code for work... mayby "find beauty in something that you do", instead of "do what you think is beautiful"?
It can easily be resolved if you realize that beautiful code has much fewer bugs. And an important metric for how good 'the result' is, is the number of bugs the system has.
There is a difference between extrinsic and intrinsic motivation. Your extrinsic motivation is to build software your users want to use. Your intrinsic motivation should be to make it beautiful. That's the claim.
@@vinterskugge907 not in my experiance it's not. If I spend my time polishing something to maximum levels of perfection available to me at my current level of proficiency what I usually get is complaints about "what took you so long". If I just slap things together and drop off a commit that barely works - it's fine. As to the bugs - they get delt with if/when they appear and no sooner. As a result, making something "beautiful" is a prerogative I allow myself only when I do things for myself, which the more I work, the less I get the time and/or inclination to do. PS: ...not that there isn't some beauty in jank that boggles the mind as to why and how it manages to do its thing at all ^_^
A Pokemon can only have four moves, so there are at most four queries, and they are run in parallel instead of sequentially since it spawns a task for each call and then waits on all of them with a timeout.
Everyone starting with microservices before they have fully mapped the domain will spend more time on DevOps/Platform engineering tasks than they need to early on. Until there are clear bounded contexts and a compelling reason to use microservices, most early stage projects should use a monolith to start. Early resource investment should be focused on features and delivering product, not technical ideology. End users don't care. The business most likely won't care. The VC/PE money folks won't care. Is your work fit for purpose? Does it add value to the business? Can sales close deals? These are the questions you should be asking early on, not whether the architecture adheres to Reactive/Clean/Onion/DDD/etc. Prioritize tests and working software over pedantic architectural implementations.
First-timers don't mind it slow in the backend if it translates to a softer smoother experience. However, those with more rodeo experience like it fast, and are willing to have it be a bit rough to get the most out of a full performance.
Driven by beauty helps you write better code I agree, but it can also drive you down the rabbit hole or give you tunnel vision. You need good discipline to code this way
PHP because Laravel. Just get it done. Then when the project has legs it's easy to get more devs at every level and you can peel parts out of the monolith into secondary services if you want to move to other languages within a particular domain (not for scaling, that should already be handled if you've done it right).
Agreed. And honestly, even if u don't use laravel, PHP frameworks in general can do so much stuff so fast to get u up n running. Obviously tho, Laravel is the most robust approach if u need this kind of power
Ton build an API please try API Platform. In the next release you will be able to use it with Laravel (or in any PHP projects). They work done on this his HUGE, it's so easy : add attributes to your DTOs, write provider and processors (or not if you use Doctrine orm) and bam you have a full API with security, content negociation, caching, documentation, ...
Occam's razor, the programing community is over represented by people who are both extremely confident and anxious at the same time, this creates this entire bs. No other profession changes tooling, and it's also not needed. If u go full sober no cap, you will see there is hardly any correlation between tools used and the succes of an application. I bet most successful apps are still in wordpress, webflow, php or w/e. Some changes made sense because the world changed, the general introduction of things like bootstrap, vue, react etc. because we went from static text on a single device to interactive on multiple devices, but the differences between them within their tier are not that relevant.
Minimal apis arent for scale. Depends on your scope. Theyre all embedded directly into Program.CS so if your program has more than a few CRUD endpoints they instantly lose relevancy. @infinite_s902
@thehumster7837 This reply can't be AI generated because it is full of nonsense. Minimal APIs do not have to be in a single file, they can be anywhere. There is infinite amount of resources talking about minimal APIs being just as scalable as controllers are.
@@ZoneInOn Minimal API setup is just a Map function call from the EndpointRoutes global. There are infintite ways to structure this. You can organize your endpoint resolvers as static classes that include a "MapEndpoints" function so Program.cs just calls into each of those. And if that gets cumbersome you can separate that bit into its own class dedicated to the registration. Alternatively you could do what controllers do and use attributes + reflection to set up any endpoint routes. You could have a separate service dedicated to endpoint resolution that contains all the logic. Etc. etc. The demo examples just call it straight in Program.cs, but the heart of it all is in the IEndpointRouteBuilder.
Use elixir and build a distributes system, is insane Real-time communication low latency distributed is what elixir shines at. Edit: gleam is another language for the erlang VM, I think is better than elixir in many ways but is just too new still
Gleam needs more dedicated people to build the ecosystem... Or a much stronger standard library. I just don't want to have to write my own everything. I've got kids.
Can you give some examples of how you think that Gleam is better than Elixir in many ways? The only one that I can think of is that Gleam already has static typing whereas Elixir will be getting it a bit later. But it's not like Elixir doesn't have ways to handle most typing errors already (function guards, pattern matching, immutability).
@@Voidstroyer Precisely. Also, lack of metaprogramming in Gleam is a big weakness. The general trend over the past decade has to introduce stronger metaprogramming. An example is how in dire need of metaprogramming Dart is, which it is getting soon; and how their current temporary substitute (build_runner) is messy. C# introduced source-generators. The moment your programing is more than just simple REST APIs, metaprogramming becomes invaluable. I can't imagine something like Phoenix without macros... Literally all languages have adopted metaprogramming to some extent, and Elixir is better than most languages at it. There are so many things that Elixir does much better than Gleam (IMO).
@@balen7555 I agree, however I admit that I have personally not really looked at Gleam as much (just watched a few videos) and so it's possible that my own bias towards Elixir is causing me to not see certain things. Which is why I am curious to see what @siriguillo has to say about his comparison of the two languages. (And to be fair I am curious to see if his opinion is also based on a bias towards Gleam due to lack of knowledge of Elixir).
That penguin is an accurate representation of how things work in a lot of projects. Someone finishes some mismatched feature (coding style, language, dependencies, etc.) and just mashes it all together with all the other mismatched pieces of code that make up the application. 5 years later you remake the original a̶p̶p̶l̶i̶c̶a̶t̶i̶o̶n̶ bugs, but this time in another language that will totally "get rid of the legacy code issue and bring us in line with current trends".
Is it typed to the level of C#? I think TS Is way overtyped (and overhyped), to the point where you're just writing more broken javascript but in a different flavor. But that's a common opinion. Coming from a C# background, I just could not get into TS because I kept falling asleep reading the docs
@@nicholaspreston9586 Elixir is dynamically typed, so like JavaScript without TypeScript, as far as I know. I meant TypeScript as an example for a not that great static type system glued on top of a dynamically typed language. With at least I meant that a type system like C# would be more than the one of TypeScript. :D
Same here. I already know Python and JavaScript. I've done a little Perl and Lisp and that's enough with the dynamic typing languages. Plus Python got type checking and JavaScript has Typescript. What's Elixir got? Fix the type system, and I'll be interested.
Partition will return a tuple of Ok results and Error results in their own respective lists. For example, [Ok(1), Error("a"), Error("b"), Ok(2)] would return #([2, 1], ["b", "a"])
I wanted to learn a functional language, so I looked at Haskell and OCaml. They were very interesting, but they felt highly alien to me. However, Elixir felt different. Elixir is partially alien, but in a good way. The pervasive use of pattern matching is such a good design, in my opinion. Additionally, Elixir feels really friendly to newcomers. It's really easy to explore new concepts from the functional paradigm, unlike in Haskell where trying to understand what a monad is can be quite challenging ._. Also I consider Elixir being extremely usefull and practical language with some superpowers no other language has (except BEAM langs ofc - Erlang and now Gleam).
did you just say effects don't have errors as values? that's kind of the core of it. also soon we'll have effect rotation too so you will not have to wrap everything into an effect.
the whole beauty thing is a bs because it's very egocentric and arbitrary. it's all beautiful until you have to work with someone who has a different concept of beauty and suddenly love turns to hatered because you are forced to do stuff that's ugly (for you). you will do ugly stuff every single day for years because you have to adapt to the environment that has a different notion of what's beautiful. let's call it a tyranny of beauty
Totally agree. Just write boring code that anyone can follow. If you need to explain how your components work together, that’s fine. But if you have to explain how your code works, you might be doing it wrong.
17:47 It's indeed pretty context specific, so it's not surprising. In gleam it splits a list of results into one list of successes and one list of failures.
I use MemoryCache in C#. Seems pretty fast. Dunno if I need Redis. Not saying I wouldn't use it tho. I like graph and what I'm hearing about Redis's versatility and speed overall. Just haven't found a use case yet in my personal projects
You can tell ThePrimeagen isn't as confident in his position when he gets angry that people suggest something to him. It's gotta be annoying to be pulled in all these different directions. Love the content!
to me the function coloring problem seems a lot like a tooling issue. If I have strict typing, it should be possible to automatically refactor all callers to be async and await the call. I think function coloring for async is actually good, particularly if your function only performs async IO sometimes. If you don't know whether a function can block for a long time, its just to easy to accidentally block the main thread of an interactive application, or block shared resources. Having to refactor large parts of you program just because you made a tiny change, is of course annoying, but the solution is automatic refactoring or to explicitly decolor the function (i.e. wrap it in a block_on or whatever your language calls it.)
Pascal. I know, sounded crazy to me, too, 20 years ago when I switched. But you know what? Still works, and I have yet to meet a developer who doesn't understand it. If there's a bottleneck, the workflow is to use whatever language you want, whatever algorithms you want, just don't change the ABI or API... then, put it in Pascal. Sometimes, fpc makes just as fast an executable, and the bottleneck was algorithmic, so whatever that new language was, usually isn't any faster in a way that improves user-perceived performance. If it is faster, the only comment needed is "see the Pascal". You get a maintainable system, and I know this from watching them exponentially scale for decades without the added cost of buying Kate more pants. Or painting yourself into a corner where "let's just rewrite the whole thing in Rust" actually sounds reasonable. REST, people, not REST API's which are an anti-pattern. HEAS, not HATEOAS, because people are using the latter to describe HTML pages full of identical unclickable buttons. Where are your URIs? Why are you excluding fully 1/3 of the global online population, to make your apps work in a way that won't be valid in five years, forsaking the URL which has an exponential-scaling track record dating back 30 years? THAT is the Web architecture. KISS.
I don't code in Haskell, but these projects, ghc comes in 2nd to fpc, and is the exception to the above, because there is no direct algorithmic translation from Haskell to... well, to anything. But where a recursive functional algorithm is called for, ghc has a userspace threading model that really kicks, and by using Pascal and Haskell... where's the vendor lock-in? The incessant changes? The failure to maintain backwards compatibility with 20-year-old code? OK, Haskell developers are hard to come by, but not for these projects. Several Forbes 500's in a common niche adopted my system for interoperability, but I'm under an NDA although they rarely consult me anymore.
I'm also considering doing backends in FP, what do you use nowadays? Are you straight up using fpweb or do you use something like Fano/Brook? I'm actually curious to see your opinion.
@@stefanalecu9532 I ranch nowadays. I get called in once a year to explain how REST APIs are no more REST than Tesla's thingie is a truck, so I don't know if they're using fpweb, probably not, although it's the same design pattern. All the httpd needs to know is FCGI, all the backend apps need to know is FCGI. We take this a step further by putting those apps in Zones or Jails with no network stack, POSIX IPC for the FCGI win. On the front end, HTTP 1.1 pipelining. No plans to upgrade to 3 any more than 2, no need to suck. No streaming videos, those are on Vimeo.
httpd only passes requests to the app when the cache expires, gets the Atom file back, writes it to disk, and now it's cached until it needs to be changed again, last-modified and etag are just filesystem metadata. The apps aren't doing anything unless they need to, the webserver's on autopilot, and the user-perceived performance isn't giving back the paltry latency gains of this century. It's about the latency. Over 30 years, only 30% improvement. Compare that to CPU/RAM/storage gains, and treat it as a precious commodity.
The user who sends a change of application state to the server, is the user who makes the first request for that new application state, no? How long does it take, when you e-mail a reply to a listmail, for it to reflect? A few seconds? Do you care? That's why I say back-end performance really doesn't matter, because the architectural style means that latency disappears for subsequent requests, until the application state is changed. But, it's always nice to reduce that first-request latency. Just not a critical concern, so use whatever coding language you want. Those details are hidden behind uniform interfaces all the way, i.e. HTTP and FCGI. But on that first request to the posting user, precision is the concern over performance. Input sanitization and validation, takes how long it takes.
Spring boot😢? Its so amazing it makes the backend level into a different league. Even though it and even java has so many features. You still have to do it the spring way. So everyones kinda on the same page how to design everything else.
My only gripe with elixir is the syntax & the type system is primitive (protocols are nice but interfaces are always a welcomed feature in general) & ambiguous at times in my opinion, especially opaque types like socket_handle() in the erlang docs, logically speaking it should be a fd or io_device, however io_device() type is defined as a process ID or an atom (esentially the same thing as a macro, theyre obsessed with atoms & returning tuples from functions, in fact errors are usually tuples where the 0th index is an atom & the 1th index is the errors message?) Overall its better than a couple of languages but its not for me, i do enjoy trying something different tho i wont doubt that, at the end of the day its still programming.
Oh, it's about Gleam, that's nice - I didn't know that and wrote three big comments about how awesome Elixir is. :D Basically, Erlang, Elixir, and now Gleam all have the same superpowers because they all run on the BEAM virtual machine. The difference lies in some syntax rules or the type system (in the case of Gleam). But they all orbit around the actor model in the BEAM VM, functional programming, etc. I just started learning Elixir about three months ago and expected to really like Gleam, but there are some 'buts' LUL. It does not offer some amazing features that are in Elixir - it's a tradeoff for its type system.
Keep practicing. It gets easier. Learn to read language specs. Start with ECMAScript. It's complicated by needing to be backwards compatible with older JavaScript.
This whole value as errors misses the whole point of exceptions. In another video recently Prime mentions he likes assertions that just fail the app, well that's how you can make exceptions work. If you don't want to handle them. If I'm calling a function X, I don't need to know all the exceptions it potentially might throw, and I don't care, in most cases an exception been thrown is likely something you can't do anything about anyway, (well not easily). eg. Out of memory, out of disk space, file permissions etc etc. But the nice thing if you did want to handle the exception, and implement some sort of recovery you can opt in later. I think a lot of reasons exceptions get bad rep, is when people use them for flow control, if a 3rd party lib is doing this then that's the fault of the lib, not exceptions.
A lot of it also comes from these awful garbage-collected languages where you might end up dropping state if you throw an exception. But that's also not the fault of exceptions, that's the fault of whatever silly person decided to copy the exception model and not also copy RAII to go with it. Exceptions need RAII to work, otherwise you're left in a nightmare scenario where you have to manually catch and cleanup at every level.
@@isodoubIet For resources that require cleanup logic that's a good point. For these the the "finally" comes in, but I think Zig & Go's defer wins here. You could create wrapper function to emulate this, but been built into a language really nice. The main problem with all option here is with them been scope based, a really nice option for a GC language would be closure based cleanup.
@@keithjohnson6510 Yeah it's like that meme "look what they need to mimic a fraction of our power". The "finally" keyword, disposables in C#, context managers in python, defer etc all just feel completely subpar. What do you mean by closure based cleanup?
The one thing I liked about Web Services from the SOAP era was WSDL files. Just download the thing and generate the client. Something like this should be mandatory for every API.
if you're not using elixir on the backend, you're simply falling behind. the mechanisms provided by the beam vm have no competition. the beam is truly a business logic operating system.
Boilerplate? Spring does so much magic stuff, it's just a @ here and a config class there and you have DB connection, orm, security, authentication, Kafka Connection. Sometimes I wish Java with Spring did less magic
Everything is an object, everything is nullabe, need to write a ton of if conditions to check for nulls No thanks Kotlin and Scala exist and run on the JVM
I agree... microservices are only neded once you get above 5000 requests per second... and at that point, your startup might (should) already be at the stage where it will not die...
If you do elixir can you talk about how to actually deal with dynamic typing? I always am like "and what is this I'm lost. Tools can't help me. List of list of what? I am in a map and I need to change something in some nesting. Where am I? Fuck it I'm going back to a typed language"
You want to iterate rapidly, especially if you're in a startup. Any language or framework that a enables this is good. You'll rewrite it all from scratch anyway if your company doesn't crash and burn like the 99%.
"You'll rewrite it all from scratch anyway" unlikely, I've seen companies grow to be worth billions and they didn't bother at all. Mainly because the folk who become tech leads take it personally and don't want anyone fixing their shit, so they hire good devs and ignore them xD
@@Bozebo Facebook, Netflix and Twitter are modern companies that support my argument. Build for rapid iteration in the early days. Build for sustainabilty and scale when you need to.
You can keep Zig, lol. I don't know why I'd build a web app in Zig for allocation reasons, unless it can beat c# or Go. Perhaps it has a niche I'm ignorant of? I mean, it looks cool, but it's on my list of langs to try.
Gleam is fun. From top-down, a Turbo Pascal on steroids for beginners. Underneath, the power of Erlang and js inclusion. Carl Sagan, "billions and billions of concurrent processes." So after supernova, my system collapsed into a black hole, consuming all light. Imagine Gleam in a container.
Likely Typescript/NestJS. Because, I don't think that I know all requirements when I start and npm ecosystem is so strong, so I can build any kind of application, use any authentication or database I decide. And there is kind of shortage of developers so I will write the backend myself and later I can get some wingman to help. Everyone knows JS so it is easier to find other developers. I know it is not ideal but if it works and when business is started, it doesn't matter. I can rewrite it later.
In JDSL, of course.
Genius detected
ask Tom, he's a genius!
Read it for the first time yesterday perfect timing
TOMS A GENIUS!!!!
Hands down, JDSL is SOTA ..
I love how every video an alert goes off and you're like "my bad forgot to turn alerts off"
He is guaranteed to get those donations doing it.
And I'm loving every minute of it.
I love THIS notification btw
In RISC-V ASM, of course.
Pfft, weak. VHDL on an FPGA, hook your network transceiver straight up no driver chip. Anything less and your leaving performance on the table. Plan to go straight to custom asics as soon you hit version 1.1
Insanity 😂
Microservice Take:
Write a monolith out of modules, the modules should talk between one another using a defined interface, and they shouldn't share DB tables.
If you need to you can always spin these modules off to be microservices. However, imo, you probably won't need to.
wisdom. You can have microservice-able architecture without actual microservices.
It's called Umbrella app on Phoenix/elixir ecosystem. It's a clever idea but most devs create a spaghetti codebase out of this so it's hard to recommend
You should watch a talk named Networkless HTTP by Matteo Collina, I think you would like it
Hey Could you give me some resources to learn more about this
i do this buy why not share DB tables? sometimes some services need to touch the same set of data and i avoid inter service comunication
“We’re completely off the *rails*” I see what you did there
came here to say just this.
my backend is in scratch
nice
What's the project name, back-scratcher?
goat
You scratch my backend I scratch yours
One of the most impressive demos I have seen was with Erlang (beam VM). The guy introduced a while true bug, that took 100% of the CPU, however, the server still responded normally. Not only that, he then connected to the server, found out the process that was causing trouble, and killed it, making the server run normal again.
ruclips.net/video/JvBT4XBdoUE/видео.html this is that video
You can even fix the bug and hot reload it in production
The soul of erlang and elixir by sasa juric. Fantastic talk and a fantastic demo
@@Deemo_codes you win the internet today. reason: providing search terms which IMMEDIATELY took me to the relevant blog post / video. Everyone: LEARN FROM THIS PERSON!
And then you could build NIFs in Rust that would run computation heavy tasks within Erlang/Elixir backend if required (normally these would be coded in C, but Rust seems a safer choice)
All that is true about the actor model in Gleam is also the same in Erlang and Elixir - it's just the BEAM VM.
By the way, it is named Gleam because it rhymes with BEAM.
In C#; Why would I go into the hassle of learning a new language when I can write my next backend in C# and have it perform faster & better, hmm.
csharp runtime sucks, ton of legacy stuff, btv microsoft is looking for rust devs, to rewrite some stuff from csharp😅
C# is my comfort language. All the time the I'm struggling with some problem in any other language I just switch to C# and it feels like home.
I second this, C# makes my life so much easier. You can do anything with it and it makes my nips happy
i mean you could and still use actors with Microsoft Orleans or akka but the BEAM is goated and first class in those family of languages.
@@d_6963 which language can outperform C#? Rust, Golang have the capability. But they are not comparable with C# because they are suitable for more Lower level stuffs.
@28:01 bricks are actually layed that way and it's called a header course. It's used to tie the stretcher courses (the normal orientation bricks) together for structural rigidity
Re: "Early Return" - mapping and flatMapping monads does that. If your result type is a monad, you just map or flatMap the success case. That mapping will never execute if the result isn't a success, so it's equivalent to an early return. Several functional languages have special syntax to avoid nesting for sequential flatMapping (e.g. Haskell's do-notation, Scala's for-comprehension) - gleam's "use"-expressions do a version of the same kind of thing: avoid nesting when handling result types.
where can we learn more?
C'MON, MAN! Don't leave me hanging!!!
This does not necessarily solve the same problem - without an early return, you basically have to keep nesting code in your if/else chain (or case, or whatever gleam uses). Early return is usually just an easy way to break out of the function early without having to keep nesting and indenting logic branches.
@@dylan_the_wizard I'm not sure I understand. An early return by definition is inside some form of conditional - you still write code after that (that's what makes it "early").
When it comes to avoiding having to nest code to handle (computations returning) results - that's exactly what Haskell's do-notation and scala's for-comprehension do for monads.
@@DumblyDorrthis isn’t Haskell. If you don’t have early return you need to keep nesting cases. Early return lets you just add more cases underneath instead of indenting to the right.
Sometimes when Prime talks a lot and seemingly with a lot of conviction about something I feel like what is actually happening is that he's trying to convince himself about what he is saying.
Nah, it's your insecurities poking their noses. Projecting your own uncertainties with his convictions being a sign of his lack of confidence.
And in my humble opinion, him talking a lot might just be a sign of him being a streamer, just a thought, I'm not really sure. But boy he does sure looks like someone who would stream.
Expressing your understanding of something is an exploration of why you understand it.
He does seem to think aloud a lot (and a lot aloud)...
Of course, types are everything. Types infer methods and it is good when the computer sees what it is working with. You can always pass the right class type to the right function.
Java...
To be precise: a JAR file with the www resources and config file embedded inside.
You'll end up with a single file that's your entire web package, and it runs on any system.
And it's garbage collected and a memory hog
@@thapr0digy Overstated problem. You shouldn't be throwing nearly enough errors to the point where that becomes a processing or memory bottleneck. If it is, that's a skill issue
@@thapr0digy enterprises have no problem with it, doubt a startup would
This is the way.
Too many millennial code fashonistas who's only language goal is the latest shiny.
@@EvileDik I once made a HTML live chat without JavaScript. The java server would keep the Sockets open to send new messages, and browsers just happily append the latest bytes to their DOM. A side-discovery was that as long as you don't close the connection for the main page, the webdev tools would be mostly unusable.
I mean I could do all of this with Java Spring Boot in like 10 lines of code... Use the Right tool for the problem but ignore Spring Boot for some reason.
It isn't trendy, you see
Yeah, no doubt you can do that having spend 5-10 years memorizing Spring Boot framework-specific APIs.
I personally like/love libraries there I have IDE-Autocomplete and can write productive code after 10-30 min of reading the docs
instead of wasting days trying to understand and wrestle with Spring Boot Idiosyncrasies.
i just googled Java Spring Boot and learned that it's a tool you can use Spring apps, and Spring apps are apps that you can just run.
well.. ok, i guess... (not really.... shrugs...) sometimes i feel like these technologies are just trying to be obtuse...
@@AloisMahdalSpring is a backend framework. Period. It still needs a server to recieve and send http rewquests.
Springboot is the Spring framework delivered in an opinionated docker aware package with integrated tomcat server and a few more bells and whistles.
I think we tend to gravitate towards languages that tries to fix languages we've been using, while still be familiar enough with it.
I started of coding in Python 6-7 years ago, and even though I have studied Java, C, Haskell in actual classes and even written one or two Rust and Go projects, it never felt "home". I got too accustomed to indentations and multi-paradigm concepts in Python. Recently, I started to use and like nim, and I think it's because it fixes some problems of Python while still being similar enough (at least on the surface, the language has so much more flexibility because of metaprogramming and its ease in making a c wrapper).
Anyway that's probably why people switched to JS to TS (without actually switching much) as well... they are used to it and wanted to use something that's better.
Try harder with java, you'll notice. And you'll think about all the python devs, that they are the result of a failed school system
Here's the thing. I used to love Java. I also realized it has flaws when looking under the hood. I like OOP, but then I did remember at some point overengineering a class diagram before even doing anything...
Kotlin is neat though, but I don't feel like I have excuses to use it as much.
I've stopped trying to fix languages with other languages (I've suffered enough, looking at you, React!). People are the problem, including me. We tend to create what I call "code entropy". This is why I build numerous small C# libraries that each have 1 responsibility. I can tell which packages I use more often based on the version numbers. 😊
And the one with the highest would be my Types nuget package that has extension methods for LINQ, quick null-free string parsing methods (with optinal fallback params), and a special Dump method that prints json to console whenever I'm debugging, but also returns the object so it never breaks control flow or causes eye-bleed.
So, basically, for me, 'fixing' my favorite language worked out great for me. I can solve complex problems really fast in LINQ, dive into directories asynchronously with a few keystrokes, debug without stopping or pausing execution, and more odds and ends I'm forgetting because I'm high on coffee ☕️ 😳
3:40 Beauty is just our human brain trying to reward us for what it considers worth of pursuing and attractive.
If you do not pursue beauty in your code, you will get burn out very quickly, because nobody likes to work on ugly code.
Now, beauty is subjective and it has nothing to do with clean code. Beauty can be a hacky way to achieve something but that hacky way fits so perfectly well that it is beautiful.
"Do things that are beautiful", but also "no one cares about your code - all that maters is the result". I can't think of a way to resolve this contradiction if you ONLY code for work... mayby "find beauty in something that you do", instead of "do what you think is beautiful"?
Yea, if I brought elixir or gleam into my next project at work I'd be crucified
you are taking this too literally, the idea is more "do a beautiful project", something that can help others, etc...
It can easily be resolved if you realize that beautiful code has much fewer bugs. And an important metric for how good 'the result' is, is the number of bugs the system has.
There is a difference between extrinsic and intrinsic motivation.
Your extrinsic motivation is to build software your users want to use. Your intrinsic motivation should be to make it beautiful. That's the claim.
@@vinterskugge907 not in my experiance it's not. If I spend my time polishing something to maximum levels of perfection available to me at my current level of proficiency what I usually get is complaints about "what took you so long". If I just slap things together and drop off a commit that barely works - it's fine. As to the bugs - they get delt with if/when they appear and no sooner.
As a result, making something "beautiful" is a prerogative I allow myself only when I do things for myself, which the more I work, the less I get the time and/or inclination to do.
PS: ...not that there isn't some beauty in jank that boggles the mind as to why and how it manages to do its thing at all ^_^
Well said.. instead of suffering from the architecture heart attack as a start up just build the damn thing first.
GLEAM MENTIONED
If every year is "the year of X" then you will never get to pick the right tool for the job.
Microservices? Of course! We need that Resume Driven Development. It does get you into the next job
Extreme go horse
Love how the author just casually glosses over the N+1 database call @17:30.
A Pokemon can only have four moves, so there are at most four queries, and they are run in parallel instead of sequentially since it spawns a task for each call and then waits on all of them with a timeout.
Everyone starting with microservices before they have fully mapped the domain will spend more time on DevOps/Platform engineering tasks than they need to early on. Until there are clear bounded contexts and a compelling reason to use microservices, most early stage projects should use a monolith to start. Early resource investment should be focused on features and delivering product, not technical ideology. End users don't care. The business most likely won't care. The VC/PE money folks won't care. Is your work fit for purpose? Does it add value to the business? Can sales close deals? These are the questions you should be asking early on, not whether the architecture adheres to Reactive/Clean/Onion/DDD/etc. Prioritize tests and working software over pedantic architectural implementations.
In BeefLang, of course.
Everyone starts with SQT-Lite but ends up with Rock-abs
First-timers don't mind it slow in the backend if it translates to a softer smoother experience. However, those with more rodeo experience like it fast, and are willing to have it be a bit rough to get the most out of a full performance.
Elixir is the most readable functional language there is, which isn't much to say, but hey, at least its something
Driven by beauty helps you write better code I agree, but it can also drive you down the rabbit hole or give you tunnel vision. You need good discipline to code this way
GoLang the first thing that came to mind
PHP because Laravel. Just get it done. Then when the project has legs it's easy to get more devs at every level and you can peel parts out of the monolith into secondary services if you want to move to other languages within a particular domain (not for scaling, that should already be handled if you've done it right).
Laravel is just so wonderful, once you try it you'll become a new person
Agreed. And honestly, even if u don't use laravel, PHP frameworks in general can do so much stuff so fast to get u up n running. Obviously tho, Laravel is the most robust approach if u need this kind of power
Ton build an API please try API Platform. In the next release you will be able to use it with Laravel (or in any PHP projects). They work done on this his HUGE, it's so easy : add attributes to your DTOs, write provider and processors (or not if you use Doctrine orm) and bam you have a full API with security, content negociation, caching, documentation, ...
@@brunoggdev6305I find Laravel pretty good for RAD, but Symfony much more flexible when you need it.
Occam's razor, the programing community is over represented by people who are both extremely confident and anxious at the same time, this creates this entire bs. No other profession changes tooling, and it's also not needed. If u go full sober no cap, you will see there is hardly any correlation between tools used and the succes of an application. I bet most successful apps are still in wordpress, webflow, php or w/e.
Some changes made sense because the world changed, the general introduction of things like bootstrap, vue, react etc. because we went from static text on a single device to interactive on multiple devices, but the differences between them within their tier are not that relevant.
Whatever language its easiest to employ people with.
It’s different in different locations.
Id use Spring, probably. I just like the batteries included thing.
I think when people say stuff like "return this" and the syntax is like "OKIE DOKIE LINE ARROW HEART EMOJI" I check out completely.
In C#, of course.
It’s pretty simple tbh
Specially the minimal api
Minimal apis arent for scale. Depends on your scope. Theyre all embedded directly into Program.CS so if your program has more than a few CRUD endpoints they instantly lose relevancy. @infinite_s902
@thehumster7837 This reply can't be AI generated because it is full of nonsense. Minimal APIs do not have to be in a single file, they can be anywhere. There is infinite amount of resources talking about minimal APIs being just as scalable as controllers are.
+1, quick setup and there’s not much you cannot do without too much finagling
@@ZoneInOn Minimal API setup is just a Map function call from the EndpointRoutes global. There are infintite ways to structure this. You can organize your endpoint resolvers as static classes that include a "MapEndpoints" function so Program.cs just calls into each of those. And if that gets cumbersome you can separate that bit into its own class dedicated to the registration. Alternatively you could do what controllers do and use attributes + reflection to set up any endpoint routes. You could have a separate service dedicated to endpoint resolution that contains all the logic. Etc. etc. The demo examples just call it straight in Program.cs, but the heart of it all is in the IEndpointRouteBuilder.
In C++, of course. No, I mean seriously!.
Nonsense. The Whitehouse has issues a warning on c++ and they know more than we do. I mean, they put Kamala Harris on AI.
My boi
@@Simple_OG C please
@@abjee1602 if you treat C++ simply as "C with smart pointers," it becomes a PLEASURE to work with!
Based and red pilled
Use elixir and build a distributes system, is insane
Real-time communication low latency distributed is what elixir shines at.
Edit: gleam is another language for the erlang VM, I think is better than elixir in many ways but is just too new still
Gleam needs more dedicated people to build the ecosystem... Or a much stronger standard library.
I just don't want to have to write my own everything. I've got kids.
I prefer Elixir over Gleam in every way possible. And Elixir is getting an interesting type system too.
Can you give some examples of how you think that Gleam is better than Elixir in many ways? The only one that I can think of is that Gleam already has static typing whereas Elixir will be getting it a bit later. But it's not like Elixir doesn't have ways to handle most typing errors already (function guards, pattern matching, immutability).
@@Voidstroyer Precisely. Also, lack of metaprogramming in Gleam is a big weakness. The general trend over the past decade has to introduce stronger metaprogramming. An example is how in dire need of metaprogramming Dart is, which it is getting soon; and how their current temporary substitute (build_runner) is messy. C# introduced source-generators.
The moment your programing is more than just simple REST APIs, metaprogramming becomes invaluable. I can't imagine something like Phoenix without macros...
Literally all languages have adopted metaprogramming to some extent, and Elixir is better than most languages at it.
There are so many things that Elixir does much better than Gleam (IMO).
@@balen7555 I agree, however I admit that I have personally not really looked at Gleam as much (just watched a few videos) and so it's possible that my own bias towards Elixir is causing me to not see certain things. Which is why I am curious to see what @siriguillo has to say about his comparison of the two languages. (And to be fair I am curious to see if his opinion is also based on a bias towards Gleam due to lack of knowledge of Elixir).
That penguin is an accurate representation of how things work in a lot of projects. Someone finishes some mismatched feature (coding style, language, dependencies, etc.) and just mashes it all together with all the other mismatched pieces of code that make up the application. 5 years later you remake the original a̶p̶p̶l̶i̶c̶a̶t̶i̶o̶n̶ bugs, but this time in another language that will totally "get rid of the legacy code issue and bring us in line with current trends".
I would take a look at Elixir, if it where statically typed. At least at the level of TypeScript.
Is it typed to the level of C#? I think TS Is way overtyped (and overhyped), to the point where you're just writing more broken javascript but in a different flavor. But that's a common opinion. Coming from a C# background, I just could not get into TS because I kept falling asleep reading the docs
@@nicholaspreston9586 Elixir is dynamically typed, so like JavaScript without TypeScript, as far as I know. I meant TypeScript as an example for a not that great static type system glued on top of a dynamically typed language. With at least I meant that a type system like C# would be more than the one of TypeScript. :D
Same here. I already know Python and JavaScript. I've done a little Perl and Lisp and that's enough with the dynamic typing languages. Plus Python got type checking and JavaScript has Typescript. What's Elixir got? Fix the type system, and I'll be interested.
Partition will return a tuple of Ok results and Error results in their own respective lists. For example, [Ok(1), Error("a"), Error("b"), Ok(2)] would return #([2, 1], ["b", "a"])
That's why Ruby on rails is best option for start-ups, you just deliver as much features as possible
Yes, do yourself a favor and go Elixir! Fair warning though, you won't want to go back
I wanted to learn a functional language, so I looked at Haskell and OCaml. They were very interesting, but they felt highly alien to me. However, Elixir felt different. Elixir is partially alien, but in a good way. The pervasive use of pattern matching is such a good design, in my opinion. Additionally, Elixir feels really friendly to newcomers. It's really easy to explore new concepts from the functional paradigm, unlike in Haskell where trying to understand what a monad is can be quite challenging ._.
Also I consider Elixir being extremely usefull and practical language with some superpowers no other language has (except BEAM langs ofc - Erlang and now Gleam).
Rust’s lifetime function colouring is a refactor nightmare! I too stopped using Rust when that came into the picture.
did you just say effects don't have errors as values? that's kind of the core of it. also soon we'll have effect rotation too so you will not have to wrap everything into an effect.
Spring boot obviously
Agreed, but in kotlin instead of java because I'm that special:)
Java spring (sometimes micronaut, quarkus etc) dominates enterprise and banking
Actually yes, literally just did that and I’ve been super happy with it
Yeah, Spring Boot and Java. Most elegant solution. Kotlin sounds to strange to me.
I was thinking the entire video "You can just do all of this with modern Java and Spring"
the whole beauty thing is a bs because it's very egocentric and arbitrary. it's all beautiful until you have to work with someone who has a different concept of beauty and suddenly love turns to hatered because you are forced to do stuff that's ugly (for you). you will do ugly stuff every single day for years because you have to adapt to the environment that has a different notion of what's beautiful. let's call it a tyranny of beauty
Totally agree. Just write boring code that anyone can follow. If you need to explain how your components work together, that’s fine. But if you have to explain how your code works, you might be doing it wrong.
Beautiful code comes from experience and if you don't have experience then you will write bad code even when you don't try to write beautiful code
17:47 It's indeed pretty context specific, so it's not surprising. In gleam it splits a list of results into one list of successes and one list of failures.
I use MemoryCache in C#. Seems pretty fast. Dunno if I need Redis. Not saying I wouldn't use it tho. I like graph and what I'm hearing about Redis's versatility and speed overall. Just haven't found a use case yet in my personal projects
"More microservices than users" 😂ok that made me laugh out loud.
4:06 What amazing wisdom
Write your backend with the language you're most comfortable with.
wrong!
Unless it's JS
Only for hobby projects.
write your backend with the language that is most fun for you
There are languages that are build for work like backend. Writing in other languages is dumb
You can tell ThePrimeagen isn't as confident in his position when he gets angry that people suggest something to him. It's gotta be annoying to be pulled in all these different directions. Love the content!
For this who didn’t watch, it’s vanilla JavaScript
I would write my backend in either rust, java or both
to me the function coloring problem seems a lot like a tooling issue. If I have strict typing, it should be possible to automatically refactor all callers to be async and await the call.
I think function coloring for async is actually good, particularly if your function only performs async IO sometimes. If you don't know whether a function can block for a long time, its just to easy to accidentally block the main thread of an interactive application, or block shared resources.
Having to refactor large parts of you program just because you made a tiny change, is of course annoying, but the solution is automatic refactoring or to explicitly decolor the function (i.e. wrap it in a block_on or whatever your language calls it.)
Good video.
Now let's watch it.
Pascal. I know, sounded crazy to me, too, 20 years ago when I switched. But you know what? Still works, and I have yet to meet a developer who doesn't understand it. If there's a bottleneck, the workflow is to use whatever language you want, whatever algorithms you want, just don't change the ABI or API... then, put it in Pascal. Sometimes, fpc makes just as fast an executable, and the bottleneck was algorithmic, so whatever that new language was, usually isn't any faster in a way that improves user-perceived performance. If it is faster, the only comment needed is "see the Pascal". You get a maintainable system, and I know this from watching them exponentially scale for decades without the added cost of buying Kate more pants. Or painting yourself into a corner where "let's just rewrite the whole thing in Rust" actually sounds reasonable. REST, people, not REST API's which are an anti-pattern. HEAS, not HATEOAS, because people are using the latter to describe HTML pages full of identical unclickable buttons. Where are your URIs? Why are you excluding fully 1/3 of the global online population, to make your apps work in a way that won't be valid in five years, forsaking the URL which has an exponential-scaling track record dating back 30 years? THAT is the Web architecture. KISS.
I don't code in Haskell, but these projects, ghc comes in 2nd to fpc, and is the exception to the above, because there is no direct algorithmic translation from Haskell to... well, to anything. But where a recursive functional algorithm is called for, ghc has a userspace threading model that really kicks, and by using Pascal and Haskell... where's the vendor lock-in? The incessant changes? The failure to maintain backwards compatibility with 20-year-old code? OK, Haskell developers are hard to come by, but not for these projects. Several Forbes 500's in a common niche adopted my system for interoperability, but I'm under an NDA although they rarely consult me anymore.
I'm also considering doing backends in FP, what do you use nowadays? Are you straight up using fpweb or do you use something like Fano/Brook? I'm actually curious to see your opinion.
@@stefanalecu9532 I ranch nowadays. I get called in once a year to explain how REST APIs are no more REST than Tesla's thingie is a truck, so I don't know if they're using fpweb, probably not, although it's the same design pattern. All the httpd needs to know is FCGI, all the backend apps need to know is FCGI.
We take this a step further by putting those apps in Zones or Jails with no network stack, POSIX IPC for the FCGI win. On the front end, HTTP 1.1 pipelining. No plans to upgrade to 3 any more than 2, no need to suck. No streaming videos, those are on Vimeo.
httpd only passes requests to the app when the cache expires, gets the Atom file back, writes it to disk, and now it's cached until it needs to be changed again, last-modified and etag are just filesystem metadata. The apps aren't doing anything unless they need to, the webserver's on autopilot, and the user-perceived performance isn't giving back the paltry latency gains of this century.
It's about the latency. Over 30 years, only 30% improvement. Compare that to CPU/RAM/storage gains, and treat it as a precious commodity.
The user who sends a change of application state to the server, is the user who makes the first request for that new application state, no?
How long does it take, when you e-mail a reply to a listmail, for it to reflect? A few seconds? Do you care? That's why I say back-end performance really doesn't matter, because the architectural style means that latency disappears for subsequent requests, until the application state is changed.
But, it's always nice to reduce that first-request latency. Just not a critical concern, so use whatever coding language you want. Those details are hidden behind uniform interfaces all the way, i.e. HTTP and FCGI. But on that first request to the posting user, precision is the concern over performance. Input sanitization and validation, takes how long it takes.
Spring boot😢? Its so amazing it makes the backend level into a different league. Even though it and even java has so many features. You still have to do it the spring way. So everyones kinda on the same page how to design everything else.
Drinking out of a Mason Jar like a true Quiche Eater :D
My only gripe with elixir is the syntax & the type system is primitive (protocols are nice but interfaces are always a welcomed feature in general) & ambiguous at times in my opinion, especially opaque types like socket_handle() in the erlang docs, logically speaking it should be a fd or io_device, however io_device() type is defined as a process ID or an atom (esentially the same thing as a macro, theyre obsessed with atoms & returning tuples from functions, in fact errors are usually tuples where the 0th index is an atom & the 1th index is the errors message?)
Overall its better than a couple of languages but its not for me, i do enjoy trying something different tho i wont doubt that, at the end of the day its still programming.
Really enjoyed your perplexed response to the non-stochastic nature of pokemon battles towards the end
I'm realistically doing 15K RPS on a single node with a monolith. What are microservices for again?
That Phoenix Live View seems to be really awesome. No complicated front-end and its toolings, but all the benefits.
Honestly, I'd use PHP first, then C# or Object Pascal (I am expecting such good responses)
Oh, it's about Gleam, that's nice - I didn't know that and wrote three big comments about how awesome Elixir is. :D
Basically, Erlang, Elixir, and now Gleam all have the same superpowers because they all run on the BEAM virtual machine. The difference lies in some syntax rules or the type system (in the case of Gleam). But they all orbit around the actor model in the BEAM VM, functional programming, etc.
I just started learning Elixir about three months ago and expected to really like Gleam, but there are some 'buts' LUL. It does not offer some amazing features that are in Elixir - it's a tradeoff for its type system.
Prime must have a larger more flexible brain than me. I can only be good at one language at one time. It feels painful to switch between languages.
Keep practicing. It gets easier.
Learn to read language specs. Start with ECMAScript. It's complicated by needing to be backwards compatible with older JavaScript.
This whole value as errors misses the whole point of exceptions. In another video recently Prime mentions he likes assertions that just fail the app, well that's how you can make exceptions work. If you don't want to handle them. If I'm calling a function X, I don't need to know all the exceptions it potentially might throw, and I don't care, in most cases an exception been thrown is likely something you can't do anything about anyway, (well not easily). eg. Out of memory, out of disk space, file permissions etc etc. But the nice thing if you did want to handle the exception, and implement some sort of recovery you can opt in later. I think a lot of reasons exceptions get bad rep, is when people use them for flow control, if a 3rd party lib is doing this then that's the fault of the lib, not exceptions.
A lot of it also comes from these awful garbage-collected languages where you might end up dropping state if you throw an exception. But that's also not the fault of exceptions, that's the fault of whatever silly person decided to copy the exception model and not also copy RAII to go with it. Exceptions need RAII to work, otherwise you're left in a nightmare scenario where you have to manually catch and cleanup at every level.
@@isodoubIet For resources that require cleanup logic that's a good point. For these the the "finally" comes in, but I think Zig & Go's defer wins here. You could create wrapper function to emulate this, but been built into a language really nice. The main problem with all option here is with them been scope based, a really nice option for a GC language would be closure based cleanup.
@@keithjohnson6510 Yeah it's like that meme "look what they need to mimic a fraction of our power". The "finally" keyword, disposables in C#, context managers in python, defer etc all just feel completely subpar. What do you mean by closure based cleanup?
Is it a re-upload?
The one thing I liked about Web Services from the SOAP era was WSDL files. Just download the thing and generate the client. Something like this should be mandatory for every API.
There's Open API spec for APIs now and you can generate clients from them.
There is OpenAPI 3.0 and AsyncAPI which will generate clients for you.
RPC frameworks do that.
elixir mentioned.. let's gooo
2:30 "off the rails" while mentioning the #1 ruby user
if you're not using elixir on the backend, you're simply falling behind. the mechanisms provided by the beam vm have no competition. the beam is truly a business logic operating system.
Function coloring helps separate side effects. If you make a function asynchronous because of another function, it's a code smell.
Username checks out
Just use whatever you’re most comfortable with which also fits the requirements
Spring boot or Golang
In Plankalkül , of course.
Huge gold nugget at the end of the video!
Elixir is more or less procedural with functional qualities like immutable data. Gleam is the functional language on the beam.
26:00 it is, the RNG is in getting that polemon (stuff move etc). But in a program that there is just 1 version of that pokemon, it is deterministic.
The correct answer is Java. There's a reason it is used extensively in FAANG and banking. Only downside is the boilerplate
Agreed. Plus, the boiler plate is really non problem with copilot.
Boilerplate? Spring does so much magic stuff, it's just a @ here and a config class there and you have DB connection, orm, security, authentication, Kafka Connection. Sometimes I wish Java with Spring did less magic
@@williamkoller9873copilot? Intellij and Lombok creates all the boilerplate for you😅
Everything is an object, everything is nullabe, need to write a ton of if conditions to check for nulls
No thanks
Kotlin and Scala exist and run on the JVM
@@nandomax3 Yeah the Spring magic plus build and boot times on large projects is a much bigger problem than boiler.
The right answer is C#, after JavaScript/typescript for years, C# brings a tear to my eye
I'd choose Haskell all day every day for back end.
I agree... microservices are only neded once you get above 5000 requests per second... and at that point, your startup might (should) already be at the stage where it will not die...
the ecommerce in my country get viewed by around 200.000.000 per day 🤣🤣🤣
@@UwU-gk7gq sure, as an aggregate... but does your e-commerce app/server get that many requests? If so, congratulations are in order... ;)
Java with Spring boot is just pleasant.
If you do elixir can you talk about how to actually deal with dynamic typing? I always am like "and what is this I'm lost. Tools can't help me. List of list of what? I am in a map and I need to change something in some nesting. Where am I? Fuck it I'm going back to a typed language"
Esoteric language mentioned
You want to iterate rapidly, especially if you're in a startup. Any language or framework that a enables this is good. You'll rewrite it all from scratch anyway if your company doesn't crash and burn like the 99%.
"You'll rewrite it all from scratch anyway" unlikely, I've seen companies grow to be worth billions and they didn't bother at all. Mainly because the folk who become tech leads take it personally and don't want anyone fixing their shit, so they hire good devs and ignore them xD
@@Bozebo Facebook, Netflix and Twitter are modern companies that support my argument. Build for rapid iteration in the early days. Build for sustainabilty and scale when you need to.
@@Bozebo have a look at Kent Beck's recent presentations on the economics of software development
I think eventually everybody finds logic in DHH's views. I think they guy has some great views that teach you how to enjoy being a developer
Absolutely! Have fun!
watching your videos make me feel like I'm a beginner
Yes do elixir. It’s on my radar for the later part of this year
You can keep Zig, lol. I don't know why I'd build a web app in Zig for allocation reasons, unless it can beat c# or Go. Perhaps it has a niche I'm ignorant of? I mean, it looks cool, but it's on my list of langs to try.
Backend devs: Frontend is needlessly complicated, what are they doing??
Backend devs: *Spending 1 week trying to update helm charts every 6 months*
Gleam is fun. From top-down, a Turbo Pascal on steroids for beginners. Underneath, the power of Erlang and js inclusion. Carl Sagan, "billions and billions of concurrent processes." So after supernova, my system collapsed into a black hole, consuming all light. Imagine Gleam in a container.
Good old Spring, I know for ages.
2:42 pretty simple, check out Edsger Dijkstra talking about mathematical elegance.
In Minecraft redstone, obviously
Ofc he left alerts on 🤣
Likely Typescript/NestJS.
Because, I don't think that I know all requirements when I start and npm ecosystem is so strong, so I can build any kind of application, use any authentication or database I decide.
And there is kind of shortage of developers so I will write the backend myself and later I can get some wingman to help. Everyone knows JS so it is easier to find other developers.
I know it is not ideal but if it works and when business is started, it doesn't matter. I can rewrite it later.