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.

hackthebox is essentially a puzzle solving platform where the puzzles are designed to teach you hacking. You're not supposed to hack the platform.

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.

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

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.

Linus might be an asshole but he's actually competent. Elon Musk is a fucking joke of a person. Not to mention Linus hasn't done anything that compares to things like Elon suing his way into being a "founder" of Tesla and kicking out the actual founders.

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.

monopoly: the exclusive possession or control of the supply of or trade in a commodity or service.

GitHub is not a monopoly: it has competition. If you're upset about it's market share, switch to GitLab, Bitbucket, or host your own instance. If you're upset about people not being aware of the other options, be an advocate and spread awareness of the alternatives.

I’ve written programs in C. I’ve written programs in assembly, for x86 and for microcontrollers. I’ve designed digital logic and programmed it into an FPGA. I’ve built digital logic circuits with transistors.

I’ll still take Go over C any day of the week. If I’m doing embedded, I’ll use TinyGo.

I absolutely detest leetcode style interview questions. I am good at solving problems and writing modular code. I am not good at writing search algorithms. Any guesses which one of those is more relevant to my job? 99% of development does not involve writing low level algorithms, because guess what someone else already did that for you, it's called a library!

Cost: Docker licenses for most companies now cost $9/user/month

Are you talking about Docker Desktop and/or Docker Hub? Because plain old docker is free and open source, unless I missed something bug. Personally I've never had much use for Docker Desktop and I use GitLab so I have no reason to use Docker Hub.

My point is that Docker Desktop is entirely optional. On Linux you can run Docker Engine natively, on Windows you can run it in WSL, and on macOS you can run it in a VM with Docker Engine, or via something like hyperkit and minikube. And Docker Engine (and the CLI) is FOSS.

I just share one window at a time. I put the meeting on one half and the window I want to share on the other, which makes it 16:9 and works perfectly for what I need to share.

Better to not have version control!? Dear god I hope I never work on anything with you.

GitLab. You can use their SaaS offering (gitlab.com) or run the open source version on your own server(s).

Most experienced developers already agree with you

Maybe these days. That definitely was not true when I was growing up, or even a decade ago.

One of my problems is that I've gotten so practiced at reading code that my standards for "this is readable, it doesn't need much commenting" are much lower than those of the other developers I work with. I've had to recalibrate from "Will I be able to understand this six months from now?" to "Will I need to explain this in the review?"

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.

I've been working primarily in Go for the past five years, including some extremely complex projects, and I have never once wished I had dependency injection. It has been wonderful. I have used dependency injection - previously I worked on a C# project for years, and that used DI - but I adore Go's simplicity and I never want to use anything else (except for JS for UI, via Electron or Wails for desktop).

Edit: If we're talking about dependency injection in the general sense (separation of concerns, modularization, loose coupling), then yeah I agree that's kind of critical to writing good, maintainable software. When I hear "dependency injection" I think of frameworks such as Unity, and that is what I was specifically talking about - I am very happy with the fact that I have felt zero need to use any framework like that over the last five years.

You’re also a programming language design nerd? Like, “Compare the features of language A to those of language B”, or nerding out about the underlying mechanics of things like generic types, virtual method dispatch, and no-stop garbage collection? I thought I was the only one. Well not the only one but it doesn’t seem that popular of a thing to nerd out over.

That sounds like a great way to set yourself up for spectacular failures down the road

When it happens? That happened to me a long time ago. I’m still a backend developer. I can create UIs and I can spin up and manage docker CI infrastructure but I sure as hell don’t want to. A properly run company team should have separate professionals for UX, front end, back end, sysadmin, etc. Just because I am capable of doing those things does not mean I should.

I understand the principles, how branch prediction works, and why optimizing to help out the predictor can help. My question is more of, how often does that actually matter to the average developer? Unless you're a developer on numpy, gonum, cryptography, digital signal processing, etc, how often do you have a hot loop that can be optimized with branchless programming techniques? I think my career has been pretty average in terms of the projects I've worked on and I can't think of a single time I've been in that situation.

I'm also generally aggravated at what skills the software industry thinks are important. I would not be surprised to hear about branchless programming questions showing up in interviews, but those skills (and algorithm design in general) are irrelevant to 99% of development and 99% of developers in my experience. The skills that actually matter (in my experience) are problem solving, debugging, reading code, and soft skills. And being able to write code of course, but that almost seems secondary.

I could use Google but I’m looking for opinions not just what journals have that kind of content

“Feeding garbage to OCR” is a really boring way of generating text. I was assuming it would be something more interesting, like creating a symbolic representation of the splatters and generating text from that. Using OCR is basically piping /dev/urandom to perl and seeing what happens. The fact that they’re valid perl programs is worth a laugh but the generation method is totally uninteresting.

