Aloso

  • 2 Posts
  • 50 Comments
Joined 1 year ago
cake
Cake day: June 13th, 2023

help-circle




  • AlosotoRustCould rust do with a crates.io alternative?
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    1 year ago

    I don’t understand the “serde2” issue. Isn’t “someusername/serde” strictly worse than “serde2”?

    GitHub being the only auth provider is something the maintainers wanted to fix, but didn’t have enough bandwidth to implement. I think they would welcome contributions!


  • AlosotoRustThe ???? operator
    link
    fedilink
    arrow-up
    7
    ·
    edit-2
    1 year ago

    If all you do in the Err(e) => ... match arm is returning the error, then you absolutely should use the ? operator instead.

    If the match arm also converts the error type into another error type, implement the From trait for the conversion, then you can use ? as well.

    If you want to add more information to the error, you can use .map_err(...)?. Or, if you’re using the anyhow crate, .with_context(...)?.



  • Apparently the maintainer trusted the first-time contributor enough to propose tackling another bug.

    There is no trust needed when asking someone to fix a bug. It’s not like the maintainer would lose anything if the contributor failed to fix the bug.

    Besides, I think it is natural to want recognition when you do a lot of work for free. Many other people wouldn’t do this unpaid work at all; recognizing their contribution is the bare minimum of good manners. Even in a company where employees are paid for their work, it is customary to give credit to co-workers who have helped you. Most people don’t like to work in places where they don’t feel appreciated, and that is also true in Open-Source.


  • It’s not possible to instantiate or assign, which is more like a never type than a unit

    Actually, this is because void is not a type, it is just a keyword, a placeholder used instead of the return type when a function doesn’t return anything.

    If it were a bottom type, that would mean that a method returning void must diverge, which is simply not true.

    Also, if it were a bottom type, it would be possible to write an “unreachable” method

    void unreachable(void bottom) {
        return bottom;
    }
    

    Even though it couldn’t be called, it should be possible to define it, if void was a bottom type. But it is not, because void isn’t a bottom type, it’s no type at all.



    • Svelte/Vue/React components need to be compiled
    • JavaScript should be minified if the project has a significant size
    • File names should have a content hash, so they can be cashed in the browser
    • Even with HTTP/2, there’s still a case to be made for bundling hundreds or thousands of JS modules into a single file for better performance
    • Bundlers give you a dev server with live reload and hot module replacement for great developer experience
    • Setting up Vite is really easy and requires minimal configuration (compared to Webpack, for example)

  • AlosotoProgrammingLet's talk about Zig
    link
    fedilink
    arrow-up
    4
    ·
    edit-2
    1 year ago

    Easy interop with legacy code is how kotlin took off, so maybe it will work out?

    Good interop was a requirement for widespread adoption, but not the reason why programmers want to use it. There’s also null safety, a much nicer syntax, custom DSLs, sealed classes, type inference, data classes, named and optional arguments, template strings, multi-line strings, computed properties, arbitrary-arity function types, delegation, custom operators, operator overloading, structural equality, destructuring, extension methods, inline functions and non-local control flow, reified types, …

    Some of these features have since been added to Java.




  • I’ve been using Manjaro with KDE for a few years now. It works smoothly, I never ran into any issues with it.

    The pacman package manager is pretty nice, too, I found it faster and easier to use than apt-get, and the provided packages are always kept up-to-date. Updating the system (even installing a newer Linux kernel) is very simple and works reliably. So you always have the latest version of your apps, the kernel, and the DE.

    In the rare occasion that a program is not available in the official repositories or the community-maintained AUR, you can also install snap or flatpak packages.

    And since Manjaro is derived from Arch, you can use the Arch Wiki, which is very useful when you want to set up a database, use the android debug bridge, install another package manager, or do anything else less than trivial.



  • AlosotoProgramming[help] So I cant' fork the fork of repo?
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    1 year ago

    Whenever possible, it’s recommended to work in a common Git repository and use branching strategies to manage your work. However, if you do not have write access for the repository you want to contribute to, you can create a fork.

    A fork is a personal copy of the repository and all its branches, which you create in a namespace of your choice. Make changes in your own fork and submit them through a merge request to the repository you don’t have access to.

    https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html

    How is this different from GitHub?

    Just to make sure there’s no misunderstanding: When I want to contribute to a project I’m not involved in, like inkscape, I’m not allowed to create a branch in their repo, so I have to fork it, which creates a copy of the repo, and sets the original repo as a remote.

    Note that git is a distributed VCS that doesn’t distinguish between servers and clients. Forking and cloning are the same operation from a technical perspective, except when you git clone, the copy ends up on your local machine, and when you press the “fork” button, the copy is on a GitHub/GitLab server.


  • Over the years people have developed an unbelievable number of coding languages. They all do pretty much the same job in pretty much the same way.

    That’s one way to say that you don’t know a lot about programming languages.

    Personally I have coded in Mercury Autocode, COBOL, FORTRAN, PL/1, LISP, Assembler, PERL, basic, C, C++ and JavaScript plus probably some others I have forgotten.

    Sadly, there’s no functional language in this list except LISP.

    JavaScript’s longevity is assured for one reason. Browsers only support JavaScript.

    Incorrect, browsers also support WebAssembly, which allows many languages (including C, C++, Rust, zig, Go, and many more) to run in the browser. And even without WebAssembly, languages can be transpiled to JavaScript, so you don’t need to code in JavaScript to run your code in the browser. Languages that can be transpiled to JavaScript include TypeScript, CoffeeScript, Reason, Elm, PureScript, Dart, Kotlin, Scala, Nim, …

    However JavaScript has a flaw.

    Not just one. Every programming language is flawed. Some languages have no type safety, some have no memory safety, some have no thread safety (or no multithreading to begin with), some are too slow for certain applications, some have an incomprehensible or verbose syntax, most support only one (sometimes two) paradigms (functional / imperative / object-oriented / logical), some have no proper module system, or no control over mutability, or visibility, or memory allocation, or side effects… some lack ergonomic error handling, or cooperative multitasking facilities such as coroutines, or generators, or macros, or reflexion…

    If you don’t appreciate the vast design space that is programming languages, of course you won’t understand why there are so many of them.


  • AlosotoProgramming QuotesPremature optimization
    link
    fedilink
    arrow-up
    8
    ·
    edit-2
    1 year ago

    Unfortunately, this quote is often taken out of context to argue that optimization is not important. Here’s the full quote:

    Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.

    In other words, you should optimize your code after you have profiled your program to find out which sections are most performance-sensitive, and you should use benchmarks to verify that the optimizations you have applied are beneficial.