I don't like how Java is associated with pointless abstractions. That's the choice of the developer, not a requirement. The Java community might have a cultural problem in that regard, but it's not a valid argument against the language itself.
Well, language itself has fairly decent amount of problems All that mantra about everything being an object (except for primitive types) quickly gets old. Why can't you just define function without turning it into a static method of a class. It is already a pointless abstraction
C# has structs, so there's a value type as well as a class reference type. However, in both languages, you are forced to use only reference types (in C# if the library used uses classes instead of structs). Also, finalizers are not destructors, and don't work well for resource management other than memory. Yes, I could craft a non-idiomatic program that gave me the control that I want, and side step the abstractions, but it would be a nightmare to maintain. There aren't many programming languages that I don't know, so I have a choice of what to use. Kotlin is better, but still stuck in the same abstractions. I'd rather use Rust any day on any project than anything on the JVM. The issue with any abstraction isn't that it's pointless; it's that it's limiting.
Forced OOP is already a pointless abstraction, and you can't scape it if you use _any_ library. On top of that, if you work with someone who does Java, you are basically required to do it the "Java" way because most people follow the abstraction design patterns that are prevalent in the language.
About complexity: I wrote a 3D game engine and physics engine in Rust using just raw Vulkan, as well as countless of complex algorithms (such as full body inverse kinematics). All of these things were very easy to do in Rust. I also wrote a web app (frontend) in Rust and it's the most complex piece of code that I've ever written. The amount of cases you need to handle when dealing with asynchronous behavior from the user, async loading of data, server-side-rendering, etc, it's mind blowing.
@@aeghohloechu5022 boxed futures are somewhat of a workaround but that introduces it's own level of complexity. in most cases it's better to just deal with function coloring.
javascript also has the same problems unfortunately. elixir phoenix with liveview is the best solution to all of those problems. rust for the frontend would only make sense if you need a high performance backend and also for mission critical backends. elixir is good enough like go for most use cases.
@@paxcoder since 2018, a lot. But just like w/ Java it's hard to notice if you're not in the midst of things - you don't have to use sealed interfaces with records, and you're likelier to find tutorials not using those due to large history, but you probably should in new projects. Same goes with rust - you won't notice polonium in half a year if you're new, but if you're familiar with the language you feel a huge improvement. There's a bunch of tiny things that get merged and features that get partially added but if you removed all improvements since last year after getting used to them you'd feel them missing.
@@Caellyan Where does 2018 come from? The article has no date, but it first appeared in the WayBackMachine this month (his page was first indexed by google in ). The author's last commit to his own Rust project was 4 months ago as far as I can see. P.S. Is the chemical element an autocomplete mistake? Or are you referring to the rust framework?
@@paxcoder Afaik, since 2018, Rust has been operating on a 40 day release schedule, so improvements between releases are usually small and hard to notice if you're not actively trying to learn new parts of the language. Also I'm pretty sure they're referring to polonius, the upcoming complete rewrite of the borrow checker which will be significantly better at validating the safety of many uncommon but useful borrowing patterns that previously required the use of unsafe to circumvent the limitations of the current implementation. Holy run-on sentence, sorry.
Modern Java (version 21 and above) is truly impressive. If your opinions are based on experiences with older Java versions (prior to 21), it’s time to reconsider. Give the latest version a chance-you might be pleasantly surprised!
@@vinothmanoharan6111 sounds good, I'll go and download it now. Wait, what is an oracle account? What is this agreement I am signing up for? Yeah I know about openjdk but oracle is a good reason to stay away.
This. So many people shit on Java because they used Java 5 10 years ago at college lol. Chances are your language of choice sucked too or (didn't even exist yet). I see this most commonly with C# devs which makes no sense.
@@CaptainDangeax It can, actually. This can be done with the GraalVM Native Image stuff. IIRC it can even be statically linked, although I'm not really all that familiar with that process. Of course, in most cases you'd probably still want to have a separate JVM, but especially for cloud functions and such, GraalVM can do it for you.
It's hard to watch language reviews now because it's all purpose driven. You can smell app dev, you can smell web dev, low level systems, you can smell frontend and backend. No pun intended. I picture 4 dogs on the sidewalk doing this. I'm not looking for one ring to bind them all. That war gets ridiculous.
But that is what we're looking for, isn't it? Partly because devs don't want to have to learn 5 languages to stay relevant and partly because companies(probably) want to keep their technical and training requirements as lean as possible.
@@huuhhhhhhh Yes. The vast majority of end-use case, companies need a maintainable code base, and a pool of employees. Continuance. That would be js/ts, if you want a job in mainline business. If you want to escape the browser, it's a different world. No, I don't want to paint the world in React.js. It's actually a dumpster fire. I chose Zig for tiny embedded. I found limits with Rust. Java? It's great but I need to compile. Java's competitor is Go. You see where I'm going though. A tangent into trade-off land. There's never gonna be one ultimate language, but companies don't care.
I did my undergrad dissertation on functional programming in Java 21 and it's super cool. Sealed classes, records, type-match expressions, better streams, more control over the gc. It's all surprisingly ergonomic and well-considered. I like Rust too, though I use it less. I think the comparison is interesting because both are sorta supposed to be a simplified C++, but with completely different aims within that. IMO, Rust was co-opted for application programming but was intended for systems. There was this strange 3-way conflict between the designers, library maintainers, and end users, where each thought they were using a different language. For systems programming, Rust is elite. But nowadays I mostly use Clojure and very occasionally one Java glue file.
Somehow I get the impression that prime did use async Rust wrong... Yeah, async traits made stuff much easier but he always talks about arc and never mentions channels... Also writing Rust with a data-driven mindset is muuuch easier than most OOP I encountered
@@catto-from-heaven So even worse, you only spread misinformation xD It's easy to write low level code in Rust, that's the whole point of Rust lol It only sucks for higher level projects and Async stuff
@@giuliopimenoff Exactly, using it for 4 years for everything(web backends, android apps, minecraft mods, etc) and never ever I had something like "oh, that thing is so bad, I wish I could do that like in language X". It's actually quite an opposite, e.g. I was so mad 2 days ago when I discovered that in TS you can do Map.forEach(), but for whatever reason you can't do Map.map(), instead you have to use workaround with Array.from(Map).map().
As someone who has written both Rust and Java professionally I would argue that Java works great if you stay in the Java ecosystem. As soon as you want to have interoperability with anything that is not a JVM language it gets a nightmare really quickly. Rust on the otherhand does integrating with other languages and ecosystems exceptionally well, create JS / Python / R bindings for your lib ? No problem ! Import that one C/C++ lib you really need ? Eazy! Run the same Code in a WASM environment? Also trivial. All these examples are really painful to do in Java.
To be fair Java doesn't compile to object file. Thus calling native lib from Java is hard, and calling Java lib from native implies running JVM within your process. As Primagen has stated in this video, Java is application level language, and integration in server room is done using app level protocol and not by loading java library in virtual memory of your process.
@bariole I really don't like the notion that some languages are application level and some are system level, etc. This is an arbitrary distinction that mostly boils down to personal preference, skill and/or the tools and libraries available. Sure, some languages are better for certain use cases, but if you compare Rust to Java, I would argue that if you have people with similar experience on hand, you could build most standalone applications reasonably well with either language. Also, the argument that Java is interpreted is not really an argument for why Java makes it hard to interoperate with other languages. Python, for example, is also interpreted, but makes it much easier to integrate languages with a C ABI.
>Rust on the otherhand does integrating with other languages and ecosystems exceptionally well LOL it's FFI relies on "C", so it is as good or bad as any C - binding to other language is, that is BAD. just take a look at how the signal core rust library connects to Java via JNI or Swift ... Yikes. makes we wanna puke. Oh you meant, you can call "C" .. well congratu-f***-ilations, every damn programming language can do that.
@@agooodolecoder What are you even talking about. C ABI is dead simple and every language that wants to interface with system libraries needs it anyway so that's what is used as the common interface in a lot of cases but it doesn't mean you have to do it and it also doesn't mean it's bad. I'm calling C++ virtual class methods directly from Rust and Rust types with trait impl from C++ via a different ABI for example.
Readibility is largely down to familiarity. I find it far more readable because i know what 'filter', 'map` etc are going to do even if not specifically *how*. Just seeing the coarse-grained operators I can get a pretty good feel of what's going on where the loop could be mutating anything anywhere. Not only is composition easier, it makes it harder to 'just add a boolean flag' to the loop that invariably goes out of control with complexity. And it *is* a builder! You're building a pipeline of operators that you eventually call with a 'terminal operator' like `foreach` or `collect`.
I'm guessing you're referring to Java since it sounds like you're replying to the article and referencing the fizzbuzz example, but as a Rust guy, I just want to say that your comment could just as easily be referring to Rust's iterators.
and apparently rust has predicates, i went down the path of trying to write rust declaratively a while ago, (I dont code rust), it all came back down to, is this the rust idiomatic way? and that ended up killing my journey with Rust at the time. Gotta start banging me head on it again, maybe once I go braindead I'll be happier.
As far as Hindley-Milner types - for any mature enough to look past blind Microsoft hate - F# is actually a really good language taking learnings from Ocaml, has the HM types, has all the .net ecosystem, can do object oriented as well, etc.
@@chrismeyers5665 I love f#. But it is tough finding other programmers to consider it. There is some ugly things in the language but it is pragmatic and very useful.
"it's so difficult I've been there" I lived there it was awful, I essentially still live there understanding these ridiculous architectures that have to be supported is incredibly challenging. Working in finance was as close as I got to real-time and for me game-like programming. Where milliseconds matter.
Any arguments against Java should include the last version of Java the person making the argument has used. There are certainly some fair critiques, but a lot of people are simply stuck in the early 2000s and haven't bothered to update their language knowledge over time.
As a Java Spring Boot developer and someone who wrote a game engine in Java, here's my biblically accurate take on Java: + very easy to read code + simple build and dependacy management tools + great out of the box support for: networking, multithreading, string operations + heavily used everywhere, plenty of tutorials on practically everything, from computer graphics to game development - no operator overloading, difficult if you're dealing with lots of math - dynamic binding and auto boxing. ArrayList can fuck off. Why can't I just ArrayList? - many possibilities for abstractions that obscure what the code is actually doing - JVM takes a few seconds to boot Verdict: Java is the Chad's language of choice. You will not get the incel Budge of Honor like Rust + Vim users, but you will get something done and get paid for it.
maven can be frustrating and is missing a lot of core features without plugins which basically requires a ton of research on how to do & configure x thing. though from my experience same can be said of e.g. cmake I think autoboxing exists because it's generic code. Instead of having to handle differently-sized primitives in builtin classes at the language level, most 'std' classes opt for being generic classes the user themselves could write easily and you don't have to reimplement e.g. Hashmap nodes for every differently-sized primitive. You just implement it once for objects (references/pointers).
the last point: isn't graalVM even fixing that shit to some degree? (not sure, just read about it but didnt test it yet) regarding the build and dependency management tools... depends on what you wanna do, they can get pretty complex fast, especially if you dont really know what you are doing. but starting out with them is easy, yes - although maven is sometimes clunky and you have to deal with all those plugin shit stuff (but gradle exists too so its fine i guess)
"Why can't I just ArrayList?" Because bridging the gap between primitives and other types requires a huge effort. However, it is underway, check out JEP 402 (Enhanced Primitive Boxing). It will enable ArrayList. Even whan that is completed, Java will still use autoboxing under the hood. The next step will be resolving that, so ArrayList actually uses ints - that's in the pipeline too, but further off.
@@yfjolne Graalvm isn't widely adopted yet, I've never used it so it's hard for me to say how beneficial it is and for which project. Project Panama and Valhalla for the openjdk look good, but not out yet.
java 100% is... open the same piece of software and read the code in both langauges, and measure how long it takes for you to figure out wtf is going on
@@marv4054 yeah i'm using kotlin since beta days, introduced it in every company i been to... i just dont want to shift conversation to kotlin, but its funny that every complaint people have about java is fixed by kt
@@nakatash1977 they copied from delphi. Although I'm sure delphi copied something else. My point is that Java didn't come up with it. Not that it is bad to borrow good ideas.
This channel is insane, I feel like it has woken me from some kind of serious depression related to the downward trend of the world at large. It has inspired me and gotten me genuinely excited to create again, to care less about the stuff I have no control over, and to immerse myself in the stuff that I have intense, granular control of. Very, very glad you are out there Prime.
Why are we pretending that you have to use inheritance in java? just quite literally forbid it. Thats what we did at my job and its just a better go at that point
Why Inhertiance has good applications where it needs to be used. Sometimes you want to use Inheritance to prevent a class from having too many methods...
as a minecraft kid, i have an interesting relationship with Java as i learned more about it from the periphery. JVM, Garbage collection, memory allocation, i barely know what these are, but i've had to fix them in so many weird and interesting ways over 7+ years. now MC Java mods are 50% kotlin tho heh
It's also like people say: "Yeah but writing in native Assembly is much more efficient than relying on a compiler", No it's not, it's only more efficient if you can write better Assembly code than the Compiler. And most programmers that were born in the last 30 years probably cannot actually write better Assembly than most Compilers.
@@username7763 Scala is too complex and when applied to masses the way Java is used it results in even worse software projects. People forget that most software projects are not made by excelent engineers most software is made by average engineers and it takes way more effort to learn how to use Scala to not shoot one self in a foot than it takes Java.
@@sk-sm9sh The vast majority of software is many times more complex than any programming language. If using a more complicated language means you end up with simpler code, that is a worthy tradeoff. The only way it couldn't be is if engineers aren't bothering to understand the code. But in that case, they aren't engineering.
@@username7763 more complicated programming languages typically have more features that can enable more ways to cut corners. Using more complicated language will only result in simpler code if you take best approach. Using more complicated language almost always result in code that is messier in most software projects because in most software projects there is lack of discipline.
@@username7763 you can call your engineers not engineers if they don't completely understand the minute details of every overcomplicated feature of the language that is used to achieve ideological purity or appearance of cleanliness and simplicity, but it's just a fact of life that they will work on your code. Human resources are rarely perfect, and languages exist to adapt to humans not vice versa. Blame doesn't matter, only achievable solutions are. And solving this problem by only ever hiring perfect people can be less feasible than choosing a different language that doesn't require people to be as perfect
Oh man, I watched 10 minutes and noticed I'm actually tired of this. It's so repetitive... why compare Java to Rust? Rust is a systems programming language without GC. That alone means that inevitable some things will be harder to write and definitely plays a role in the necessity of macros sometimes! Also, I wonder how many people that complain about async rust have written async C++. That would be a meaningful comparison.
Funny. Cause the video addresses your point a number of times. The reason for the comparison is because you keep using rust for things that you’d be better off using Java or go for.
@@wredue3733 First of all, I still disagree. I've used Rust a lot (sync and async) and definitely would not go back to go or Java for anything where reliability is even remotely important. Nevertheless, "Rust is used in areas where other technologies might be more suitable" is a debatable, but reasonable stance. That is a VERY different statement than "Java is better than rust" though ,which is literally the title of the article. So if that's what they were trying to say, their communication skills are apparently even worse than their coding skills.
The thing is, personally I would prefer to use Rust over Java every time because of the build system and type system. Also, most apps don't need to be async anyway nor do you need to write macros that often. So I don't understand why writing "actually useful apps" means doing those things.
Well I love the verbosity and compile time safety of Java. When libs use ASM byte code modification with annotations, stuff like Spring Boot has minimal boiler plate code. JPA finders in spring wrapped ORM are so minimalist am not sure you can code faster than that in any other language. So I find Java rocks more nowadays than it has ever done. I ❤ Java.
Byte code modification, annotations and Spring are precisely the worst things about Java. It’s not about code golfing, it’s about code thst works. And all this bullshit magic is just the recipe for constant disaster. Which of the hundreds of magical annotations broke the Spring context this time?!? I hate people use this shit, who like this shit, and who think that this shit is productive. Golang attracts people for precisrly the reason it has none of this bullshit magic
You should try new Java Stuff, you will appreciate the language more, I do think your opinion is miss a little bit because the memory you had about Java is "applet" and 1.5 stuff.
The only reason to pick Rust over Java for some huge grug business project is for your own job security. If you actually get something up and running you're the only person who's ever going to understand it and never get fired. Choosing Rust Drastically reduces the amount of engineers who can work on it.
@@ShootingUtah this is partially true but also unfortunate. I've learned many language and technologies in my career simply because someone had to maintain a project after the original authors left. It's hard but not that hard. I just don't understand the mindset of programmers not wanting to learn new, and old, things.
Perhaps, but by that metric JavaScript is possibly even better, but really you should be writing in C++ or Python. In practice, every team has different experience and expectations, and different problems they need to solve. It's quite possible to have a problem, even in a big grug bushes project, where 10 lines of Rust beats the pants off of several thousand lines of Java. Or vice versa! Being a good engineer is often about being able to predict that sort of thing.
rust has some things that are inherently difficult, but i think most of what makes it difficult to learn is that it's an entirely unique paradigm. it makes you feel like you know nothing again. whereas the majority of other languages have similar concepts. i think if more languages had a borrow checker the reputation of difficulty would be lower.
Java just keeps reinventing itself and beating other languages, for example with native threads in Java 21 improving the performance of the virtual machine. I think that's the kind of feature that could make it a great alternative to "trendy" back-end technologies like Node.js However Java currently needs a React framework killer too, for the front-end applications that use that cursed technology. We used to have strong alternatives but they aren't updated for the single page model. Front-end usage of Java really fell off the charts by the time Java Server Faces was released (previously lots of coding was done on JSP and Jakarta Struts for example).
if webassembly cant fully beat js in frontend, then java version will not i think, just like c# blazor. webassembly excels in runtime performance but slower in initial loading and slower in development cycle than javascript and creating highly complicated interactivity is very complex. no one will fully beat javascript in frontend in couple years unless webassembly initial loading speed is solved with different strategy than previous ones and making it much less complex to build highly complex interactivity to the point at least match javascript's if not surpassed, then I can really see it will take over javascript in frontend
I am writing C++ code for a living and many Concepts regarding the Borrowchecker are various footguns you learn in C++ the hard way. I was positively impressed how Rust just enforced that.
The vast majority of criticisms of rust that I see are people who mostly write Java (or Python, or Javascript, or Go). They usually write some kind of simple web application back-end and the complaint usually goes "urgh this language is such hard work, why do I have to jump through so many hoops!?". However, if you write ultra high-performance massively-parallel code and your only realistic alternative was C/C++, but you need it to be right and not crash. Well then you can start to appreciate the real strengths of rust.
@@tomshackell The drama surrounding the Linux Kernel Rust integration has shown that you can add C programmer to that list. But they argue from a different point of view. One valid criticism here is the different way of thinking and structuring of your code. Another point seems to be the stiffness how Rust (the compiler theirof) demands you to do things the Rust way. I also don't like how the complexity of the language itself (adding lifetimes, async, borrowchecker, ... etc. on top of each other) rivals C++ without the legacy. I haven't used Rust for bigger/complex projects only C/C++/C#. To me the whole "Rust is bad" and "Rust is good" debate is (1st) jumping between not knowing the languge (or how to write data oriented code) and (2nd) using Rust for things it is just not good at.
@@TanigaDanae Agreed, Rust is a complex language. I personally don't find that surprising: it's a language that provides the performance and low-level control of C, but without the inherent unsafety of C. Strangely that's not easy to achieve and comes with some compromises. I have used Rust on a large commercial project. It's been very successful: because we use it for what it is good at. Dealing with highly complex software running on machines with 100+ CPUs and 4TB of RAM. The language is complex, but that complexity is nothing compared to the demands of our domain. The language is easy by comparison and the safety it provides (especially thread safety) is such an enormous win that it's worth the complexity. It's always been possible to knock together a simple CRUD webservice in C++. However people didn't generally do it because it was overkill. Rust is nicer to use than C++ (IMO) .. but it's still in that same category. It's a difficult complex language designed for solving very hard problems where performance is essential. Most people don't write that kind of code .. but some of us do.
That mention of needing to refactor a rust application after adding a new string to the mix gives me the same kind of vibes to needing to add in a variable in an Elm app on the front end. I need to add this one thing, but it not has to be strung through 27 functions and handled at every step of the way before it can compile again and my IDE is screaming at me the whole way.
Thankfully in Rust you can always just throw it into an Rc (the rust equivalent of the average variable in Go) and you don't need to deal with any of the lifetime stuff nor have to worry about performance when cloning etc.
Unless the string is large I don't understand why you wouldn't just store as String::new() and clone it. If it is a large string then you're probably making a major change to the application anyways. Plus Rc or Arc is in your toolbox. Although to be fair if you need to mutate the shared string things start to get ugly Arc or Rc while require you to clone the smart pointer then lock the mutex are not ideal..
I went from over a decade of Python, and only thing I'd used (other than some MC modding back when it was in Beta). And I found Rust just clicked with the way I like to program, and it's all because of the borrow checker, it made things feel very easy to learn. But I think that's just because it feels like the way Rust works, and the way my brain works are pretty aligned.
java literally gives me anxiety. No refererential transparency. You cannot trust that some code will not perform spooky actions at a distance. And the code takes so long to read that my brain runs out of memory before I understand what the code actually does. Rust is ugly as hell to me, but at least I can read the code without falling asleep before understanding whats going on and I can trust the code without getting anxiety about spooky side effects.
While async rust is hard, Actors make it quite easy to reason about once you understand them. They also seem to overcome the lifetime stuff. Channels and message passing in general makes rust so much easier, because you avoid shared state a lot.
I use java for work and actually kind of like it My biggest issue so far is inability to have real compile time values. And tbf my issue with most modern languages is lack of pre-processor stuff. At least in C you can make pretty much anything with macros.
Rust macros are great! They are typesafe code templates with cool pattern matching and repeat args. If you need more, there is a 2nd kind of programmed macros, that can, at Rust compile time, validate HTML passed in, or connect to the database and validate your SQL, as well as establish the types of in and out values: so many avoided run time problems.
Java is so much easy to use, and have so much stable and mature libraries. I do not want you guys to use Java, I use Java it make me so happy, I do not want to share good things such as Java programming language to you guys because I am so selfish. so, I would tell you: Java is a so bad programming language! do not use it, please!
I’m a C++ systems programmer so Rust is perfect for the stuff I do. The product I work on is a library for mobile and embedded database software, so performance and memory safety are really important. Rust would be super helpful. Currently writing a log parser in Rust to parse all of the text logs we receive from customers, and write the parsed data into SQLite. I think Rust is really great for that too because it’s mostly “simple Rust” apart from a few custom proc macros to reduce code duplication, and the data types which get written into SQL are verified at compile time.
Getting a good injection mold design going is typically harder than getting a precision gear made. You still need extremely high precision machining for the mold, and making a good moldable design for something non-trivial requires a significant body of knowledge. And then, you need the molding equipment. You also need some specialized tooling for precision gear grinding, but overall, from soup to nuts, I'd say molding a run of parts is a harder process, and if you're asking someone else to make your parts, more knowledge is needed for the injectionolded design.
Bjarne Stroustrup the c++ developer said , if i was in my 20's in 2024 , i probably learn all the different programming languages because i love learning them , i'm not going to be a person who is doing sales job and then learn one programming which pays more for earn more... because this is not going to last long.
Exceptions aren't for error handling. They're for reporting unexpected errors. They're like panic in golang. That's why checked exceptions turned out to be a bad idea and APIs now tend to allow for handling expected errors like parsing JSON from outside or making a network call without using exceptions. At the same time, unexpected errors like local configuration JSON broken are still best handled by letting an exception fall down the stack.
Lately I have been obligated to use java for a project that requires very high performance. I just keep desperately searching the internet for a valid reason to not dislike it but I did not find it here :(. Most of the libraries are poorly optimized because the way you abstract things in java is adding almost always indirection levels (you can not have the equivalent of a list of struts without some black magic for instance) and support for proper ffi and vectorized instructions is still in incubator, project Valhalla still not finished... so it feels that it's way behind from rust and Zig and other languages in that regard. Also back in the day I did enterprise backbends in spring, and this is anything but simple at least if we talk about what happens in runtime.
yes it is possible to get good performance but you basically have to take apart existing classes in order to do so and create your own implementations of interfaces. Of course nothing close to nitty-gritty low-level optimizations like vectorizations but at least it will be 'fine'. I had to repurpose some apache poi class to stream an excel spreadsheet while keeping memory low, and take apart/reimplement parts of SimpleJdbcInsert from spring in order to support uppercase postgres table names before ditching it and JdbcClient entirely because their default implementations created too many objects, namely large maps with wasteful properties we had no need for (uppercase and lowercase indexing of 'result maps') in every query and if you want to do anything remotely realtime, forget it. but that's mainly bc of the runtime and garbage collector.
I think Rust is valid as an Application Language. But the hard part about that is writing the Rust Libraries to support App Level code. Reading or writing a function signature with more than 3 trait bounds, or whatever they're called, can be hell, trying to keep all that info in your head before even reading the function is hard.
that's my take on it as well. the only thing i would slightly disagree with is that most applications don't reach that point. most of the rust code i've written has a create for something that already abstracts away a lot of the complexity. of course you do have to sometimes do things on your own and that's where i agree.
I don't agree when you say rust is an "all the things" language, I think it is a "mission critical" software language, if the software is not mission critical, then there is probably a better choice.
I would call it "performance critical" instead, it doesn't have to be a big mission, but it definitely crushes performance, and you can use it for a small part of your app, you don't need the entire app using rust
Mission Critical software you chose C++ not Rust, because more people know C++, it has more mature good libraries and it's been an industry standard for Decades and is used in the Aerospace industry.
I really don’t like the mental overhead in a programming language. I want my mental energy focused on the problem not on the tool. This is why I am not sure I will go on with Rust. I don’t need it for work and I just need a low level language in my personal toolbox as an engineer to mess around with lower level stuff. I am very tempted to switch back to C or jump on Zig (or Mojo or OCaml?).
(Java^22 + Lombok + Manifold) x Kotlin = Exactly what I enjoy dealing with. JetBrains forcing Oracle to be better. If the 10+ Big Java projects ever get finished, Any Native + Java + Kotlin will be super nice.
@OleKap records are great when you can use them. On bigger classes, unless you delegate a lot of the code to a helper/handler, lombok can remove a lot of boilerplate, not have to sift through. I'd delombok eventually, but it speeds up the dev process quite a bit.
@@OleKap Any class where java setters are required: JPA entities, spring beans , DTO classes with older versions of Jackson, because they don't support records, in cases you need to add annotations on fields. Let alone when requiring features that records doesn't support, builders, fields exclusion from toString(), and hashCode().
It's funny to me how the same argument applies differently to rust and go. Prime says doing ? everywhere in rust is bad so on. But in Go he says he has to think a lot about the problem, and handles it, as if you couldn't do if err nil { return err }.
it is just harder to do. Typing ? is dead simple. But if you write if err != nil your brain out of habit automatically makes you add some context to that error by wrapping it before returning
What i feel you are forgetting about Rust is that it's type abstractions are normally 0 cost, and only when the `dyn` keyword and a `struct` which allocates really slows the application down in any meaningful way. Also (as much as it can) the compiler optimizes the Rust code and sometimes the resulting binary has allocations and dynamic dispatch optimized away. Yes it is a black box, but the compiler can often make better optimizations than a human can hand code something. I will say it's perfectly valid to prefer something like Zig over Rust but arguing about which is better is often futile and in some area's Zig will beat Rust, but also the visa versa is true, for instance working with a large code base hands down Rust annihilates Zig, Zig also requires just as much allocation as Rust, for instance returning an error with context dynamic at runtime still requires a heap allocation as the size cannot be known at runtime and the error requires persistence beyond the stack frame it is called in. That being said, you can do errors statically in Rust, you can also do them dynamically but you can also have a hybrid approach very easily where you use an Optional to be `None` for static handling and either use a `Box
yeah, if you have 50k lines + nobody cares about "zero cost abstractions" when debugger doesn't work :) or the debug build is so slow, that it's actually better to do it the JS way - just write to console.
"working with a large code base hands down Rust annihilates Zig" I feel like it's too early to say this. I don't think large codebases in Zig have really been tried yet, except for Bun. I am very curious how Zig will compare to Rust once it's stable.
@@Qrzychu92 currently i'm writing some code which in involves a complex set of steps to scrape, download, verify, and upload to a database. I'm using lifetimes and mutable references, to most this area of Rust appears complex because you have to think about lifetimes in an abstract way as opposed to i declared it here and i must at some point free it, or its on the stack and taken care automatically. I prefer it over Zig and normal references found in Zig, C++ and Go. Because if i was to introduce a bug which makes the reference invalid Rust will catch it. That's my perspective and i like it, I'm not saying everyone has to agree with that, I'm not saying my opinion is the correct one and I'm not saying it's the best, i'm, saying i prefer it. Someone else may prefer Zig and that's fine, it's syntax and philosophy may appeal to them, but whichever you like doesn't invalidate the other is what i'm pointing out. Since i've had to explain this twice now i'm going to see this as resolved
Started with PHP projects. Then Java for a couple years. Now Scala, Kotlin, JavaScript/Typescript, Python, Go and so on. I saw all the pitfalls. I love Scala and Kotlin. But for my own business I would always choose plain Java with a enterprise supported Framework like Quarkus or Spring. Or maybe Scala with Akka for some specific use case.
@@balint133 Sure it is. But think about hiring, supporting agencies, knowledge transfer and so on. Let us say your are the founder, it is your own money and your choice. What would you do? I would go for the most boring, established, enterprise ready language and toolset. I am in a Scala project for around 8 years and we are working on some Kotlin services too. It is fun, but I am convinced that this was not the best business decision.
The two serve completely different purposes. Want to get stuff done easier and faster at the expense of having to carry around a runtime? Use Java. Otherwise, use Rust. The two aren't really competing.
I know C#. I made three small apps for my own use in Rust. Anything non system level or "C#" level was as productive as C#. And that feeling I got while still learning Rust...
@@techpriest4787 I've written web servers in all three, and mobile and desktop apps on C# and Java. I don't feel that Rust slows me down much either after you know it well, but I also understand those who do feel slowed down. You have to keep more things in your head while developing Rust than Java or C#: who should own this? should this function borrow that? Should this variable be consumed here? Should a reference be returned there? Stuff that you simply don't have to think about in Java or C#.
Hi Primeagen, I love your content! However, I think your criticism of Java might be based on older versions and outdated knowledge. If you explore modern Java, perhaps with a framework like Quarkus, you might find its tooling and features more impressive. Just as you took the time to learn Zig, giving modern Java a fresh look could be enlightening. Looking forward to your thoughts!
I much prefer Kotlin over Java - less boilerplate and a more modern language, null safety, better syntax etc. Coding in Java for the JVM does not make sense to me because Kotlin is fully interoperable with Java
I would love to use kotlin, but you are practically required to use intellij. There are no good tools/lsp outside. And IntelliJ is great, but it's really heavy (and afaik you can only use community edition for non commercial uses?)
@@gabrielpreciado5699 Scala is a great language but it has downsides It is a more difficult for your average programmer, slower compilation and less compatible with Java libraries. Jetbrains created Kotlin because of some of the downsides of Scala You could argue that Kotlin is a baby Scala
10:30 Having implemented my own framework that makes use of functions with varying parameters and return values... yeah, things get kinda tricky. Probably the hardest thing I've implemented in Rust. Was kinda fun, though and I learnt a lot. And because I'm not sure I properly described what I mean: I have a route() method that takes in a callback function. This callback function can have many different parameters and the return value is also somewhat flexible. It adjusts its behaviour based on what exact function you give it.
com.mycorporatebusiness.mydepartment.packagename.subpackagename ..... WHY ARE YOU GUYS STILL WRITING THIS TRASH?! Just use a simple one-word package name!
I don't know if this was mentioned, maybe I missed it, but any language where objects/structs can always be null is just an instant "pass" for me. The other questions don't even have to be raised.
This is one of the real problems that nobody seems to care about. All these languages bring a lot of software engineering byproducts that have nothing to do with computer science. Reference types? Objects and classes? Iterators? StringBuilder FileStreams? Nothing but BS. We have real programming languages like ML and Mathematica for solving real problems.
I thought I hated working with Java, but then I worked on a big rust codebase, and I feel like I prefer java's amazing debugging and tooling over rust's, despite how awesome cargo is. Aslo, I may not like Java, but I love kotlin (despite some hangups surrounding certain defaults, and nested destructuring).
You downloaded the wrong Rust. It requires only a minimum of debugging tools. You may be out of habit using it more than you actually need. Old habits die hard.
@@techpriest4787 spoken like a true member of the community. Try saying that after you have to diagnose a subtle logic error, and most of the types you're working with dont even implement debug. Oh, and there's liberal use of super confusing numeric IDs that abstract away anything even slightly reminiscent of a string. Also, every other function you try to step into is proc macro generated. I'm working on a 5 year old codebase. The guy who made some of this stuff isn't in the org any more. And there's no documentation worth looking at. Despite all that, I did eventually fix the bug I've been ranting about. It was, thankfully, a 1 line fix. But I couldn't have done it without a debugger. And it would've been nice if the debugger just let me execute arbitrary rust as an expression, it would've saved me a lot of time figuring out what the heck that boxed double indirected enum inside an rc refcell had inside. Yeah. Don't say I was using it wrong.
@@techpriest4787 you are a great person who has correct thoughts and nothing is wrong about what you have said. Also lived experience is worth a lot more than a bunch of words strung together on a screen.
explaining the code sample in java, starting from main: we create an integer range as an array to pass using the java 8 IntStream. We create a map of conditions, relating predicates of ints, to strings. A predicate is a true-false statement. In this case they're implemented with a Java 7 Lambda then we print the output of fizzBuzz for the range and rules of the game. Stepping into the algorithm, we stream the array of ints. For each int in order, we stream the conditions. If any condition matches, we map to its matching string. We connect the strings together. if there is no result yet, we return the number instead. Then we connect the results for each number with spaces between, and return. This structure is written so that the number game could be done with any arbitrary substitution if the number matches a given condition, and that condition can be anything as long as it is a condition on a number. It can also take any arbitrary number sequence.
@@AndrewErwin73 well, exactly. Everything would be good if you know how and why you use it properly. And if you don't, then everything can be bad. That's such a non-heuristic it isn't even worth pointing out in general.
The fact that we're comparing the complexity of Java, which is a garbage-collected language, with Rust, says a lot about how unnecessarily complex Java is
I'm all for writing "simple code" because I would take simple code any day over difficult and "make me feel smart code" just because I know for a fact that you'll burn out so much quicker if all you did was difficult code day in and day out
I don't understand how you can think that there is more mental overhead in using filler, map and reduce than in using a bunch of loops, like at 32:00 . Sounds like some Golang copeism to me.
It is all garbage for the fact that people just don't know how to use Rust, you do not create OOP garbage and claim rust is hard, you don't create a mess with C styled procedural hack and whine about life time and asyncs destroying you, no no no. Only correct way of working with async rust is ECS (Entity, Component, System). It works really great for UI, perfect for games, and certainly good enough for servers. It eliminates the life time coloring entirely. Even if you use lifetimes, AT WORST you'd do something stupid like having them on a component, then it will pollute only the systems which use them, and the system manager. But it can easily be eliminated. It eliminates most clones as you wouldn't be fighting the borrow checker, and the mutable shared state exists in a single thread. It baffles me why people are not using ECS more in rust. Some good implementations exist, like bevy for games, and I have heard people behind Warp use it extensively, but nearly not enough. Most rust servers to this day are massive shared states with very many Arc mutexes, then lifetimes and everything adding to the complexity! You can't use a language wrong and then complain that it is hard. It is hard like you use it, because Rust's compiler specifically want you to avoid doing what you are doing. You are fighting the language with 'hacks', of course it will be pathetically difficult! The goal of rust is no to accept all 'safe' code, but a subset of safe code. You have to just understand what that subset is, and you will never feel pain of using Rust. Background: My first programming language was really GW-BASIC (if you don't count LOGO), then I taught myself FreeBASIC and C. During the HTML5 gaming boon in early 2010s I learned Javascript and Typescript and started making games and a few game engines, which lead me to making servers for them, and learn Rust. I have done fair bit of C++, Java, D, x86 assembly on Linux, and sadly, even some ruby. I have also implemented a lot of toy BASIC-like languages with backends in C, C++, and assembly, and even toy interpreters during early teenage years. My first reaction towards how pathetic javascript was, was to create a BASIC-like language transpiling to JS in C. There is nothing like Rust for sure. The confusion around which architecture to use with Rust is causing all the problem. And because of that, most rust code i see looks nothing more than 'hack' around the rules of the language.
Here is the thing! We technical guys care about speed and developer joy and pain. Companies don't. Literally no ones who has the money to found your dreams cares. I have got so much in trouble reporting things that don't work, security shit, performances issues that I just gave up on trying to improve anything at any company.
As a long-time viewer/subscriber this pushed me to stop following him on Twitch. I've heard him talk down so much on his viewers (among other things) that it's really rubbed me the wrong way.
Listen, I don't follow his streams, I mainly watch the youtube stuff. I don't hear all his statements. But... regarding people not doing "hard stuff" all the time: that is just objectively true. If you've been in the industry for long enough, and seen what happens in most companies, this is just an accurate take.
@@peculiar-coding-endeavours I'm not arguing the truth of the statement - in fact, I agree. What I'm saying is that he comes off as condescending and belittling.
Rust has a lot of tools like write on clone, Rc, etc, that you can use to simplify things in return for slightly less good performance. The problem is that people worry about doing things the "right" way with lifetimes when it doesn't matter for performance and makes the code worse to write. (If you aren't measuring or know for certain from experience that it matters a lot, performance doesn't exist.) So easy people make it hard actually applies to a lot of haskell code. People end up reaching for cool monad transformer stacks or effect types when what you need for a brain dead API backend is just a reader io monad and STM. Maybe the capabilities library to have a nicer RIO experience.
Does it even make sense to compare an interpreted, garbage collected language to a compiled language with explicit memory management? like, imagine writing some software that must operate under real time constraints, would you use Java and its garbage collector which starts and stops unpredictably, or Rust?
One time I tried out Java to make a Minecraft mod, and I swear it took me like maybe two or three hours to get Graddle to work, and when it finally did, after a few more hours it just stopped working and I could never figure out why.
I'm a C# dev and I wanted to play with Kotlin. Graddle and Maven were such brick walls for me. Like 30 different tasks are there when you create a new project. I just want to run it. In C# you just hit F5 or "dotnet run" in terminal, and that's it. "dotnet publish" for release build. That's it.
Do people still use Maven/Gradle for Java? I just remember being miserable using them (especially maven) when I used to work on Java. Cargo so far has been seamless, I like NPM too but I'm not sure if it's stockholm syndrome.
With rust you can't bang on the keyboard like a monkey. You have to solve the puzzle - that's one of the things that makes it great. Once the puzzle is solved and the code is written, it is extremely easy to read what is happening.
I don't speak or understand English very well, so I have to put your videos at 0.5x and repeat parts of the video over and over again to understand better, the subtitles don't give a good translation and although sometimes it takes me more than 1 hour to finish a video and I try to watch it in full. Simply because you have good content and interesting opinions, it distracts me sometimes when I'm coding, thanks. "PS/ I used gogole translate I don't know if I said some weird shit lol"
I realized that the more I understand Rust's macros, the more unreadable my code becomes. I am currently working on a small math library and I got to the point where almost the entire code base is macro calls, procedural, declarative, derives, the entire lot. So yeah, there is almost no repeating code, but debugging is a nightmare and making any changes is almost impossible. And it's not just me, if you look at a lot of libraries, they are full of macros everywhere. It's almost as if Rust encourages every project to have it's own DSL which makes it so hard to maintain.
Huh, I don't know if I agree that "a lot" of crates are "full of" macros, but that's pretty subjective and depends on what you've looked at. Generally I see macros used for what it's good for: really repetitive code, saving more than 100 lines. What confuses me in libraries tends to be the trait bounds gymnastics where whether you can call a function end up depending on 40 different traits.
@@SimonBuchanNz I've been using rust mostly for writing math libs, and because you need to declare things for every single num type, all the math crates uses macros heavily.
Some suggestion for improvement: - don't use an array, but the IntStream - use IntPredicate, so there is no autoconversion to Integer object - put that inner function into it's own method
Doesn't matter which language... the question should always be how good quality is your application. If you obsess too much on choosing the best language, but write terrible code/logic, Java or whatnot isn't gonna make you a better programmer.
It looks like Rust tries to be C++ but without going the way C++ went last 20 years. Well after 20 years it would be universal language if it survives.
There’s a dialect of C++ that adds the Rust style borrow-checker. It’s definitely stirring the pot and being looked at. In ten years C++ will probably have borrowed checker and pattern matching. C++ templates are way better than the combo of Rust generics and hygienic macros. No limit to what can be devised with templates - such as containers. Compiler is able to do better optimization with templates as it sees everything. And C++ is way ahead (except relative to Zig) on constexpr kind of compile time evaluated code. More and more of std library will keep getting reworked to better use constexpr where ever possible and concepts.
@@TheSulross "C++ templates are way better than the combo of Rust generics and hygienic macros" Elaborate. Because I have experienced template hell and would like to not experience it again.
@@khai96x hee, hee - they’re [C++ templates] not simpler to use (from user perspective) but they allow for better compiler visibility into the nature of the code and hence facilitate better code optimization, and hence performance. Now with C++20 and some other recent new template related enhancements, they are getting better in terms of writing templates (vs just consuming templates via, say, the std lib stuff) That’s the big contrast to, say, type-erased generics that are in languages such as Java or more recently, Golang. The Rust hygienic macro feature, though improved over C macro pre-processor in some respects, is still not as sophisticated as C++ templates. C++ templates get criticized for being a language within a language, so to speak, but Rust macro feature is also alien to its host language. (The new C++ reflection feature coming in C++26 will augment nicely with templates - probably will be more impactful than Concepts.) But meta-programming in context of any language means stepping off into needing certain things that the language proper doesn’t address. Zig is one case, though, where one just uses Zig language for meta-programming too. I think it already has some things that are only relevant in meta-programming context, though - so will be interesting to see if there is pressure to better accommodate meta-programming in Zig with things that are only available in that context. (Zig build files also written in Zig and comptime stuff same sort of simplicity. Definitely interesting to watch how this Zig simplifying philosophy goes.)
@@khai96x He's just wrong. C++ templates are hell. I used to love C++ but the language is too large and complicated now to be saved. Adding more stuff to it just makes it worse. It's not like you can forget about the old stuff, you still have to know that and the new stuff too. If you're starting a new project, you might as well start from the clean slate that is Rust.
The concurrent hashmap is really good, I can agree, when I was building my key-value store, at first I didn't know about it and when I found out about it...
I work writing banking enterprise software. The app is about 8M LoC java with a decent amount of legacy (20 yo system). Even though many efforts have been made to keeping mental overhead low it is by no means trivial, and this is a problem that is almost impossible to overcome with idiomatic java. For a system of this size I would much rather have rust and learn the language features than the mostly required incidental complexity. Ive written rust professionally for about 6 years and would def not agree that java scales better at this size. I would say java does win scalability until the system becames exceedingly complex. But a fund trade system where things casually have 7+ layers of inheritance is hairy at best, and error prone. The flip side is its much easier finding good java developers than expert rust programmers. So from a business standpoint java probably still wins.
One area that Rust certainly beats Java in is the ratio of hype to lines of production code.
Hype to Production is an important metric. How else do you keep your team motivated to the finish line?
@@voidwalker7774 try more coffee, office pool tables and money?🌚😅
Yeah, because the amount of boiler plate and base class you write can surely bloat up loc 🤣
I do my best
Haahahaha!
P.S. I have Java tshirt and love piss random people off by wearing it.
I don't like how Java is associated with pointless abstractions. That's the choice of the developer, not a requirement. The Java community might have a cultural problem in that regard, but it's not a valid argument against the language itself.
Well, language itself has fairly decent amount of problems
All that mantra about everything being an object (except for primitive types) quickly gets old.
Why can't you just define function without turning it into a static method of a class. It is already a pointless abstraction
that is Uncle Bob Java dialect
the JDK team has mantra - when in doubt leave it out
most enterprise kevel software is written in java
C# has structs, so there's a value type as well as a class reference type. However, in both languages, you are forced to use only reference types (in C# if the library used uses classes instead of structs). Also, finalizers are not destructors, and don't work well for resource management other than memory. Yes, I could craft a non-idiomatic program that gave me the control that I want, and side step the abstractions, but it would be a nightmare to maintain. There aren't many programming languages that I don't know, so I have a choice of what to use. Kotlin is better, but still stuck in the same abstractions. I'd rather use Rust any day on any project than anything on the JVM. The issue with any abstraction isn't that it's pointless; it's that it's limiting.
Forced OOP is already a pointless abstraction, and you can't scape it if you use _any_ library. On top of that, if you work with someone who does Java, you are basically required to do it the "Java" way because most people follow the abstraction design patterns that are prevalent in the language.
About complexity: I wrote a 3D game engine and physics engine in Rust using just raw Vulkan, as well as countless of complex algorithms (such as full body inverse kinematics). All of these things were very easy to do in Rust. I also wrote a web app (frontend) in Rust and it's the most complex piece of code that I've ever written. The amount of cases you need to handle when dealing with asynchronous behavior from the user, async loading of data, server-side-rendering, etc, it's mind blowing.
that's just how rust is
doing low level stuff in rust is very easy, but as soon you hit the coloured functions everything explodes
@@aeghohloechu5022 boxed futures are somewhat of a workaround but that introduces it's own level of complexity. in most cases it's better to just deal with function coloring.
javascript also has the same problems unfortunately. elixir phoenix with liveview is the best solution to all of those problems. rust for the frontend would only make sense if you need a high performance backend and also for mission critical backends. elixir is good enough like go for most use cases.
Rust and a game engine that was never used for an actual game.
Name a more iconic duo.
@@Nors2Ka vulkan (if that's what you were talking) isn't a game engine, it's an API and it is used in big games.
Hot take:
The best programming language is the one that pays the bills.
exactly mine thought too
so excel and vba.
in the real world yeah but this is for funsies
That's literally ABAP and COBOL, though...
👏
Prime is just about as qualified to talk about the modern java build system as the article author is to speak about the rust one 😂
How so? Did something fundamentally change in the Rust language like it did in Java build systems?
@@paxcoder since 2018, a lot. But just like w/ Java it's hard to notice if you're not in the midst of things - you don't have to use sealed interfaces with records, and you're likelier to find tutorials not using those due to large history, but you probably should in new projects. Same goes with rust - you won't notice polonium in half a year if you're new, but if you're familiar with the language you feel a huge improvement. There's a bunch of tiny things that get merged and features that get partially added but if you removed all improvements since last year after getting used to them you'd feel them missing.
@@Caellyan Where does 2018 come from? The article has no date, but it first appeared in the WayBackMachine this month (his page was first indexed by google in ). The author's last commit to his own Rust project was 4 months ago as far as I can see.
P.S. Is the chemical element an autocomplete mistake? Or are you referring to the rust framework?
@@paxcoder Afaik, since 2018, Rust has been operating on a 40 day release schedule, so improvements between releases are usually small and hard to notice if you're not actively trying to learn new parts of the language.
Also I'm pretty sure they're referring to polonius, the upcoming complete rewrite of the borrow checker which will be significantly better at validating the safety of many uncommon but useful borrowing patterns that previously required the use of unsafe to circumvent the limitations of the current implementation.
Holy run-on sentence, sorry.
that's a great short depiction of 99.9% of software dev influencers
Modern Java (version 21 and above) is truly impressive. If your opinions are based on experiences with older Java versions (prior to 21), it’s time to reconsider. Give the latest version a chance-you might be pleasantly surprised!
@@vinothmanoharan6111 sounds good, I'll go and download it now. Wait, what is an oracle account? What is this agreement I am signing up for? Yeah I know about openjdk but oracle is a good reason to stay away.
This. So many people shit on Java because they used Java 5 10 years ago at college lol. Chances are your language of choice sucked too or (didn't even exist yet). I see this most commonly with C# devs which makes no sense.
@@hellowill I remember when Java folks belittled c++. This is just how things go.
Can java21 be compiled and run standalone ?
@@CaptainDangeax It can, actually. This can be done with the GraalVM Native Image stuff. IIRC it can even be statically linked, although I'm not really all that familiar with that process.
Of course, in most cases you'd probably still want to have a separate JVM, but especially for cloud functions and such, GraalVM can do it for you.
[]interface{} is not Vec, it is Vec (add Send + Sync + 'static if you want…).
Prime when The composite walks in..
Nl ass joke
It's hard to watch language reviews now because it's all purpose driven. You can smell app dev, you can smell web dev, low level systems, you can smell frontend and backend. No pun intended. I picture 4 dogs on the sidewalk doing this. I'm not looking for one ring to bind them all. That war gets ridiculous.
But that is what we're looking for, isn't it?
Partly because devs don't want to have to learn 5 languages to stay relevant and partly because companies(probably) want to keep their technical and training requirements as lean as possible.
@@huuhhhhhhh Yes. The vast majority of end-use case, companies need a maintainable code base, and a pool of employees. Continuance. That would be js/ts, if you want a job in mainline business. If you want to escape the browser, it's a different world. No, I don't want to paint the world in React.js. It's actually a dumpster fire. I chose Zig for tiny embedded. I found limits with Rust. Java? It's great but I need to compile. Java's competitor is Go. You see where I'm going though. A tangent into trade-off land. There's never gonna be one ultimate language, but companies don't care.
I did my undergrad dissertation on functional programming in Java 21 and it's super cool. Sealed classes, records, type-match expressions, better streams, more control over the gc. It's all surprisingly ergonomic and well-considered.
I like Rust too, though I use it less. I think the comparison is interesting because both are sorta supposed to be a simplified C++, but with completely different aims within that.
IMO, Rust was co-opted for application programming but was intended for systems. There was this strange 3-way conflict between the designers, library maintainers, and end users, where each thought they were using a different language. For systems programming, Rust is elite.
But nowadays I mostly use Clojure and very occasionally one Java glue file.
Somehow I get the impression that prime did use async Rust wrong...
Yeah, async traits made stuff much easier but he always talks about arc and never mentions channels...
Also writing Rust with a data-driven mindset is muuuch easier than most OOP I encountered
Most Javascript programmers are incapable of grasping Rust's generic type system.
@@stevenhe3462 Just like most Rust programmers are incapable of writing safe, low-level code without an overengineered type system
@@catto-from-heavenThis is your own skill issue, don't project ;)
@@ITSecNEO I use C. Don't assume
@@catto-from-heaven So even worse, you only spread misinformation xD It's easy to write low level code in Rust, that's the whole point of Rust lol It only sucks for higher level projects and Async stuff
u would so love Kotlin
I'm waiting for so long for prime to try out Kotlin, it is such a pleasure to write kotlin code
Everyone stays sleeping on kotlin. Goat language
@@giuliopimenoff Exactly, using it for 4 years for everything(web backends, android apps, minecraft mods, etc) and never ever I had something like "oh, that thing is so bad, I wish I could do that like in language X". It's actually quite an opposite, e.g. I was so mad 2 days ago when I discovered that in TS you can do Map.forEach(), but for whatever reason you can't do Map.map(), instead you have to use workaround with Array.from(Map).map().
Lucas Montano do canal Lucas Montado ❤
it so fun() :)
As someone who has written both Rust and Java professionally I would argue that Java works great if you stay in the Java ecosystem. As soon as you want to have interoperability with anything that is not a JVM language it gets a nightmare really quickly. Rust on the otherhand does integrating with other languages and ecosystems exceptionally well, create JS / Python / R bindings for your lib ? No problem ! Import that one C/C++ lib you really need ? Eazy! Run the same Code in a WASM environment? Also trivial. All these examples are really painful to do in Java.
To be fair Java doesn't compile to object file. Thus calling native lib from Java is hard, and calling Java lib from native implies running JVM within your process. As Primagen has stated in this video, Java is application level language, and integration in server room is done using app level protocol and not by loading java library in virtual memory of your process.
Did you try graalvm? I found it astonishing to have the same object in R, python and Javascript.
@bariole
@bariole I really don't like the notion that some languages are application level and some are system level, etc. This is an arbitrary distinction that mostly boils down to personal preference, skill and/or the tools and libraries available. Sure, some languages are better for certain use cases, but if you compare Rust to Java, I would argue that if you have people with similar experience on hand, you could build most standalone applications reasonably well with either language. Also, the argument that Java is interpreted is not really an argument for why Java makes it hard to interoperate with other languages. Python, for example, is also interpreted, but makes it much easier to integrate languages with a C ABI.
>Rust on the otherhand does integrating with other languages and ecosystems exceptionally well
LOL it's FFI relies on "C", so it is as good or bad as any C - binding to other language is, that is BAD. just take a look at how the signal core rust library connects to Java via JNI or Swift ... Yikes. makes we wanna puke.
Oh you meant, you can call "C" .. well congratu-f***-ilations, every damn programming language can do that.
@@agooodolecoder What are you even talking about. C ABI is dead simple and every language that wants to interface with system libraries needs it anyway so that's what is used as the common interface in a lot of cases but it doesn't mean you have to do it and it also doesn't mean it's bad. I'm calling C++ virtual class methods directly from Rust and Rust types with trait impl from C++ via a different ABI for example.
Readibility is largely down to familiarity. I find it far more readable because i know what 'filter', 'map` etc are going to do even if not specifically *how*. Just seeing the coarse-grained operators I can get a pretty good feel of what's going on where the loop could be mutating anything anywhere.
Not only is composition easier, it makes it harder to 'just add a boolean flag' to the loop that invariably goes out of control with complexity.
And it *is* a builder! You're building a pipeline of operators that you eventually call with a 'terminal operator' like `foreach` or `collect`.
I'm guessing you're referring to Java since it sounds like you're replying to the article and referencing the fizzbuzz example, but as a Rust guy, I just want to say that your comment could just as easily be referring to Rust's iterators.
and apparently rust has predicates, i went down the path of trying to write rust declaratively a while ago, (I dont code rust), it all came back down to, is this the rust idiomatic way? and that ended up killing my journey with Rust at the time. Gotta start banging me head on it again, maybe once I go braindead I'll be happier.
@jazzycoder It's mostly used on the backend.
As far as Hindley-Milner types - for any mature enough to look past blind Microsoft hate - F# is actually a really good language taking learnings from Ocaml, has the HM types, has all the .net ecosystem, can do object oriented as well, etc.
Yep, F# is very very good.
@@chrismeyers5665 I love f#. But it is tough finding other programmers to consider it. There is some ugly things in the language but it is pragmatic and very useful.
Blind Hate 🤡
No one mature enough is able to ignore *THE* Microsoft hate. Now get off my lawn!
"it's so difficult I've been there" I lived there it was awful, I essentially still live there understanding these ridiculous architectures that have to be supported is incredibly challenging. Working in finance was as close as I got to real-time and for me game-like programming. Where milliseconds matter.
Any arguments against Java should include the last version of Java the person making the argument has used. There are certainly some fair critiques, but a lot of people are simply stuck in the early 2000s and haven't bothered to update their language knowledge over time.
Turns out most codebases are stuck in the early 2000s too, so it's pretty fair
Turns out most production code is still written in old java.
@@zesky6654 So what? Soon there will be a lot of code written in some old Rust edition code too.
@@koh-i-noor123 No it wont, cuz no one uses Rust lol
@@zesky6654 examples?
As a Java Spring Boot developer and someone who wrote a game engine in Java, here's my biblically accurate take on Java:
+ very easy to read code
+ simple build and dependacy management tools
+ great out of the box support for: networking, multithreading, string operations
+ heavily used everywhere, plenty of tutorials on practically everything, from computer graphics to game development
- no operator overloading, difficult if you're dealing with lots of math
- dynamic binding and auto boxing. ArrayList can fuck off. Why can't I just ArrayList?
- many possibilities for abstractions that obscure what the code is actually doing
- JVM takes a few seconds to boot
Verdict:
Java is the Chad's language of choice. You will not get the incel Budge of Honor like Rust + Vim users, but you will get something done and get paid for it.
maven can be frustrating and is missing a lot of core features without plugins which basically requires a ton of research on how to do & configure x thing. though from my experience same can be said of e.g. cmake
I think autoboxing exists because it's generic code. Instead of having to handle differently-sized primitives in builtin classes at the language level, most 'std' classes opt for being generic classes the user themselves could write easily and you don't have to reimplement e.g. Hashmap nodes for every differently-sized primitive. You just implement it once for objects (references/pointers).
the last point: isn't graalVM even fixing that shit to some degree? (not sure, just read about it but didnt test it yet)
regarding the build and dependency management tools... depends on what you wanna do, they can get pretty complex fast, especially if you dont really know what you are doing. but starting out with them is easy, yes - although maven is sometimes clunky and you have to deal with all those plugin shit stuff (but gradle exists too so its fine i guess)
@@MrLordLowbob Don't know about GraalVM in that context, but Project Valhalla introduces value objects.
"Why can't I just ArrayList?"
Because bridging the gap between primitives and other types requires a huge effort. However, it is underway, check out JEP 402 (Enhanced Primitive Boxing).
It will enable ArrayList.
Even whan that is completed, Java will still use autoboxing under the hood. The next step will be resolving that, so ArrayList actually uses ints - that's in the pipeline too, but further off.
@@yfjolne Graalvm isn't widely adopted yet, I've never used it so it's hard for me to say how beneficial it is and for which project.
Project Panama and Valhalla for the openjdk look good, but not out yet.
there are 2 types of programming languages
- the "good" ones
- the ones that are used for 30 years and still in top 3
2 years until javascript is in the second category
Let’s go JS, Python, and Bash 🥳
@@houstonbova3136 you forgot HTML "programming language"
@@oussama7132 i don't have no problem with JS
when its used for it was created for
so c++
Haven't watched the video yet, but having spent the last 5 years developing in Java 8 and JUST NOW getting upgraded to Java 17... I am intrigued...
Go right up to 21, lack of pattern matching is just weird considering it already has sealed types in 17.
Jeez going to 17 instead of 21 now? I mean congrats on moving past 8 but what? I've heard of n-1, but lts-1?
I've been doing java for 16 years, and I love it!
Liked for the primeagen callout in the article
When I see thepigeon videos, I go to description, open the article and read it. Saving 30 mins everyday. He is the best to find beneficial content!
java 100% is... open the same piece of software and read the code in both langauges, and measure how long it takes for you to figure out wtf is going on
Counterpoint: It's less fun to write. Life sucks if you aren't having fun.
@@MaybeADragon You can absolutely have fun writing Java.
Having fun in Java does not usually help the readable code though.
if you want to have fun writing java just write it in kotlin
@@MaybeADragon A bit subjective tho. If you hate writing Rust, but tolerate writing Java (me), the opposite case will be true.
@@marv4054 yeah i'm using kotlin since beta days, introduced it in every company i been to... i just dont want to shift conversation to kotlin, but its funny that every complaint people have about java is fixed by kt
Java is designed to be a very generic language and I think it did pretty well
Java nailed interfaces. If Java just had interfaces and never had inheritance no other language would exist today.
@@nakatash1977 how would you do systems programming then
@@gs-e2d Holy C
@@nakatash1977 they copied from delphi. Although I'm sure delphi copied something else. My point is that Java didn't come up with it. Not that it is bad to borrow good ideas.
@@nakatash1977 It is up to a programmer whether to use language feature or not. Java doesn't even require to use OOP
This channel is insane, I feel like it has woken me from some kind of serious depression related to the downward trend of the world at large. It has inspired me and gotten me genuinely excited to create again, to care less about the stuff I have no control over, and to immerse myself in the stuff that I have intense, granular control of. Very, very glad you are out there Prime.
Why are we pretending that you have to use inheritance in java? just quite literally forbid it. Thats what we did at my job and its just a better go at that point
Why Inhertiance has good applications where it needs to be used.
Sometimes you want to use Inheritance to prevent a class from having too many methods...
as a minecraft kid, i have an interesting relationship with Java as i learned more about it from the periphery. JVM, Garbage collection, memory allocation, i barely know what these are, but i've had to fix them in so many weird and interesting ways over 7+ years.
now MC Java mods are 50% kotlin tho heh
The Rollercoaster Tycoon example was perfect not because someone _could_ write it in assembly, but because Chris Sawyer in fact _did_.
It's also like people say: "Yeah but writing in native Assembly is much more efficient than relying on a compiler",
No it's not, it's only more efficient if you can write better Assembly code than the Compiler.
And most programmers that were born in the last 30 years probably cannot actually write better Assembly than most Compilers.
You can dislike Java but you've got to admit the JVM is an exquisite feat of engineering.
Yup, my dislike for Java has always been the language and not the JVM. I wish Scala was more popular.
@@username7763 Scala is too complex and when applied to masses the way Java is used it results in even worse software projects. People forget that most software projects are not made by excelent engineers most software is made by average engineers and it takes way more effort to learn how to use Scala to not shoot one self in a foot than it takes Java.
@@sk-sm9sh The vast majority of software is many times more complex than any programming language. If using a more complicated language means you end up with simpler code, that is a worthy tradeoff. The only way it couldn't be is if engineers aren't bothering to understand the code. But in that case, they aren't engineering.
@@username7763 more complicated programming languages typically have more features that can enable more ways to cut corners. Using more complicated language will only result in simpler code if you take best approach. Using more complicated language almost always result in code that is messier in most software projects because in most software projects there is lack of discipline.
@@username7763 you can call your engineers not engineers if they don't completely understand the minute details of every overcomplicated feature of the language that is used to achieve ideological purity or appearance of cleanliness and simplicity, but it's just a fact of life that they will work on your code. Human resources are rarely perfect, and languages exist to adapt to humans not vice versa. Blame doesn't matter, only achievable solutions are. And solving this problem by only ever hiring perfect people can be less feasible than choosing a different language that doesn't require people to be as perfect
Oh man, I watched 10 minutes and noticed I'm actually tired of this. It's so repetitive... why compare Java to Rust? Rust is a systems programming language without GC. That alone means that inevitable some things will be harder to write and definitely plays a role in the necessity of macros sometimes! Also, I wonder how many people that complain about async rust have written async C++. That would be a meaningful comparison.
Funny. Cause the video addresses your point a number of times.
The reason for the comparison is because you keep using rust for things that you’d be better off using Java or go for.
@@wredue3733 First of all, I still disagree. I've used Rust a lot (sync and async) and definitely would not go back to go or Java for anything where reliability is even remotely important. Nevertheless, "Rust is used in areas where other technologies might be more suitable" is a debatable, but reasonable stance. That is a VERY different statement than "Java is better than rust" though ,which is literally the title of the article. So if that's what they were trying to say, their communication skills are apparently even worse than their coding skills.
The thing is, personally I would prefer to use Rust over Java every time because of the build system and type system. Also, most apps don't need to be async anyway nor do you need to write macros that often. So I don't understand why writing "actually useful apps" means doing those things.
Java gets shit done.
How it get's things done is a whole different story
@@OzzyTheGiant good one
@@OzzyTheGiant It gets things done quite well and efficiently actually.
very slowly
@@_khainenope , the hole Jenkins and k8s client runs on java
Well I love the verbosity and compile time safety of Java. When libs use ASM byte code modification with annotations, stuff like Spring Boot has minimal boiler plate code. JPA finders in spring wrapped ORM are so minimalist am not sure you can code faster than that in any other language. So I find Java rocks more nowadays than it has ever done. I ❤ Java.
Byte code modification, annotations and Spring are precisely the worst things about Java. It’s not about code golfing, it’s about code thst works. And all this bullshit magic is just the recipe for constant disaster. Which of the hundreds of magical annotations broke the Spring context this time?!? I hate people use this shit, who like this shit, and who think that this shit is productive. Golang attracts people for precisrly the reason it has none of this bullshit magic
You should try new Java Stuff, you will appreciate the language more, I do think your opinion is miss a little bit because the memory you had about Java is "applet" and 1.5 stuff.
I'm not at all ashamed to say that I really enjoy coding in Java.
The only reason to pick Rust over Java for some huge grug business project is for your own job security. If you actually get something up and running you're the only person who's ever going to understand it and never get fired. Choosing Rust Drastically reduces the amount of engineers who can work on it.
@@ShootingUtah this is partially true but also unfortunate. I've learned many language and technologies in my career simply because someone had to maintain a project after the original authors left. It's hard but not that hard. I just don't understand the mindset of programmers not wanting to learn new, and old, things.
Perhaps, but by that metric JavaScript is possibly even better, but really you should be writing in C++ or Python.
In practice, every team has different experience and expectations, and different problems they need to solve. It's quite possible to have a problem, even in a big grug bushes project, where 10 lines of Rust beats the pants off of several thousand lines of Java. Or vice versa! Being a good engineer is often about being able to predict that sort of thing.
Not arguable.
If your job security relies on the fact that you need to be the only one who understands that code, it might be a good idea to switch the job.
@@stevenhe3462 said after two arguments
rust has some things that are inherently difficult, but i think most of what makes it difficult to learn is that it's an entirely unique paradigm. it makes you feel like you know nothing again. whereas the majority of other languages have similar concepts. i think if more languages had a borrow checker the reputation of difficulty would be lower.
Yeah but like that just is a negative of Rust.
Why reinvent the wheel when C++ does the job?
@@teaser6089 if it did the job a borrow checker wouldnt be necessary in the first place
@@teaser6089 you are showing your low skill level if you think rust has reinvented any type of wheel, you must be thinking of zig
Would love to see prime struggle with setting up a Java environment in neovim. Good stream idea and I'll copy-paste it when it's done.
Java just keeps reinventing itself and beating other languages, for example with native threads in Java 21 improving the performance of the virtual machine. I think that's the kind of feature that could make it a great alternative to "trendy" back-end technologies like Node.js
However Java currently needs a React framework killer too, for the front-end applications that use that cursed technology. We used to have strong alternatives but they aren't updated for the single page model. Front-end usage of Java really fell off the charts by the time Java Server Faces was released (previously lots of coding was done on JSP and Jakarta Struts for example).
if webassembly cant fully beat js in frontend, then java version will not i think, just like c# blazor. webassembly excels in runtime performance but slower in initial loading and slower in development cycle than javascript and creating highly complicated interactivity is very complex. no one will fully beat javascript in frontend in couple years unless webassembly initial loading speed is solved with different strategy than previous ones and making it much less complex to build highly complex interactivity to the point at least match javascript's if not surpassed, then I can really see it will take over javascript in frontend
After the amazing success of "PHP is now good again" now in theaters: "Java - the next hot thing?"
I am writing C++ code for a living and many Concepts regarding the Borrowchecker are various footguns you learn in C++ the hard way. I was positively impressed how Rust just enforced that.
The vast majority of criticisms of rust that I see are people who mostly write Java (or Python, or Javascript, or Go). They usually write some kind of simple web application back-end and the complaint usually goes "urgh this language is such hard work, why do I have to jump through so many hoops!?". However, if you write ultra high-performance massively-parallel code and your only realistic alternative was C/C++, but you need it to be right and not crash. Well then you can start to appreciate the real strengths of rust.
@@tomshackell The drama surrounding the Linux Kernel Rust integration has shown that you can add C programmer to that list. But they argue from a different point of view.
One valid criticism here is the different way of thinking and structuring of your code. Another point seems to be the stiffness how Rust (the compiler theirof) demands you to do things the Rust way.
I also don't like how the complexity of the language itself (adding lifetimes, async, borrowchecker, ... etc. on top of each other) rivals C++ without the legacy.
I haven't used Rust for bigger/complex projects only C/C++/C#. To me the whole "Rust is bad" and "Rust is good" debate is (1st) jumping between not knowing the languge (or how to write data oriented code) and (2nd) using Rust for things it is just not good at.
@@TanigaDanae Agreed, Rust is a complex language. I personally don't find that surprising: it's a language that provides the performance and low-level control of C, but without the inherent unsafety of C. Strangely that's not easy to achieve and comes with some compromises.
I have used Rust on a large commercial project. It's been very successful: because we use it for what it is good at. Dealing with highly complex software running on machines with 100+ CPUs and 4TB of RAM. The language is complex, but that complexity is nothing compared to the demands of our domain. The language is easy by comparison and the safety it provides (especially thread safety) is such an enormous win that it's worth the complexity.
It's always been possible to knock together a simple CRUD webservice in C++. However people didn't generally do it because it was overkill. Rust is nicer to use than C++ (IMO) .. but it's still in that same category. It's a difficult complex language designed for solving very hard problems where performance is essential. Most people don't write that kind of code .. but some of us do.
That mention of needing to refactor a rust application after adding a new string to the mix gives me the same kind of vibes to needing to add in a variable in an Elm app on the front end. I need to add this one thing, but it not has to be strung through 27 functions and handled at every step of the way before it can compile again and my IDE is screaming at me the whole way.
Thankfully in Rust you can always just throw it into an Rc (the rust equivalent of the average variable in Go) and you don't need to deal with any of the lifetime stuff nor have to worry about performance when cloning etc.
Unless the string is large I don't understand why you wouldn't just store as String::new() and clone it. If it is a large string then you're probably making a major change to the application anyways. Plus Rc or Arc is in your toolbox. Although to be fair if you need to mutate the shared string things start to get ugly Arc or Rc while require you to clone the smart pointer then lock the mutex are not ideal..
I went from over a decade of Python, and only thing I'd used (other than some MC modding back when it was in Beta). And I found Rust just clicked with the way I like to program, and it's all because of the borrow checker, it made things feel very easy to learn. But I think that's just because it feels like the way Rust works, and the way my brain works are pretty aligned.
java literally gives me anxiety.
No refererential transparency. You cannot trust that some code will not perform spooky actions at a distance. And the code takes so long to read that my brain runs out of memory before I understand what the code actually does.
Rust is ugly as hell to me, but at least I can read the code without falling asleep before understanding whats going on and I can trust the code without getting anxiety about spooky side effects.
While async rust is hard, Actors make it quite easy to reason about once you understand them. They also seem to overcome the lifetime stuff. Channels and message passing in general makes rust so much easier, because you avoid shared state a lot.
I use java for work and actually kind of like it
My biggest issue so far is inability to have real compile time values. And tbf my issue with most modern languages is lack of pre-processor stuff. At least in C you can make pretty much anything with macros.
Rust macros are great! They are typesafe code templates with cool pattern matching and repeat args. If you need more, there is a 2nd kind of programmed macros, that can, at Rust compile time, validate HTML passed in, or connect to the database and validate your SQL, as well as establish the types of in and out values: so many avoided run time problems.
Java is so much easy to use, and have so much stable and mature libraries. I do not want you guys to use Java, I use Java it make me so happy, I do not want to share good things such as Java programming language to you guys because I am so selfish. so, I would tell you: Java is a so bad programming language! do not use it, please!
JAVA MENTIONED BOYS
I’m a C++ systems programmer so Rust is perfect for the stuff I do.
The product I work on is a library for mobile and embedded database software, so performance and memory safety are really important. Rust would be super helpful.
Currently writing a log parser in Rust to parse all of the text logs we receive from customers, and write the parsed data into SQLite. I think Rust is really great for that too because it’s mostly “simple Rust” apart from a few custom proc macros to reduce code duplication, and the data types which get written into SQL are verified at compile time.
"I'm not biased". Proceeds to define bias.
Getting a good injection mold design going is typically harder than getting a precision gear made. You still need extremely high precision machining for the mold, and making a good moldable design for something non-trivial requires a significant body of knowledge. And then, you need the molding equipment. You also need some specialized tooling for precision gear grinding, but overall, from soup to nuts, I'd say molding a run of parts is a harder process, and if you're asking someone else to make your parts, more knowledge is needed for the injectionolded design.
Java can get me a job. Enough said.
Human trafficking is also a job, technically 😜
@@alakani 💀💀
Bjarne Stroustrup the c++ developer said , if i was in my 20's in 2024 , i probably learn all the different programming languages because i love learning them , i'm not going to be a person who is doing sales job and then learn one programming which pays more for earn more... because this is not going to last long.
Exceptions aren't for error handling. They're for reporting unexpected errors. They're like panic in golang. That's why checked exceptions turned out to be a bad idea and APIs now tend to allow for handling expected errors like parsing JSON from outside or making a network call without using exceptions.
At the same time, unexpected errors like local configuration JSON broken are still best handled by letting an exception fall down the stack.
Lately I have been obligated to use java for a project that requires very high performance. I just keep desperately searching the internet for a valid reason to not dislike it but I did not find it here :(. Most of the libraries are poorly optimized because the way you abstract things in java is adding almost always indirection levels (you can not have the equivalent of a list of struts without some black magic for instance) and support for proper ffi and vectorized instructions is still in incubator, project Valhalla still not finished... so it feels that it's way behind from rust and Zig and other languages in that regard.
Also back in the day I did enterprise backbends in spring, and this is anything but simple at least if we talk about what happens in runtime.
Yeah I recently started having to deal with spring. Validators suck.
yes it is possible to get good performance but you basically have to take apart existing classes in order to do so and create your own implementations of interfaces. Of course nothing close to nitty-gritty low-level optimizations like vectorizations but at least it will be 'fine'.
I had to repurpose some apache poi class to stream an excel spreadsheet while keeping memory low, and take apart/reimplement parts of SimpleJdbcInsert from spring in order to support uppercase postgres table names before ditching it and JdbcClient entirely because their default implementations created too many objects, namely large maps with wasteful properties we had no need for (uppercase and lowercase indexing of 'result maps') in every query
and if you want to do anything remotely realtime, forget it. but that's mainly bc of the runtime and garbage collector.
I think java can be performant, that's why kafka is written in java, but you need to do some dark magics
I think Rust is valid as an Application Language. But the hard part about that is writing the Rust Libraries to support App Level code. Reading or writing a function signature with more than 3 trait bounds, or whatever they're called, can be hell, trying to keep all that info in your head before even reading the function is hard.
that's my take on it as well. the only thing i would slightly disagree with is that most applications don't reach that point. most of the rust code i've written has a create for something that already abstracts away a lot of the complexity. of course you do have to sometimes do things on your own and that's where i agree.
I don't agree when you say rust is an "all the things" language, I think it is a "mission critical" software language, if the software is not mission critical, then there is probably a better choice.
I would call it "performance critical" instead, it doesn't have to be a big mission, but it definitely crushes performance, and you can use it for a small part of your app, you don't need the entire app using rust
And even then, Ada exists, so Rust has no place
Mission Critical software you chose C++ not Rust, because more people know C++, it has more mature good libraries and it's been an industry standard for Decades and is used in the Aerospace industry.
I really don’t like the mental overhead in a programming language. I want my mental energy focused on the problem not on the tool. This is why I am not sure I will go on with Rust. I don’t need it for work and I just need a low level language in my personal toolbox as an engineer to mess around with lower level stuff. I am very tempted to switch back to C or jump on Zig (or Mojo or OCaml?).
Java is Euro Truck Simulator 2 for C++ devs
I have no idea about coding but this comment just feels correct
its a mystery to me how so many people absolutely love the shit out of that game...
Somebody explain for a normie
Yes, please explain.
@@GanjaDubstephow did you get here?
(Java^22 + Lombok + Manifold) x Kotlin = Exactly what I enjoy dealing with. JetBrains forcing Oracle to be better.
If the 10+ Big Java projects ever get finished, Any Native + Java + Kotlin will be super nice.
Where te obsession of Lombok comes from?
Record are more than enough or it is a mantra of java 8 dinosaurs?
@@OleKap
Lombok provides more than just setters and getters, and you can't use records for everything.
@midoevil7 you are welcome to prove your point by providing some real-world examples where lombok is not replaceable by records
@OleKap records are great when you can use them. On bigger classes, unless you delegate a lot of the code to a helper/handler, lombok can remove a lot of boilerplate, not have to sift through. I'd delombok eventually, but it speeds up the dev process quite a bit.
@@OleKap
Any class where java setters are required:
JPA entities, spring beans , DTO classes with older versions of Jackson, because they don't support records, in cases you need to add annotations on fields.
Let alone when requiring features that records doesn't support, builders, fields exclusion from toString(), and hashCode().
Java syntax is million times more human friendly. Rust guys should fix their syntax and then I can think about using it.
Java's latest additions include gems like:
if(pet instanceof Cat c) {
c.meow();
} else {
//c not in scope here
}
//c not in scope here either
Kotlin was able to do smart casting years ago running on JDK6
when pet {
is Cat -> pet.meow()
else -> { /* meow() not callable */ }
}
It's funny to me how the same argument applies differently to rust and go. Prime says doing ? everywhere in rust is bad so on. But in Go he says he has to think a lot about the problem, and handles it, as if you couldn't do if err nil { return err }.
it is just harder to do. Typing ? is dead simple.
But if you write if err != nil your brain out of habit automatically makes you add some context to that error by wrapping it before returning
@@bionic_batman sounds like skill issue :)
What i feel you are forgetting about Rust is that it's type abstractions are normally 0 cost, and only when the `dyn` keyword and a `struct` which allocates really slows the application down in any meaningful way. Also (as much as it can) the compiler optimizes the Rust code and sometimes the resulting binary has allocations and dynamic dispatch optimized away. Yes it is a black box, but the compiler can often make better optimizations than a human can hand code something. I will say it's perfectly valid to prefer something like Zig over Rust but arguing about which is better is often futile and in some area's Zig will beat Rust, but also the visa versa is true, for instance working with a large code base hands down Rust annihilates Zig, Zig also requires just as much allocation as Rust, for instance returning an error with context dynamic at runtime still requires a heap allocation as the size cannot be known at runtime and the error requires persistence beyond the stack frame it is called in. That being said, you can do errors statically in Rust, you can also do them dynamically but you can also have a hybrid approach very easily where you use an Optional to be `None` for static handling and either use a `Box
yeah, if you have 50k lines + nobody cares about "zero cost abstractions" when debugger doesn't work :) or the debug build is so slow, that it's actually better to do it the JS way - just write to console.
"working with a large code base hands down Rust annihilates Zig"
I feel like it's too early to say this. I don't think large codebases in Zig have really been tried yet, except for Bun. I am very curious how Zig will compare to Rust once it's stable.
@@Qrzychu92 currently i'm writing some code which in involves a complex set of steps to scrape, download, verify, and upload to a database. I'm using lifetimes and mutable references, to most this area of Rust appears complex because you have to think about lifetimes in an abstract way as opposed to i declared it here and i must at some point free it, or its on the stack and taken care automatically. I prefer it over Zig and normal references found in Zig, C++ and Go. Because if i was to introduce a bug which makes the reference invalid Rust will catch it. That's my perspective and i like it, I'm not saying everyone has to agree with that, I'm not saying my opinion is the correct one and I'm not saying it's the best, i'm, saying i prefer it. Someone else may prefer Zig and that's fine, it's syntax and philosophy may appeal to them, but whichever you like doesn't invalidate the other is what i'm pointing out. Since i've had to explain this twice now i'm going to see this as resolved
@@ahdog8 tigerbeetle and bun are large code bases
Started with PHP projects. Then Java for a couple years. Now Scala, Kotlin, JavaScript/Typescript, Python, Go and so on. I saw all the pitfalls. I love Scala and Kotlin. But for my own business I would always choose plain Java with a enterprise supported Framework like Quarkus or Spring. Or maybe Scala with Akka for some specific use case.
Kotlin all the way, it is 100% compatible with all Java libraries and frameworks unlike Scala. The language is just so much nicer than Java
@@balint133 Sure it is. But think about hiring, supporting agencies, knowledge transfer and so on. Let us say your are the founder, it is your own money and your choice. What would you do? I would go for the most boring, established, enterprise ready language and toolset. I am in a Scala project for around 8 years and we are working on some Kotlin services too. It is fun, but I am convinced that this was not the best business decision.
The two serve completely different purposes. Want to get stuff done easier and faster at the expense of having to carry around a runtime? Use Java. Otherwise, use Rust. The two aren't really competing.
I know C#. I made three small apps for my own use in Rust. Anything non system level or "C#" level was as productive as C#. And that feeling I got while still learning Rust...
@@techpriest4787 I've written web servers in all three, and mobile and desktop apps on C# and Java. I don't feel that Rust slows me down much either after you know it well, but I also understand those who do feel slowed down. You have to keep more things in your head while developing Rust than Java or C#: who should own this? should this function borrow that? Should this variable be consumed here? Should a reference be returned there? Stuff that you simply don't have to think about in Java or C#.
Hi Primeagen, I love your content! However, I think your criticism of Java might be based on older versions and outdated knowledge. If you explore modern Java, perhaps with a framework like Quarkus, you might find its tooling and features more impressive. Just as you took the time to learn Zig, giving modern Java a fresh look could be enlightening. Looking forward to your thoughts!
I much prefer Kotlin over Java - less boilerplate and a more modern language, null safety, better syntax etc.
Coding in Java for the JVM does not make sense to me because Kotlin is fully interoperable with Java
I would love to use kotlin, but you are practically required to use intellij. There are no good tools/lsp outside. And IntelliJ is great, but it's really heavy (and afaik you can only use community edition for non commercial uses?)
@@araozuthe non commercial part isn't true (ce is licensed under apache 2.0), but the lock-in into intellij is real
@@araozu just buy a private license. It is like 100 bucks.
Scala is the answer
@@gabrielpreciado5699 Scala is a great language but it has downsides
It is a more difficult for your average programmer, slower compilation and less compatible with Java libraries.
Jetbrains created Kotlin because of some of the downsides of Scala
You could argue that Kotlin is a baby Scala
10:30 Having implemented my own framework that makes use of functions with varying parameters and return values... yeah, things get kinda tricky. Probably the hardest thing I've implemented in Rust.
Was kinda fun, though and I learnt a lot.
And because I'm not sure I properly described what I mean: I have a route() method that takes in a callback function. This callback function can have many different parameters and the return value is also somewhat flexible. It adjusts its behaviour based on what exact function you give it.
i love writing java but the package manager and folder structure is so damn verbose. I dont even want to think about that.
com.mycorporatebusiness.mydepartment.packagename.subpackagename
..... WHY ARE YOU GUYS STILL WRITING THIS TRASH?! Just use a simple one-word package name!
I don't know if this was mentioned, maybe I missed it, but any language where objects/structs can always be null is just an instant "pass" for me.
The other questions don't even have to be raised.
This is one of the real problems that nobody seems to care about. All these languages bring a lot of software engineering byproducts that have nothing to do with computer science. Reference types? Objects and classes? Iterators? StringBuilder FileStreams? Nothing but BS. We have real programming languages like ML and Mathematica for solving real problems.
I thought I hated working with Java, but then I worked on a big rust codebase, and I feel like I prefer java's amazing debugging and tooling over rust's, despite how awesome cargo is. Aslo, I may not like Java, but I love kotlin (despite some hangups surrounding certain defaults, and nested destructuring).
You downloaded the wrong Rust. It requires only a minimum of debugging tools. You may be out of habit using it more than you actually need. Old habits die hard.
@@techpriest4787 spoken like a true member of the community. Try saying that after you have to diagnose a subtle logic error, and most of the types you're working with dont even implement debug. Oh, and there's liberal use of super confusing numeric IDs that abstract away anything even slightly reminiscent of a string. Also, every other function you try to step into is proc macro generated.
I'm working on a 5 year old codebase. The guy who made some of this stuff isn't in the org any more. And there's no documentation worth looking at.
Despite all that, I did eventually fix the bug I've been ranting about. It was, thankfully, a 1 line fix. But I couldn't have done it without a debugger. And it would've been nice if the debugger just let me execute arbitrary rust as an expression, it would've saved me a lot of time figuring out what the heck that boxed double indirected enum inside an rc refcell had inside. Yeah. Don't say I was using it wrong.
@@techpriest4787 no u
@@techpriest4787
@@techpriest4787 you are a great person who has correct thoughts and nothing is wrong about what you have said. Also lived experience is worth a lot more than a bunch of words strung together on a screen.
explaining the code sample in java, starting from main:
we create an integer range as an array to pass using the java 8 IntStream.
We create a map of conditions, relating predicates of ints, to strings. A predicate is a true-false statement. In this case they're implemented with a Java 7 Lambda
then we print the output of fizzBuzz for the range and rules of the game.
Stepping into the algorithm, we stream the array of ints.
For each int in order, we stream the conditions.
If any condition matches, we map to its matching string.
We connect the strings together.
if there is no result yet, we return the number instead.
Then we connect the results for each number with spaces between, and return.
This structure is written so that the number game could be done with any arbitrary substitution if the number matches a given condition, and that condition can be anything as long as it is a condition on a number. It can also take any arbitrary number sequence.
I love Prime. He has said this stuff for years "if you CAN use it wrong, it muse be bad!"
That metric would put all programming languages to the bad pile.
@@TranscenGopher except that Prime is a bit of a walking double standard.If he knows how to you use and why, it is good.
@@AndrewErwin73 well, exactly. Everything would be good if you know how and why you use it properly.
And if you don't, then everything can be bad.
That's such a non-heuristic it isn't even worth pointing out in general.
as a language - meh, but java's 21 virtualthreads are awesome! using them from scala rn and it's a dream.
The fact that we're comparing the complexity of Java, which is a garbage-collected language, with Rust, says a lot about how unnecessarily complex Java is
Funny
I'm all for writing "simple code" because I would take simple code any day over difficult and "make me feel smart code" just because I know for a fact that you'll burn out so much quicker if all you did was difficult code day in and day out
Imperative java > rust > procedural java
Huh? Procedural is a subset of imperative
@@rusi6219this is the modern programmer's level of computer science education
@@youtubeenjoyer1743 :)
imo, when you read code writen in java in an imperative way, it is far easier than rust or procedural java,
also, subset doesn’t mean the same
I don't understand how you can think that there is more mental overhead in using filler, map and reduce than in using a bunch of loops, like at 32:00 . Sounds like some Golang copeism to me.
It is all garbage for the fact that people just don't know how to use Rust, you do not create OOP garbage and claim rust is hard, you don't create a mess with C styled procedural hack and whine about life time and asyncs destroying you, no no no. Only correct way of working with async rust is ECS (Entity, Component, System). It works really great for UI, perfect for games, and certainly good enough for servers. It eliminates the life time coloring entirely. Even if you use lifetimes, AT WORST you'd do something stupid like having them on a component, then it will pollute only the systems which use them, and the system manager. But it can easily be eliminated. It eliminates most clones as you wouldn't be fighting the borrow checker, and the mutable shared state exists in a single thread. It baffles me why people are not using ECS more in rust. Some good implementations exist, like bevy for games, and I have heard people behind Warp use it extensively, but nearly not enough. Most rust servers to this day are massive shared states with very many Arc mutexes, then lifetimes and everything adding to the complexity!
You can't use a language wrong and then complain that it is hard. It is hard like you use it, because Rust's compiler specifically want you to avoid doing what you are doing. You are fighting the language with 'hacks', of course it will be pathetically difficult! The goal of rust is no to accept all 'safe' code, but a subset of safe code. You have to just understand what that subset is, and you will never feel pain of using Rust.
Background: My first programming language was really GW-BASIC (if you don't count LOGO), then I taught myself FreeBASIC and C. During the HTML5 gaming boon in early 2010s I learned Javascript and Typescript and started making games and a few game engines, which lead me to making servers for them, and learn Rust. I have done fair bit of C++, Java, D, x86 assembly on Linux, and sadly, even some ruby. I have also implemented a lot of toy BASIC-like languages with backends in C, C++, and assembly, and even toy interpreters during early teenage years. My first reaction towards how pathetic javascript was, was to create a BASIC-like language transpiling to JS in C.
There is nothing like Rust for sure. The confusion around which architecture to use with Rust is causing all the problem. And because of that, most rust code i see looks nothing more than 'hack' around the rules of the language.
Here is the thing! We technical guys care about speed and developer joy and pain. Companies don't. Literally no ones who has the money to found your dreams cares. I have got so much in trouble reporting things that don't work, security shit, performances issues that I just gave up on trying to improve anything at any company.
What's the deal with Primagen telling the audience they don't do "hard stuff" all the time?
"netflix btw"
As a long-time viewer/subscriber this pushed me to stop following him on Twitch. I've heard him talk down so much on his viewers (among other things) that it's really rubbed me the wrong way.
Listen, I don't follow his streams, I mainly watch the youtube stuff. I don't hear all his statements. But... regarding people not doing "hard stuff" all the time: that is just objectively true. If you've been in the industry for long enough, and seen what happens in most companies, this is just an accurate take.
@@peculiar-coding-endeavours I'm not arguing the truth of the statement - in fact, I agree. What I'm saying is that he comes off as condescending and belittling.
@@okseaj That's fair. I'm not sure if he means it that way, I doubt he does, but I can't be sure.
Rust has a lot of tools like write on clone, Rc, etc, that you can use to simplify things in return for slightly less good performance. The problem is that people worry about doing things the "right" way with lifetimes when it doesn't matter for performance and makes the code worse to write. (If you aren't measuring or know for certain from experience that it matters a lot, performance doesn't exist.)
So easy people make it hard actually applies to a lot of haskell code. People end up reaching for cool monad transformer stacks or effect types when what you need for a brain dead API backend is just a reader io monad and STM. Maybe the capabilities library to have a nicer RIO experience.
It's a wellknown fact that real men code in C++
Does it even make sense to compare an interpreted, garbage collected language to a compiled language with explicit memory management? like, imagine writing some software that must operate under real time constraints, would you use Java and its garbage collector which starts and stops unpredictably, or Rust?
One time I tried out Java to make a Minecraft mod, and I swear it took me like maybe two or three hours to get Graddle to work, and when it finally did, after a few more hours it just stopped working and I could never figure out why.
use maven
Graddle lol McDonald's ass dependency manager
I'm a C# dev and I wanted to play with Kotlin. Graddle and Maven were such brick walls for me. Like 30 different tasks are there when you create a new project. I just want to run it. In C# you just hit F5 or "dotnet run" in terminal, and that's it. "dotnet publish" for release build. That's it.
Nuget dependencies can be a nightmare in c# in java you have a little more control im sure with nuget you do also but its easier in java @Qrzychu92
I suppose you just were not chosen by Java
Do people still use Maven/Gradle for Java? I just remember being miserable using them (especially maven) when I used to work on Java.
Cargo so far has been seamless, I like NPM too but I'm not sure if it's stockholm syndrome.
With rust you can't bang on the keyboard like a monkey. You have to solve the puzzle - that's one of the things that makes it great. Once the puzzle is solved and the code is written, it is extremely easy to read what is happening.
I don't speak or understand English very well, so I have to put your videos at 0.5x and repeat parts of the video over and over again to understand better, the subtitles don't give a good translation and although sometimes it takes me more than 1 hour to finish a video and I try to watch it in full.
Simply because you have good content and interesting opinions, it distracts me sometimes when I'm coding, thanks.
"PS/ I used gogole translate I don't know if I said some weird shit lol"
I realized that the more I understand Rust's macros, the more unreadable my code becomes. I am currently working on a small math library and I got to the point where almost the entire code base is macro calls, procedural, declarative, derives, the entire lot. So yeah, there is almost no repeating code, but debugging is a nightmare and making any changes is almost impossible. And it's not just me, if you look at a lot of libraries, they are full of macros everywhere. It's almost as if Rust encourages every project to have it's own DSL which makes it so hard to maintain.
Huh, I don't know if I agree that "a lot" of crates are "full of" macros, but that's pretty subjective and depends on what you've looked at.
Generally I see macros used for what it's good for: really repetitive code, saving more than 100 lines.
What confuses me in libraries tends to be the trait bounds gymnastics where whether you can call a function end up depending on 40 different traits.
@@SimonBuchanNz I've been using rust mostly for writing math libs, and because you need to declare things for every single num type, all the math crates uses macros heavily.
You should try kotlin. It's fixed Java that's fully interoperable so you don't even have to throw any code out.
31:14 That fizzbuzz is just mental masturbation, if a junior made a pr like that, I'd tell him to rewrite it.
that's a SOLID solution bro
What I don't understand is that I'm pretty sure Rust can do the same shit kind of the same way but less verbosely.
What if the hashmap in the java example changes the order of the predicates due to hashing? Wouldn't you get BuzzFizz then instead of FizzBuzz?
@@in2vd LinkedHashMap keeps the insertion order when iterating
Some suggestion for improvement:
- don't use an array, but the IntStream
- use IntPredicate, so there is no autoconversion to Integer object
- put that inner function into it's own method
all i could think at 14:00 is "What are you doing over there, step-function?"
Doesn't matter which language... the question should always be how good quality is your application. If you obsess too much on choosing the best language, but write terrible code/logic, Java or whatnot isn't gonna make you a better programmer.
Started with Java 1.7, but used php on server side 😅.
of all the things to disagree with ure gonna pick the java ecosystem is rich one. Crazy
One king to rule them all: JAVA
C# ;)
If you think functional programming will really not take off, maybe looking at ROC will change your mind.
It looks like Rust tries to be C++ but without going the way C++ went last 20 years. Well after 20 years it would be universal language if it survives.
There’s a dialect of C++ that adds the Rust style borrow-checker. It’s definitely stirring the pot and being looked at. In ten years C++ will probably have borrowed checker and pattern matching. C++ templates are way better than the combo of Rust generics and hygienic macros. No limit to what can be devised with templates - such as containers. Compiler is able to do better optimization with templates as it sees everything. And C++ is way ahead (except relative to Zig) on constexpr kind of compile time evaluated code. More and more of std library will keep getting reworked to better use constexpr where ever possible and concepts.
@@TheSulross agree
@@TheSulross "C++ templates are way better than the combo of Rust generics and hygienic macros"
Elaborate. Because I have experienced template hell and would like to not experience it again.
@@khai96x hee, hee - they’re [C++ templates] not simpler to use (from user perspective) but they allow for better compiler visibility into the nature of the code and hence facilitate better code optimization, and hence performance. Now with C++20 and some other recent new template related enhancements, they are getting better in terms of writing templates (vs just consuming templates via, say, the std lib stuff)
That’s the big contrast to, say, type-erased generics that are in languages such as Java or more recently, Golang.
The Rust hygienic macro feature, though improved over C macro pre-processor in some respects, is still not as sophisticated as C++ templates.
C++ templates get criticized for being a language within a language, so to speak, but Rust macro feature is also alien to its host language. (The new C++ reflection feature coming in C++26 will augment nicely with templates - probably will be more impactful than Concepts.)
But meta-programming in context of any language means stepping off into needing certain things that the language proper doesn’t address. Zig is one case, though, where one just uses Zig language for meta-programming too. I think it already has some things that are only relevant in meta-programming context, though - so will be interesting to see if there is pressure to better accommodate meta-programming in Zig with things that are only available in that context. (Zig build files also written in Zig and comptime stuff same sort of simplicity. Definitely interesting to watch how this Zig simplifying philosophy goes.)
@@khai96x He's just wrong. C++ templates are hell. I used to love C++ but the language is too large and complicated now to be saved. Adding more stuff to it just makes it worse. It's not like you can forget about the old stuff, you still have to know that and the new stuff too. If you're starting a new project, you might as well start from the clean slate that is Rust.
The concurrent hashmap is really good, I can agree, when I was building my key-value store, at first I didn't know about it and when I found out about it...
I work writing banking enterprise software. The app is about 8M LoC java with a decent amount of legacy (20 yo system). Even though many efforts have been made to keeping mental overhead low it is by no means trivial, and this is a problem that is almost impossible to overcome with idiomatic java.
For a system of this size I would much rather have rust and learn the language features than the mostly required incidental complexity. Ive written rust professionally for about 6 years and would def not agree that java scales better at this size. I would say java does win scalability until the system becames exceedingly complex. But a fund trade system where things casually have 7+ layers of inheritance is hairy at best, and error prone.
The flip side is its much easier finding good java developers than expert rust programmers. So from a business standpoint java probably still wins.
>idiomatic java
maybe that's the issue: don't worry about being idiomatic