Oh yeah, I’m in favor of using type hints. People here are also saying that Pyright is more useful, which I haven’t used yet.
I was involved as the unlucky bastard supposed to sprinkle software engineering on top of a Python project 2+ years ago, and I just remember how much I understood right then and there why Python devs thought static typing was cumbersome. Felt like I had to write Java again, except it also didn’t work half the time.
Interesting. If it’s only in the type checker, can IDEs/editors correctly show the type information of inferred types then? Do they call the type checker themselves to retrieve that info?
Yeah, I only used Mypy so far. I thought it was inherent to the language spec, not the type checker.
I guess, some of your colleagues might have also just used Mypy so far, though…
In the case of Rust, you can also omit the type annotation in the vast majority of cases and the compiler will infer it.
It feels more solid to have a complex program covered by tests, yes, but how can this be confirmed in an objective way? And if it can, for which kind of software is this valid? Are the same methodologies adequate for web programming as for industrial embedded devices or a text editor?
Worth noting here that tests should primarily serve as a (self-checking) specification, i.e. documentation for what the code is supposed to do.
The more competent your type checking is and the better the abstractions are, the less you need to rely on tests to find bugs in the initial version of the code. You might be able to write code, fix the compiler errors and then just have working code (assuming your assumptions match reality). You don’t strictly need tests for that.
But you do need tests to document what the intended behaviour is and conversely which behaviours are merely accidental, so that you can still change the code after your initial working version.
In particular, tests also check the intended behaviour of all the code parts you might not have realized you’ve changed, so that you don’t need to understand the entire codebase every time you want to make a small change.
To be fair, Python doesn’t have type inference, so the type hints are quite obnoxious, and the type checkers for Python are also not as reliable as in languages with native static typing (even if that is often caused by libraries not providing type hints).
Interesting and valid point, but Kotlin’s when is not actually pattern-matching. It really is just syntactic sugar for if-else, like you’ve demonstrated.
Actual pattern-matching allows matching on the structure of a data type. So, you formulate a pattern to describe the structure and then you can choose different code paths based on whether the pattern matches or you can also access fields inside of this data type.
Rust allows pattern-matching even in variable assignments, which is going to look funky, but I think it shows quite well that pattern-matching isn’t just a fancy switch statement: https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=3a8d126fa0cb9736597793915b00dd5d
So what happens is that:
When someone writes this in Rust:
let x = 1;
It’s still pattern matching under the hood, but the pattern x is just a singular wildcard, so the right-hand side just gets ‘assigned’ to that variable name.
And with these simple examples, you might think that being able to access field values this way is silly, since you can also access them via my_data_type.foo, but it becomes more useful with deeply nested data types, and in particular in statically typed languages, it allows you to work with different data types without type casting. So, it would be more useful of a feature for TypeScript than it might be for JavaScript.
Yeah, I don’t like when corporations put stuff like that into their ToS, but at the same time, I 100% understand why every open-source license under the sun has it. You’re giving it away for free, so you don’t want people to sue for more than you’re providing for free.
Mastodon.social is currently very much in the latter camp of giving things away for free. I also understand that a service is yet another beast than a piece of software, since they hold your personal data and may leak/sell it. But yeah, at this point in time, I wouldn’t want someone to be able to sue Mastodon.social out of existence. I guess, it depends a lot on how it’s formulated in the end…
It should be noted that theoretically, we don’t know how this external API is implemented. The vast majority of APIs are REST APIs and with REST APIs, there’s a decent chance that you can download an OpenAPI definition from the server which provides the API.
REST APIs are basically APIs which use HTTP(S) for transport and then there’s some specific rules how the API should be designed. Often times, these rules are not strictly followed and people still refer to such an API as “REST”, because they assume that any HTTP API is a REST API. But yeah, similarly the guides you’ll find will likely also work with general HTTP APIs.
Sounds to me like they’re not trying to create a website for now, but rather just process some data, which they can later display in a static webpage.
So, I’m guessing something like this:
+--------+ +---------+ +----------+
| Static | | Their | | External |
| Web |---->| Own |---->| API |
| Page | | Backend | | |
+--------+ +---------+ +----------+
But yes, unless there’s a lot of data to crunch, the design one would usually go for is rather:
+-----------+ +----------+
| *Dynamic* | | External |
| Web |---->| API |
| Page | | |
+-----------+ +----------+
So, the data calculations would happen in the user’s browser. You would still need some hosting for that webpage, but there’s lots of free services to put a simple webpage up.
And yes, when you go with that latter design, then JavaScript would be the typical choice. It’s still possible to do it with Rust, using WebAssembly (e.g. a colleague of mine has built a small statistics webpage which gets data directly from GitHub, using the Leptos framework), but it is definitely the less beaten path.
Having said all that, frankly, fuck the usual way of doing things. If you’re comfortable with Hugo for frontend work, then I think it’s legit to build a little backend to take over the dynamic part. Better to build a useful project and learn something than to get stuck trying to learn the ‘correct’ path of doing it. Especially if you’d rather learn about Rust than JS.
Those Spectacle changes look good. The old UI made some amount of sense, if the primary use-case was taking complete screenshots, but even for that, there’s probably a single shortcut to do that directly.
And I do find, I generally want a smaller cutout these days, because you can just fit more stuff onto modern displays, some of which is going to irrelevant.
I could imagine that they didn’t want to do something called “Destiny 3”, because people would expect that to be better than Destiny 2, which is virtually impossible, if you’re gonna start over from scratch, with how many years of development have gone into Destiny 2 by now…
Climate change is gonna fuck this place up before I retire. I do not hope I win.
No pride for the poor, sorry.
I’ve never used Facebook, but I’ve seen people say that Friendica is quite similar to Facebook (in case you care about that).
This song in some Cyrillic language: https://open.audio/library/tracks/102128
I think, that’s not a coral, but rather a dead tree next to a stream…
Yeah, the wording is confusing. A long time ago, there was no paid software, there was only software where you got the source code and other software where e.g. it was pre-installed on some hardware and the manufacturer didn’t want to give the source code.
In that time, a whole movement started fighting for software freedom, so they called their software “free”.
Well, it didn’t feel like I’m tweaking to my needs (that came afterwards on top), it rather felt like I’m just undoing design decisions that someone made to cater to their specific needs.
And I named the time mainly to give an idea of how much there was to tweak. My main problems were:
It’s the same thing as ternary, just without the
? :syntax.