I am all aboard the code readability train. The more readable code is, the more understandable and therefore debuggable and maintainable it is. I will absolutely advocate for any change that increases readability unless it hurts performance in a way that actually matters. I generally try to avoid nesting ifs and loops since deeply nested expressions tend to be awful to debug.

This article has had a significant influence on my programming style since I read it (many years ago). Specifically this part:

Don't indent and indent and indent for the main flow of the method. This is huge. Most people learn the exact opposite way from what's really proper — they test for a correct condition, and if it's true, they continue with the real code inside the "if".

What you should really do is write "if" statements that check for improper conditions, and if you find them, bail. This cleans your code immensely, in two important ways: (a) the main, normal execution path is all at the top level, so if the programmer is just trying to get a feel for the routine, all she needs to read is the top level statements, instead of trying to trace through indention levels figuring out what the "normal" case is, and (b) it puts the "bail" code right next to the correctness check, which is good because the "bail" code is usually very short and belongs with the correctness check.

When you plan out a method in your head, you're thinking, "I should do blank, and if blank fails I bail, but if not I go on to do foo, and if foo fails I should bail, but if not i should do bar, and if that fails I should bail, otherwise I succeed," but the way most people write it is, "I should do blank, and if that's good I should do foo, and if that's good I should do do bar, but if blank was bad I should bail, and if foo was bad I should bail, and if bar was bad I should bail, otherwise I succeed." You've spread your thinking out: why are we mentioning blank again after we went on to foo and bar? We're SO DONE with blank. It's SO two statements ago.

I think it’s a joke about the song being copyrighted

I’ve been using GitLab for years. I have a GitHub account but at this point I only use it to contribute to other projects.

Do you use the command line for everything? Do you edit with vim, view diffs with git diff, browse the web with links or lynx?

GUIs are useful tools. I’m happy with VSCode’s git integration. It’s just what I need for basic stuff like staging files and committing. I use the CLI whenever I want to do something like rebasing because I can type that command faster than I can figure out the GUI, but it would be stupid to artificially force myself to use the CLI for everything because of some kind of principal.

After programming in Go for nearly a decade, the idea of going back to needing semicolons brings me pain. Rust seems cool, but semicolons 🤢

One of the reasons I love Go is that it makes it very easy to collect profiles and locate hot spots.

The part that seems weird to me is that these articles are presented as if it's a tool that all developers should have in their tool belt, but in 10 years of professional development I have never been in a situation where that kind of optimization would be applicable. Most optimizations I've done come down to: I wrote it quickly and 'lazy' the first time, but it turned out to be a hot spot, so now I need to put in the time to write it better. And most of the remaining cases are solved by avoiding doing work more than once. I can't recall a single time when a micro-optimization would have helped, except in college when I was working with microcontrollers.

Fortunately for me, VSCode has support for running the backend remotely via SSH.

Senior engineers have learned through hard-won experience that writing code is the ultimate diminishing return.

I feel seen. That entire section is absolute gold.

If over-worked, he needs to talk to his manager or whoever the work is coming from and tell them they need to slow it down

The first part of this article is taking about naming, and then heavily implies “CSS/HTML is not a programming language” is equivalent to devaluing front end developers. But that’s not the case, at least not for me.

Front end is hard. It is obnoxiously hard and requires both artistry and technical skill. And it’s critical to the success of anything that has a front end.

But I still say, “CSS/HTML is not a programming language”, because they’re not Turing complete. A programming language is something you can write a program in, without any other languages. It’s a matter of definition, not a matter of valuation. CSS and HTML are difficult and critical to get right but they’re a different kind of thing from programming languages.

"Flagged as spam", "Publication Not Available". I can't see the article.

You don't have to be a full stack dev for that to happen to you

If you want your code to run on the GPU, the complete viability of your code depend on it.

Because of the performance improvements from vectorization, and the fact that GPUs are particularly well suited to that? Or are GPUs particularly bad at branches.

it is only one of the many micro-optimization techniques you can do to take a few nanoseconds from an inner loop.

How often do a few nanoseconds in the inner loop matter?

The thing to keep in mind is that there is no such thing as “average developer”. Computing is way too diverse for it.

Looking at all the software out there, the vast majority of it is games, apps, and websites. Applications where performance is critical, such as control systems, operating systems, databases, numerical analysis, etc, are relatively rare compared to apps/etc. So statistically speaking the majority of developers must be working on the latter (which is what I mean by an "average developer"). In my experience working on apps there are exceedingly few times where micro-optimizations matter (as in things like assembly and/or branchless programming as opposed to macro-optimizations such as avoiding unnecessary looping/nesting/etc).

Edit: I can imagine it might matter a lot more for games, such as in shaders or physics calculations. I've never worked on a game so my knowledge of that kind of work is rather lacking.