Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)LY
Posts
65
Comments
357
Joined
2 yr. ago

  • Mozilla allegedly stands for a bunch of stuff that is be definition incompatible with hosting code on GitHub as it is.

    Your statement is fundamentally wrong on many levels, including the fact that it goes against the fundamental premise of FLOSS which is that "the users have the freedom to run, copy, distribute, study, change and improve the software."

    I bet a lot of people were expecting a lot more from them (...)

    You only speak for yourself. You do not have a mandate to speak on behalf of anyone, including Firefox users such as myself. Keep your personal opinions as personal. You have the right to have a personal opinion, but you do not have the right to pass them off as anyone else's.

  • you meant that the focus of the change wasn’t GH

    They are dropping Mercurial and focusing on Git. Incidentally, they happen to host the Git project on GitHub. GitHub is used for hosting, and they don't even use basic features such as pull requests.

    Again, this is really not about GitHub at all.

  • how centeralised GitHub

    It's a pointless and irrelevant remark. Mozilla uses Git to track work on Firefox. GitHub provides Git repositories. I can clone Firefox out of GitHub, create an account on GitLab/Bitbucket, push the code there, and GitHub does not feature as a concern at all.

    What point can you possibly think you're able to make regarding GitHub?

    GitHub is enshittifying everything that has to do with Git.

    Nonsense. Speaking as someone who actually hosts the same projects on GitHub and other version control providers, GitHub does not even feature as an implementation detail.

    I'm starting to think you're just trolling.

    You should care.

    I do my best to not waste my time with irrelevant nonsense. It's silly to believe that the version control system you use has any influence on the quality of the software you deliver.

  • Github for organizations becomes rather expensive rather quickly (...)

    I'm not sure if that's relevant. GitHub's free plan also supports GitHub organizations, and GitHub's Team plan costs only around $4/(developer*month). You can do the math to check how many developers you'd have to register in a GitHub Team plan to match the operational expense of hiring a person to manage a self-hosted instance from 9-to-5.

  • A less confusing title would be “Mozilla drops support for Mercurial (...)

    It's not even about GitHub at all. Taken straight out of the announcement:

    “For a long time Firefox Desktop development has supported both Mercurial and Git users. This dual SCM requirement places a significant burden on teams which are already stretched thin in parts. We have made the decision to move Firefox development to Git.”

  • Well generally speaking, read up on solid principles. Learn how to organize your code, write code that balances efficiency and manageability.

    To me, that reads as "learn software design patterns", specially the balancing part.

  • What really helped me get better as a software engineer was going out of my way to progressively learn as many software design patterns as I could and iterate over pet projects to refactor them to apply them in practice. It helped me write cleaner code that's far easier to maintain and extend, it helped me be far more efficient at onboarding onto projects, it helped me greatly improve my skills as a software architect.

  • So, from a decentralised solution to the world’s biggest repository

    You need to check your notes. Git is decentralized, even if you host a repository somewhere.

    Decisions like these (...)

    As a Firefox user, these initiatives matter nothing in my decision to use Firefox. In fact, I'm glad they went this way. They need to focus on working on code instead of wasting their time with irrelevant details.

  • but I don’t understand why they don’t self-host

    Why would anyone self-host a FLOSS project? Trade secrets is not a concern, nor is it barring access to the source code repository. Why would anyone waste their resources managing a service that adds no value beyond a third-party service like GitHub?

  • From the article:

    (...) but recently, another type of criticism seems to be on the rise.

    The code that I suggest is too verbose. It involves too much typing.

    This reads like a one-sentence strawman. Describing code as "too verbose" is really not about the risk of carpal tunnel syndrome. It's about readability and cognitive load.

    The blogger seems to almost get the point when he writes the following:

    In short, the purpose of source code is to communicate the workings of a piece of software to the next programmer who comes along. This could easily include your future self.

    The purpose of source code is to communicate (...) to the next programmer who comes along.

    If you make the mistake of going the "enterprise quality java code" meme approach, you're making the next programmer's life needlessly harder.

    The blogger then tries to make his case with verbose code, and makes the following statement:

    Which alternative is better? The short version is eight lines of code, including the curly brackets. The longer version is 78 lines of code. That's ten times as much.

    I prefer the longer version. While it takes longer to type, it comes with several benefits. (...)

    This is yet another strawman. The longer version is awful code, not because it's longer but because it's needlessly jam-packed of boilerplate code. Ignorign basic things like interfaces and contracts, It's been proven already that bugs in code are directly proportional to the number of lines of code, and thus the code the author prefers is likely to pack ten times more bugs.

    The shorter code in this case would not be the 78-loc mess that the author picked as the thing he prefers. The shorter code in this case would be something like onboarding the project onto Project Lombok to handle all-args constructors, property methods, and even throw a builder in for free. This requires onboarding Lombok to the project, and add two annotations to the short example. Two lines of code, done.

    After the blogger fails to make his case, he doubles down on the typing non-sequitur:

    Perhaps you're now convinced that typing speed may not be the bottleneck (...)

    This is a blog post that fails to justify a click. It's in the territory of "not even wrong".

  • Kotlin is IMO easier and less error prone

    I'm no Kotlin expert, but I think Kotlin has a far more extensive core language and requires a heavier cognitive load to get up and running than Java.

    It might have better developer experience and be less error-prone, but that comes at a price of admission that newbies have to pay.

  • Surely you got a bonus and a raise out of it right? Right??

    The only reward I got from it was recognition from my team members, which was already more than what I was expecting to get.

    My manager was praised for the higher team velocity and improvements in the team's burndown chart. The hallmark of having done good work is seeing others trying to take credit for it.

  • The optimization I'm the most proud about was when I worked on a legacy project whose end-to-end builds took around 1 hour. After spending some time working on its architecture, project layout and build system, I managed to get the full end-to-end builds to take 10 minutes, and incremental builds to be almost instant.

    What makes me the most proud about this project is that the technical debt plaguing the legacy project was directly and indirectly the reason why half a dozen of my team members burned out and quit the company. After that point my remaining team members started to be far less stressed and team velocity skyrocketed, just for the fact that the thought of iterating over a bugfix and posting a pull request didn't cost at least one hour, and sometimes two or three.

  • The Rust community is a very diverse group of people with many different opinions. It is not a universal truth that the Rust community believes Rust to be an awful first language.

    You don't need to take my word for it. Google the topic and go through all the discussions. Even the ones in Rust's own forum get mixed responses, and that community is by its very nature very partial towards Rust.

    Also, framing the discussion around newbies learning Rust as a first language is a strawman. The question is not whether if someone without any prior experience in programming can or cannot make and effort and write code in Rust. The question is which language to learn.

    There are many programming languages to pick and choose from, and some are renowned to be very beginner friendly. Rust is not one of them.

    If you want to make a case for Rust, it's up to you to prove that Rust is a better language to take first steps than any other programming language around. In my personal opinion, it is simply not possible to claim that Rust is better for this particular usecase than quite a sizable set of programming languages, including but not limited to Python. If you want to claim Rust is better suited then you need to make a case for it, and that is a challenging thing to pull off.

  • You’re not making the strong case that you think you are. Quite the opposite. The ease of “shooting yourself in the foot” is precisely what makes it so difficult to learn. Segmentation faults and random memory corruption make it incredibly hard to get started with programming.

    That's not the case, though. Some C and C++ compilers are already resilient and flexible enough to not get C and C++ to blow up in your face when you're doing unmentionable things to memory access. Some memory safety issues are only noticeable when running profilers and memory safety tools.

    Keep in mind you are talking about someone taking their first steps in writing software. They are struggling to get stuff to work, and throwing curve balls at them is not going to help them get on their feet.

    Also, I did not advocated for C or C++ as better options. My point is that Rust is an awful suggestion as a first language, which even the Rust community states. It also speaks volumes to Rust's unsuitability as a beginner programming language if the best attempt to refute that fact is to try to come up with worst alternatives that in the end aren't even worse at all.

    Rust’s constraints are very clear and concise in comparison (...)

    Irrelevant. The point is that Rust enforces constraints that other programming languages don't. If anyone is taking their first steps, not having to deal with them leads to a far more productive and enjoyable experience. It's absurd to talk about memory-safety and performance when the target audience doesn't even understand what memory is.

  • This is very over-exaggerated. A lot of people started with C or C++ as their first language.

    That took place over two decades ago. There were no better alternatives back then. Times have changed.

    Both of which are significantly harder than learning Rust.

    This is simply not true. It's far simpler and less frustrating to work on either C or C++ for the simple reason that you can shoot yourself in the foot anywhere you'd like. In Rust, newbies have to alternative to endure the compiler enforcing its safety constraints anywhere they'd like. Rust is also a far more complex and extensive language that enforces memory safety rules that can and very often are very frustrating to handle by those who don't have a firm grasp on them.