![](https://programming.dev/pictrs/image/8aa73c24-f2a3-41c7-bbd3-a777419d588a.jpeg)
![](https://programming.dev/pictrs/image/170721ad-9010-470f-a4a4-ead95f51f13b.png)
hackthebox is essentially a puzzle solving platform where the puzzles are designed to teach you hacking. You’re not supposed to hack the platform.
Principal Engineer for Accumulate
hackthebox is essentially a puzzle solving platform where the puzzles are designed to teach you hacking. You’re not supposed to hack the platform.
It’s not just about learning a language. Given two equivalent languages, writing a project using one or the other is always going to be less work and less of a maintenance burden than writing it using both. A competent manager will take that into account when deciding what tools to use. On top of that, learning a new language has a cost. Of course Rust and JavaScript are not equivalent, but which one is ‘better’ is highly subjective and dependent on how you measure ‘better’. So a manager needs to take that into account. But my fundamental point is that using two languages for a project adds overhead, and learning a language adds overhead, so unless cost (including time) is irrelevant, there must be a compelling reason to choose a dual-language solution* over a single-language solution, and to chose a solution that requires your devs to learn a new language over one that does not. Not to mention switching platforms has a massive cost if your project is already mature. Even if you’re creating a new project, if your team already knows JavaScript and doesn’t have any particular objection to Electron, there’s no compelling reason.
If there is a good reason to learn a language then people will.
Sure. Except in my experience interviewing candidates and from what I’ve seen online, there are a lot of developers out there who aren’t very good. I am not optimistic that the average developer will have an easy time learning a new language. If the “we” in “Is this the electron alternative we’ve been waiting for” is you and I, that’s not a problem. But if OP meant to suggest there will be a large-scale shift away from Electron, then the average developer is quite relevant.
*As someone else pointed out, Dioxus is designed with the intent that you’ll right the frontend in Rust, so it’s not exactly dual-language like I thought.
Ah, well that’s great for folks who already know or want to learn Rust
I seriously doubt that a dual-language platform is ever going to supplant Electron. Electron has the major advantage that the entire app is written in one language. And according to Stack Overflow’s 2023 developer survey, 66% of devs use JavaScript, 45% use Python, 43% use TypeScript, and 12% use Rust. More devs use Java, C#, C++, PHP, and C than Rust. So 2/3 of developers wouldn’t have to learn a new language to use Electron, and only a small fraction of the remainder knows Rust.
I was trying to make a point without starting a flamewar that was beside the point. Personally I’d never choose a dynamically typed language for a production system. That being said, Python and Ruby complain if you try to add an array, dict/hashmap, string, or number to another (of a different type) so they’re certainly more sane than JavaScript.
I thought it was clear I was saying JavaScript is not a sane language for this very reason
Sure. But in a sane language doing something totally nonsensical like that is an error, and in a statically typed language it’s a compiler error. It doesn’t just silently do weird shit.
I used GitLab’s version of Copilot when it was free and that was net helpful. It predicted for loops and stuff and was close enough, enough of the time that it was net positive. Not enough that I’d actually pay for it…
Sure, there are worse languages and environments to get stuck with. But I can avoid those jobs. And if I get hired as a SomeLang developer and they force me to work in Java or whatever, it’s time to dust off the resume.
I am aware of that, but Java is the most popular language that runs on the JVM. I don’t specifically dislike other JVM languages, though one of my issues is type erasure and that’s partially a limitation of the JVM.
Obviously OpenJDK is superior to dealing with Oracle’s bull. But even more superior (IMO) is simply not using Java. My life has been noticeably more pleasant since I started refusing to touch Java.
You consider calculating the hash of a few bytes to be heavy lifting?
just use
await
in anasync function
.
Sure, I’ll just put await
and async
everywhere. Oh wait, I can’t. A constructor can’t be async so now I need to restructure my code to use async factories instead of constructors. Wonderful…
async/await infecting all of my code, being unable to create a get myField()
method that involves a hash calculation. It may be standard to do heavy lifting concurrently, but async hash functions are certainly not standard in any of the languages I’ve used (which is quite a few).
That seems like a good guess, I can see why async hashing could be useful. But it would be nice if there was an alternative API that was blocking so my code wouldn’t get infected with async/await all over the place…
It’s hard to distinguish whether a line is wrongly indented or not.
That’s very much not my experience. I use YAML regularly and while I’ve had copy paste indentation errors when I look at the offending line it’s always obvious to me how to fix the indentation. The only indentation thing that’s ever given me trouble is embedding YAML as a string within a file that uses tabs.
As someone whose first language was C, I plan to never use C++ for anything more than programming an Arduino precisely because of the multitude of pointer types. A pointer should just be a pointer. Having five hundred different flavors of pointers is confusing as fuck.
Ananace and the article they linked are using their dislike of Go to conclude that it’s a bad language*. It is not a bad language. Every language has hidden complexity and foot guns. They don’t like Go. Maybe you won’t like Go. That’s ok. But that doesn’t make Go a bad language. The language designers are very opinionated and you might dislike them and their decisions.
I haven’t used Rust but from what I’ve seen, it’s a lot less readable than Go. And the only thing more important than readability is whether or not the code does what it’s supposed to do. For that reason I doubt I’ll ever use Rust outside of specific circumstances.
*I’m using “a bad language” as shorthand for “a language you shouldn’t use”. Maybe they don’t think it’s bad but amounts to the same thing.
I think it’s a joke about the song being copyrighted
That’s an artifact of JavaScript, not JSON. The JSON spec states that numbers are a sequence of digits with up to one decimal point. Implementations are not obligated to decode numbers as floating point. Go will happily decode into a 64-bit int, or into an arbitrary precision number.