I really wanna know where you get your language info and examples from because nearly every single one you wrote in your comments is just wrong.
Program state in Rust isn’t immutable. datastruct.nextState() is not only possible, but perfectly reasonable, it’s exactly how iterators are implemented.
The fact that it can be used as a scripting language doesn’t mean it’s a scripting language. You could use C++ as a scripting language as well, but it would suck.
C# even supports native compilation nowadays, not just JIT, so it’s definitely not a lowly scripting language.
Anyways you’ve got options. Go may also be one of them if you want GC, I forgot to mention it.
I’ve found working with Rust and Bevy to be quite pleasant. If you’re used to working with ECS, I suggest you at least give it a go.
Rust is as functional as C++ 20 with ranges and views is, which is to say it isn’t. Not sure where you got that impression from, but while it does borrow some ideas from functional languages, it’s still very much a procedural one.
Zig doesn’t have headers, nor inheritance. Again, not sure where you got that from, but Zig is basically a modern C, so there’s no OOP anywhere, let alone multiple inheritance.
As for what to use, I think they’re both viable alternatives. I lean more towards Rust, but that’s just due to familiarity. Odin also looks like a viable option, if you don’t mind a smaller ecosystem.
If you want a garbage collected language, then I’d go for C#. Despite its historic reputation as a Windows only language, it’s been cross platform and open source for roughly a decade at this point. I find it great to work with.
It wasn’t just to accomodate trans people but just… anyone who isn’t male? Apparently women being software developers is a controversial concept for Andreas.
I find this to be true for every new language I try out. Since every language has a different way of doing things and gives me a new perspective, in the long run they all end up improving my programming style as a whole. I always end up integrating the best parts of each into my next project when possible.
Experience will always be more valuable than any set of rules these kind of books tout as “the way things are meant to be done”.
Oh for sure. I have nothing against getters and setters when they’re justified, but in the case of bare fields with no validation like that example it’s just annoying.
Also stuff like this just grinds my gears (oversimplified example again):
class IntegerAdder {
private int a, b;
public IntegerAdder(int a, int b) {
this.a = a;
this.b = b;
}
public int get_sum() {
return a + b;
}
}
Just make it a bloody function.
You may say it’s silly, but I’ve genuinely found code like this in the wild. Not that exact code snippet of course but that was the spirit.
It really depends on the context frankly. I did say it was a crappy example ;)
Try to read this snippet I stole from Clean Code and tell me if it’s readable without having to uselessly jump everywhere to understand what’s going on:
public class SetupTeardownIncluder {
private PageData pageData;
private boolean isSuite;
private WikiPage testPage;
private StringBuffer newPageContent;
private PageCrawler pageCrawler;
public static String render(PageData pageData) throws Exception {
return render(pageData, false);
}
public static String render(PageData pageData, boolean isSuite) throws Exception {
return new SetupTeardownIncluder(pageData).render(isSuite);
}
private SetupTeardownIncluder(PageData pageData) {
this.pageData = pageData;
testPage = pageData.getWikiPage();
pageCrawler = testPage.getPageCrawler();
newPageContent = new StringBuffer();
}
private String render(boolean isSuite) throws Exception {
this.isSuite = isSuite;
if (isTestPage())
includeSetupAndTeardownPages();
return pageData.getHtml();
}
private boolean isTestPage() throws Exception {
return pageData.hasAttribute("Test");
}
private void includeSetupAndTeardownPages() throws Exception {
includeSetupPages();
includePageContent();
includeTeardownPages();
updatePageContent();
}
private void includeSetupPages() throws Exception {
if (isSuite)
includeSuiteSetupPage();
includeSetupPage();
}
private void includeSuiteSetupPage() throws Exception {
include(SuiteResponder.SUITE_SETUP_NAME, "-setup");
}
private void includeSetupPage() throws Exception {
include("SetUp", "-setup");
}
private void includePageContent() throws Exception {
newPageContent.append(pageData.getContent());
}
private void includeTeardownPages() throws Exception {
includeTeardownPage();
if (isSuite)
includeSuiteTeardownPage();
}
private void includeTeardownPage() throws Exception {
include("TearDown", "-teardown");
}
private void includeSuiteTeardownPage() throws Exception {
include(SuiteResponder.SUITE_TEARDOWN_NAME, "-teardown");
}
private void updatePageContent() throws Exception {
pageData.setContent(newPageContent.toString());
}
private void include(String pageName, String arg) throws Exception {
WikiPage inheritedPage = findInheritedPage(pageName);
if (inheritedPage != null) {
String pagePathName = getPathNameForPage(inheritedPage);
buildIncludeDirective(pagePathName, arg);
}
}
private WikiPage findInheritedPage(String pageName) throws Exception {
return PageCrawlerImpl.getInheritedPage(pageName, testPage);
}
private String getPathNameForPage(WikiPage page) throws Exception {
WikiPagePath pagePath = pageCrawler.getFullPath(page);
return PathParser.render(pagePath);
}
private void buildIncludeDirective(String pagePathName, String arg) {
newPageContent
.append("\n!include ")
.append(arg)
.append(" .")
.append(pagePathName)
.append("\n");
}
}
That’s what I was talking about.
Yeah that was essentially what I was referring to (referring to your edit).
I generally dislike stuff like (crappy example incoming):
void do_stuff(int count, bool cond) {
function1(count);
function2(b);
function3();
}
void function1(int count) {
for (var i = 0; i < count; i++) {
...
}
}
void function2(bool cond) {
if (cond) { ... }
else { ... }
}
void function3() {
...
}
I’m not a fan of this kind of code fragmentation.
If all those actions were related and it could have been just one thing, retaining a lot more context, then it should be one function imo.
If by not splitting it it became massive with various disconnected code blocks, sure, but otherwise I’d much prefer being able to read everything together.
If splitting the functions required producing side effects to maintain the same functionality, then that’s even worse.
Also (taking go as an inspiration), I (personally) find this very hard to read
Agreed. Go’s implementation of errors as values is extremely noisy and error prone. I’m not a fan of it either.
You can always ignore an error return value and pretend that the “actual” value you got is correct.
Then that’s a language design / api design issue. You should make it so you cannot get the value unless you handle the error.
I’m of the opinion that errors should be handled “as soon as possible”. That doesn’t necessarily mean immediately below the function call the error originates from, it may very well be further up the call chain. The issue with exceptions is that they make it difficult to know whether or not a function can fail without knowing its implementation, and encourage writing code that spontaneously fails because someone somewhere forgot that something should be handled.
The best implementation of errors as values I’ve seen is Rust’s Result type, which paired with the ? operator can achieve a similar flow to exceptions (when you don’t particularly care where exactly an error as occurred and just want to model the happy path) while clearly signposting all fallible function calls.
So taking your example:
try {
res = try_something()
res2 = try_something_else(res)
res3 = try_yet_something_else(res2)
return res3
} catch (e) {
// check which error it is and handle it appropriately
throw_own_exception()
}
It would become:
fn do_the_thing() -> Result<TheValue, TheError> {
res = try_something()?;
res2 = try_something_else(res);
res3 = try_yet_something_else(res2)?;
}
match do_the_thing() {
Ok(value) => { /*Do whatever*/ }
Err(error) => { /*handle the error*/ }
}
The difference is that you know that try_something and try_yet_something_else may fail, while try_something_else cannot, and you’re able to handle those errors further up if you wish.
You could do so with exceptions as well, but it wasn’t clear.
The same clarity argument can be made for null as well. An Option type is much more preferable because it forces you to handle the case in which you are handed nothing. If a function can operate with nothing, then you can clearly signpost it with an Option<T>, as opposed to just T if a value is mandatory.
Exceptions are also a lot more computationally expensive. The compiler needs to generate landing pads and a bunch of other stuff, which not only bloat your binaries but also prevent several optimizations. C# notoriously cannot inline functions containing throws for example, and utility methods must be created to mitigate the performance impact.
I’ve found it’s mostly two things: readability (ironically) and performance. I’ll describe a few crude examples, but I won’t get too much into specifics, otherwise I might as well write another book myself.
The performance part is simple: its excessive reliance on polymorphism and the presence of several levels of abstraction just doesn’t allow for good code generation. I’ve seen 10x+ performance improvements by dropping all of the above, with often minimal loss in readability; on the contrary, oftentimes the code became more readable as well.
The readability part is harder to explain; not only because it depends on the codebase and the problem at hand, but also on the coding style each programmer has (though in my opinion, in that particular case it’s the programmer’s problem, not the codebase’s).
I like to think of codebases as puzzles. To understand a codebase, you need to piece together said puzzle. What I’ve found with Clean Code codebases is that each piece of the puzzle is itself a smaller puzzle to piece together, which isn’t ideal.
I generally disagree, not because those ideas are wrong, but because they’re often too limiting.
What often happens by following those principles is you end up with a slew of tiny functions scattered around your codebase (or a single file), and you are forced to piece together the behaviour they exhibit when called together. Your code loses locality and, much like with CPU cache locality, your brain has to do extra work to retrieve the information it needs every time it needs to jump somewhere else.
It may work for describing what the code does at a high level, but understanding how it works to make meaningful changes will require a lot more work as a result.
Once again, it makes sense in principle, but in practice it often creates more problems. I agree that having massive chunks of repeated code is bad, no questions about it, but for smaller chunks it may actually be desirable in some circumstances.
By never repeating code, you end up with functions that are over-parameterized to account for all possible uses and combinations that particular code snippet needs to work with. As a result, that code becomes more complex, and the code that calls it does too, because it requires you to know all the right parameters to pass for it to do the right thing.
Exceptions are just bad. They are a separate, hidden control flow that you constantly need to be wary of.
The name itself is a misnomer in my opinion, because they’re rarely exceptional: errors are not just common, but an integral part of software development, and they should be treated as such.
Errors as values are much clearer, because they explicitly show that a function may return an error and that it should be handled.
I have lots of gripes with object orientation. Not everything needs to be an object, not everything needs to be polymorphic.
There’s no need to have a Base64Decoder, much less an IBase64Decoder or an AbstractBase64Decoder. Base64 only works one way, there are no alternative implementations, a function is enough.
I’m a lot more on the data oriented side of the isle than the OO one, but I digress.
Object orientation can be good in certain contexts, but it’s not a silver bullet.
Let’s say you have something like this:
class Point {
public float X, Y;
}
With the Clean Code approach, it magically becomes:
class Point {
private float x, y;
public float get_x() {
return this.x;
}
public float get_y() {
return this.y;
}
public void set_x(float x) {
this.x = x;
}
public void set_y(float y) {
this.y = y;
}
}
Why? Who the hell knows. It makes absolutely no tangible difference, it only makes your code longer and more verbose. Now, if a value needs validation, sure, but oftentimes this is just done regardless and it drives me insane.
The problem with wanting to create the most generalized code in advance is that you end up stuck in abstraction hell.
You may as well not need the ability to have arbitrary implementations, but now you need to plan for that.
Not only that, but it also makes reasoning about your code harder: how many times have you had to step through your code just to figure out what was being executed | just to figure out what particular concrete class was hiding behind an abstract class reference?
I myself, way too many, and there was often no reason for that.
Also, the idea that you shouldn’t know about the implementation is crazy to me. Completely encapsulating data and behaviour not only makes you miss out on important optimizations, but often leads to code bloat.
Take a look at these if you want more info or someone else’s view on the matter, I wholeheartedly recommend both:
I’m of the opinion that Uncle Bob did some massive damage to software development as a whole with that book.
With that said, this is genuinely funny.
Oh my god look at how big this Java project is before I compile it, what a nightmare!!1!1!1!
When shipping to customers, all code is your responsibility, dependency or otherwise. A bug or a security vulnerability, which aren’t rare in the JS ecosystem, is your responsibility whether you wrote the code or not. Customers don’t care if someone else wrote it, it’s your product, you are to blame. Thus, the less code, the better. Less moving parts also means more stability in general.
the most popular language and the most successful cross platform development platform in the entire history of programming
But no, I’m sure it’s the millions of successful developers and users who are wrong.
People can be successful with things that aren’t perfect. It’s often a matter of being the first, not being the best. Something can be popular and still not be good, momentum is hard to stop. If JS’s own creator saying so in the last few years can’t convince you of that, I don’t know what will. Flash at one point was the most popular. It was still flawed, and a liability, but I bet that doesn’t hurt you as much to hear.
Everything is shit but you amirite?
Quite the contrary. I have flaws like everybody else, but at least I don’t deflect every single criticism of stuff I like because in can’t fathom it not being perfect. It’s fine, use it. Maybe one day you’ll find a platform that’ll make you realize there’s better stuff out there.
But I’m done arguing with you. I should have known by the tone of your first reply that this wasn’t going to be a real discussion, just you being butthurt because someone said something negative about your favourite language. Go get butthurt somewhere else.
There’s a distinct lack of FactoryFactoryFactoryBuilders in this code snippet.
Clearly you have yet to reach true abstraction nirvana.
Is there something I’m missing here? Why would you expect to be able to do bitwise operations on floats and get a sensible value? And if you want to do integer bitwise operations… you still can? Just use integer values and the bitwise operators?
No that’s my point. You can’t, because there’s no such thing as an integer value. It’s all floats, always. They get casted to integers, the binary operation is done, then they get converted back to floats. That’s a lossy process, so some binary operations with certain values are simply not possible and you get weird results. The max width of an integer you can store is 53 bits, the maximum addressable width is 32 bits for binary operations. That’s wonky.
This is patently false. JS has sets, maps, etc…
Ah yes I forgot sets. But I don’t think there’s anything else? Last time I checked there were no binary trees, no proper (ring buffer) queues, no ordered sets, but I may be wrong on that. It’s not enough imo for a proper standard library.
For everything else:
My point is that JS is an okay scripting language for the web. As I said, for that it’s perfectly fine, though the frameworks are often lacking imo. But there is this tendency to use it to create backends, desktop applications and tooling. That’s where the language falls apart, because it’s not made for that. It needs to be more robust, well defined and fully featured to be used in those contexts, both in terms of JS itself, and its standard library. Same with TS.
You seem to be confused about what JS is. It’s a high-level interpreted language. It’s not C.
I know and that’s the point. It’s underspecified for things outside the web, so it’s terrible for those use-cases. You can make it work for Node, but not for Bun or any other runtime. And even then, the experience is acceptable at best.
I personally would never use it for such use-cases, but people keep touting it and TS as these amazing general purpose languages you can do anything in. You can, but you really shouldn’t.
That’s what people with skill issues tend to say.
Not that’s what people who can recognize genuine architectural defects and aren’t blind fanboys say.
You apparently still bitch and whine like a rookie.
Only to your eyes since apparently pointing out genuine problems is whining. It’s okay for people not to like the stuff you like. And no, using a few swear words for emphasis doesn’t make someone immature, nor does listing what one has worked with for context.
You learned how to write == in every other language, but you can’t figure out === in typescript?
…you still haven’t realised that === is not what I have a problem with have you? It’s literally a non issue. In fact, equality in general is a non issue. It’s the wonky standard library, lack of proper support for binary operations, serialization and almost everything being an afterthought that I have a problem with. Does it prevent me from using the language and write proper, stable software? No. But it’s not good.
you install a whole web browser alongside operating system shims into your project
Except that amounts to a mere ~180_000 lines of the 3 million. Did a plain create-react-app without Electron, still over 3 million.
Now, since it’s impossible to have a genuine conversation if the other party’s response is “haha you suck” to any genuine, documented criticism, are you gonna grow up or are you gonna keep acting like an offended 13 year old who can’t find a better retort?
Ah that’s fine. There’s nothing wrong with abstraction, until it becomes too much.
Anything that isn’t plain web browser stuff.
You can’t write files without Node specific APIs.
You can’t even do proper bitwise operations because everything’s a float.
Binary serialization is a pain and proper deserialization in general is not enforced, even in TypeScript, because types are an illusion.
Up until recently there were no synchronization primitives, though now the idea of having them in JS seems terrifying.
There are no other data structures than arrays and maps, which are often not enough.
It’s just not a language I’d use for anything more than… well… Scripting. But even though other, better solutions exist for cross platform development, people insist on using JS, so here we are.
I can understand accounting for different environments. That’s unfortunately unavoidable. But I found web framework developers in particular have a weird tendency of piling up ungodly amounts of abstractions just for the sake of it.
It’s kind of a cultural problem in modern software development in general imo. It’s not limited to web dev by any means, but it’s particularly bad there because JS lends itself to it quite well.
Yeah but if the class changes you need to update everything, you got all that boilerplate taking up space for no real reason, etc…
The Rust way’s just a lot cleaner imo.