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/)Z
Posts
1
Comments
56
Joined
3 yr. ago

  • One thing that I don't think anyone else has mentioned is data structures. Bash does have arrays and hashmaps at least but I've found that working with them is significantly more awkward than in e.g. python. This is one of several reasons for why bash doesn't scale up well, but sure for small enough scripts it can be fine (if you don't care about windows)

  • Why do you think that? "this one is legit" implies that they know what script this is

  • One problem with this question is that UBI can be implemented in different ways and the way that it is implemented is very important.

    I think that the way most people think about UBI is that you would get enough money to not have to work. I don't think that this is compatible with capitalism, because the main reason why people work is because they are pressured into it for economic reasons so removing that without providing people with some other reason to work will just cause the economy to collapse.

    Even if people work for some other reason than money, you will still have the problem that UBI undermines itself. As less people work for money, the money you get from the UBI program will also mean less. Not only do you need a different way to encourage people to work, but you also need a new way to distribute the products of that work if you want to ensure that everyone has access to basics like food and housing.

    For these reasons I don't think that a UBI that offers people the option of not working is compatible with capitalism. Capitalism is the system that we use to distribute work and resources and if we implement UBI we will have to invent new systems to do those things instead.

    It is still possible to have a smaller UBI under capitalism if your goal is to for example prevent money from getting to concentrated among the rich and instead stimulate the economy, or something.

  • Ah ok just read the article and not the proposal. I'm surprised that they went that far but as I wrote I think that lifetime annotations are a good idea, hope the C++ people find a way to add them to the language that actually works well, which sounds like an incredibly difficult task.

  • I'm a bit skeptical that a borrow checker in C++ can be as powerful as in rust, since C++ doesn't have lifetime annotations. Without lifetime annotations, you have to do a whole program analysis to get the equivalent checks which isn't even possible if you're e.g. loading dynamic libraries, and prohibitively slow otherwise. Without that you can only really do local analysis which is of course good but not that powerful.

    Lifetime annotations in the type system is the right call, since it allows library authors to impose invariants related to ownership on their consumers. I doubt C++ will add it to their typesystem though.

  • Vim sort of already has this feature via set foldmethod=syntax. This doesn't work exactly like the author suggests but you can also use set foldmethod=expr and then set foldexpr to a more complicated expression to only get nested function/method bodies, via tree sitter for example if you're on neovim.

  • My favorite example of haskell arcane wizardry is löb. It's mentioned in this list but not really done justice imo.

  • To add on this, this doesn't necessarily mean that there are fewer programing jobs in total. If people work 10% more efficently, that means that the cost of labor is only 91% of what it was before meaning that people might be able to afford to finance more programing projects. One thing that does matter is for example things like entry level jobs disappearing or the nature of the work changing. Doing less boring gruntwork can make the job more fun, but otoh digitization sometimes results in the worker having less agency in what they do since they have to fit everything into a possibly inflexible digital system.

  • I'm using "OOP" more in the sense that is described in the article, but that is a fair perspective on rust and OOP. It is a term with a lot of different interpretations after all.

  • Curious to hear what in Rust could be more easily solved with OOP! I think one reason for rust not using OOP is because they want to minimize dynamic dispatch and keep it explicit where it happens, because it's a language that gives you very fine grained control of resource usage, kinda similar to how you have to be explicit about copying for most types. Most trait calls are static dispatch unless you have a Box::<dyn SomeTrait>

  • What do you mean by its predecessor? C++? I think rust has a bunch of advantages. For one, designing a new language today gives you the benefit of hindsight meaning that they have a more cohesive set of features and a nicer standard library compared to C++ that has some bloat and cruft as a natural result of it evolving over several decades. It's also much easier to reason about undefined behavior in rust thanks to unsafe. Algebraic data types are really nice and traits are better than classes.

    The borrow checker isn't just useful for low level programming. One of the other main selling points is "fearless concurrency" or essentially the fact that the borrow checker can help you reason about thread safe vs non thread safe data.

  • I dunno, CMake has one of the worst syntaxes I've ever seen, and despite that it's one of the most popular languages used for C/C++ build scripting. This is because it has certain technical benefits compared to its competitors. I'm certain that having "bad" syntax is a disadvantage but it's less important than other factors. Also I don't think that Rusts syntax is universally disliked either.

  • If you're hobby programming then do whatever you want obviously but if you're part of some sort of larger project that's trying to decide between Rust and C++ then subjective aesthetic arguments probably aren't going to be considered as heavily as technical ones (and rightfully so), which in Rusts case could be that certain classes of bugs are impossible. That's not to say that it's not possible to make a technical case for C++ over rust but syntax preferences probably aren't going to play a large role in how widely used either languages are, which is good.

  • I don't think that everyone has to switch to rust or anything but "I dislike the syntax" and "I only want familiar things" are really bad arguments for not using a language. Try something outside of your comfort zone for a bit, it will help you grow as a programmer.

  • I'm surprised that no one seems to have brought up curl, which is maintained by Daniel Stenberg who is Just Some Guy™

  • Ideally I'm working on a short lived branch that only I'm working on in which case I do a rebase from origin/master where I also touch up the history in case there are any "forgot x in the previous commit" type of commits before doing a merge request. I won't rebase code someone else might have pulled, and I'll quit rebasing if I get any non-trivial conflicts .