131–140 of 146 posts
Earlier quoted context omitted.
Here they are: https://github.com/beyond-all-reason/Beyond-All-Reason https://github.com/ZeroK-RTS/Zero-K
I can't recommend Zero-K enough. It plays like a dream. Super fun at all levels. Great 8v8 clashes of robots. Unbeatable price ($0). Great dev blogs. https://store.steampowered.com/app/334920/ZeroK/
Earlier quoted context omitted.
Agreed. I had to work in a larger Python codebase after spending a few years with Go and Rust and the drop in logical confidence around the language was remarkable. I have, roughly, sworn off dynamic languages at this point. Although I have dreams of implementing a firm typed system over Common Lisp.
I’m assuming that Python code base didn’t have thorough type hints. What if it had? Would Go still feel safer? I know these aren’t checked in runtime, but Python type system seems more thorough than Go’s, so shouldn’t a Python code base fully typed be even safer than Go? If so, why not? (I know Python type checks aren’t mandatory, but for this question assume that the type checker is running in CI)
Even then, you're reliant on the correctness of a 3rd party tool vs a 1st party compiler. It's never going to be as good of an experience.
Earlier quoted context omitted.
You mean compiler vs client reporting issues? Never safer.
Yes, but in practice, is the difference significant enough to matter? I’m genuinely looking to see if I’m missing anything when favoring Python type system over Go’s.
Earlier quoted context omitted.
I saw someone describe python as “stressful” for this reason and I couldn’t agree more. It’s difficult to have confidence in any change I make or review. I need to sit down and manually exercise codepaths because I don’t get the guarantees I crave from the language or tooling. While with the small amount of Rust code I’ve written lately I could yolo changes into production with no stress.
Do you believe that Rust's type system is as flexible, powerful, and easy to maintain as unit tests in Python?
1. Of course a type system is not as "flexible" as arbitrary test code.
2. Compiler-enforced type safety is many orders of magnitude easier to maintain than the equivalent unit tests
3. Defining rigorously enforced invariants with a type system is far, far more powerful than hoping you remembered to test all the important cases.
Earlier quoted context omitted.
Do you believe that Rust's type system is as flexible, powerful, and easy to maintain as unit tests in Python?
I write and test a lot of both rust and python, so I can say quite confidently: 1. Of course a type system is not as "flexible" as arbitrary test code. 2. Compiler-enforced type safety is many orders of magnitude easier to maintain than the equivalent unit tests 3. Defining rigorously enforced invariants with a type system is far, far more powerful than hoping you remembered to test all the important cases.
Of course if you limit yourself only to problems that can be effectively solved by type system, then it may work. It is like limiting yourself only to those text processing tasks where regexs work. Yes, some text processing tasks may be much more effectively solved using a regex. But it is obvious that at some point in a more general case grep can’t replace python. It may be less apparent for compiler vs. python case but the general logic is the same.
Earlier quoted context omitted.
Yes, but in practice, is the difference significant enough to matter? I’m genuinely looking to see if I’m missing anything when favoring Python type system over Go’s.
One difference is that Python's type system is unsound. You can write code that passes `mypy --strict` but still contains functions that, for example, claim to return an `int` but actually return a `list` [0]. AFAIK it's not possible to circumvent Go's type system in such a way. [0] https://news.ycombinator.com/item?id=43508152
You can definitely circumvent Go's type system with unsafe operations (with FFI also recognized as inherently unsafe) but that's a clear boundary that you know you're crossing (albeit not quite as clear as e.g. in Rust).
Earlier quoted context omitted.
I understand your frustrations since you are forced to work within a codebase that is shared with other developers with varying levels of experience. Lua was from the get-go never supposed to be a standalone language, it is more of a complimentary language and if you fail to respect that then it becomes unwieldy, quick. It is extremely easy to shoot yourself in the foot with the language and once bad design decisions…
We were using Luajit with our own extensions with our own binding mechanisms that included automatic translation of indices. And we had A LOT of bindings. There was some "fun" there. Luajit C functions uses space indentation that becomes tabs every 8 spaces, i.e. mixed tabs and spaces. And his custom assembler for the assembly portions. I personally spent a lot of time "refactoring code to generate less garbage" as w…
To be honest I am trying to move away from LuaJIT, now that q66's cffi-lua project exists I don't have a reason to use LuaJIT from a dev productivity perspective. For speed, sure. But for my use-case regular Lua is fast enough and the added features in 5.4 over 5.1 are really nice. Plus having the option to easily edit the Lua source code if I want gives me a lot of comfort, since the codebase is way simpler than LuaJIT's.
I have removed LuaJIT from everything I use other than OpenResty. If I could, I would remove it from OpenResty but that is a huge undertaking
Yeah the garbage collector is one of the things in Lua I really don't like - in Lua 5.4 Roberto added the thing and generational GC but I'm not sure how well these work in practice. I guess I'm lucky enough in that I have never hit the upper limit where a GC cycle totally kills performance and if that ever happens I have the option of rewriting that code in C
Earlier quoted context omitted.
You mean compiler vs client reporting issues? Never safer.
Yes, but in practice, is the difference significant enough to matter? I’m genuinely looking to see if I’m missing anything when favoring Python type system over Go’s.
The fact that there still exist people to whom this is not painfully obvious is despairing me.
Earlier quoted context omitted.
Except now you're writing and maintaining twice the amount of code instead of relying on the compiler and/or type checker to help you catch those errors
Sorry, but I don't agree that static typing is a replacement for unit tests. I can see static languages having fewer unit tests, but it's not going to eliminate them.
Why are you doing double misrepresentation?
More honest discussion tactics, please.
Earlier quoted context omitted.
I write and test a lot of both rust and python, so I can say quite confidently: 1. Of course a type system is not as "flexible" as arbitrary test code. 2. Compiler-enforced type safety is many orders of magnitude easier to maintain than the equivalent unit tests 3. Defining rigorously enforced invariants with a type system is far, far more powerful than hoping you remembered to test all the important cases.
Your 2-3 points remind me of the quote by Ludwig Wittgenstein: “The limits of my language means the limits of my world.” Of course if you limit yourself only to problems that can be effectively solved by type system, then it may work. It is like limiting yourself only to those text processing tasks where regexs work. Yes, some text processing tasks may be much more effectively solved using a regex. But it is obvious…
We all deploy to production, dude.
Strong static typing (Rust), even only dynamic strong typing + pattern matching (Elixir), are leagues better than Python. Literal 3x - 7x less code and less production errors both in Elixir and Rust, over the course of 5 years.
You're the one limiting yourself. Expand your horizons.