Yes. Am not robot.

  • 0 Posts
  • 23 Comments
Joined 1 year ago
cake
Cake day: June 6th, 2023

help-circle



  • Cargo is doing too many things at once. It’s a build system but also a package manager but also manages dependencies? Idk what to even call it.

    Coming from Java where you have no standard tool and two current defacto standards (Maven and Gradle) which do similar things in a less clean or standardised way, I think Cargo is one of the least contentious parts of the Rust experience.

    Supposively bad typescript

    Correct. Bad Typescript. You haven’t provided any of the type information to make this a TypeScript construct (this is just JavaScript)

    It should be something like…

    interface Person {
        name: string,
        age: number,
    }
    
    const person: Person = {
      name: "joe",
      age: 23,
    }
    

    And the Rust equivalent being something like

    struct Person {
        name: String,
        age: u8,
    }
    
    let person = Person {
        name: "joe".to_string(),
        age: 23,
    };
    

    i32 i64 i8 f8 f16 f32 instead of a single unified “number” type like in typescript.

    Those all have different sizes and capabilities. The lack of these requires the JS JIT compiler to try and guess (and deoptimise when it’s wrong).

    Even in C you can just write “int” and be done with it so it’s not really a “low level” issue.

    No, you can’t - https://en.wikipedia.org/wiki/C_data_types

    • Similarly, Async code starts to look really ugly and overengineered in rust.
    • Having to use #[tokio:main] to make the main function async (which should just be inbuilt functionality, btw tokio adds insane bloat to your program) yet you literally can’t write code without it. Also what’s the point of making the main function async other than 3rd party libraries requiring it?

    I agree the Rust Async experience feels a little messy, and the lack of an opinionated default makes even the foothills a steeper climb than we might hope. However given all that it’s trying to achieve (in terms of Rust drives for efficiency and safety) I don’t have any better ideas right now.

    Speaking of bloat, a basic get request in a low level language shouldn’t be 32mb, it’s around 16kb with C and libcurl, despite the C program being more lines of code. Why is it so bloated? This makes using rust for serious embedded systems unfeasible and C a much better option.

    I don’t know how you’re getting to 32MB. A release build of the most basic form of a get request is not that bad.

    A simple chatgpt generated one app to get the content of an HTTPS URL, using reqwest and tokio is 4MB. I expect this can be reduced with options.

    However yes, the default Rust build (with all of the panic machinery and more) is bigger than C. But Rust doesn’t have to be the best choice for every niche, to be an excellent choice for several. With that reasoning your return to TypeScript is equally flawed.

    Another major issue I’ve encountered is libraries in Rust, or lack thereof. Every single library in rust is half-baked.

    Coming from Java, Rust’s young ecosystem is definitely noticeable. It’s taking a while for it to grow, to mature, and for clearly dominant frameworks to emerge for various problem-spaces.

    Java, like Rust, is not opinionated about the frameworks, but the size and age of the community means that clearly dominating frameworks emerge with huge contributor bases - Rust just isn’t quite there yet.

    As for “memory safety”, it’s a buzzword. Just use a garbage collector. They’re invulnerable to memory issues unless you write infinite while loop and suitable for 99% of applications.

    Again, coming from Java (which has a number of excellent GC implementations), Rust takes this a lot further (an alternative to null, protection against aliasing bugs). While I’m still fundamentally a Java developer, what Rust achieves here is significant.

    Then use C or C++ if you really need performance. Both of them are way better designed than Rust. In most cases though it’s just bikeshedding. We’re not in 1997 where we have 10mb of ram to work with, 9/10 times you don’t need to put yourself through hell to save a few megabyes of a bundle size of a web app. There are apps with billions of users that run fine on php. Also, any program you write should be extensively tested before release, so you’d catch those memory errors if you aren’t being lazy and shipping broken software to the public. So literally, what is the point of Rust?

    Tell me you don’t pay to run anything large on cloud infrastructure without telling you don’t pay to run anything large on cloud infrastructure. There’s a cost to CPU and RAM. Java does okay on the first, but has a long history of doing poorly on the second (c’mon Valhalla - a Java enhancement project that will help here).

    Who cares? Coding is a tool to get shit done and I think devs forget this way too often, like if one works easier than the other why does learning lower level stuff matter? It’s useless knowledge unless you specifically go into a field where you need lower level coding. Typescript is easy, rust is not. Typescript is therefore better at making things quick, the resourse usage doesn’t matter to 99% of people and the apps look good and function good.

    Of your post, this is very nearly the only part I can somewhat agree with. Our industry primarily has more of a need for ‘solution now please’ than ‘optimal solution later’. Engineering time matters. The learning curve and cycle time of Rust are barriers.

    Also, while Rust is a very safe language to refactor in, it’s not quick to refactor in. The less ceremony and strictness there is, the easier it is to experiment and then refactor. This is, in part, why I think Python does so well in the ML/Data-science space - that niche is more R than D in the R&D balance of software development.

    So again, Rust suits some development needs better than others, now. However as it matures I think we will see it grab little pieces of the niches previously occupied by other languages. As it’s tools and libraries get better, and as the pool of familiar developers increases, Rust’s strength are going to translate more easily into dollars without costing time.

     

    I’m not ready to switch to Rust fully. But neither am I putting it aside - and I look forward to its continued improvements in libraries, language, tooling and adoption in more and more places.

    (I can say that I’m not planning on using TypeScript for any more than our front-end development though)




  • Fast moving new technology means a larger gap between the used and new market. Combine this with effects of smaller volumes per model and they start high and fall fast.

    It will change, but ‘early adopters’ are carrying some of the costs of transition - though only realise losses at time of sale (so keeping the vehicle longer will cost you less than frequent refreshes).

    Edit: and no, buying one is not foolish. For many consumers, a midrange EV is already a saving over a reasonable lifetime.







  • Most people are still using Java 8 (including android)…

    Surveys don’t seem to back this up any more… Yes there’s a lot of Java 8 code. But more and more of it is maintenance rather than new development. Respondents of surveys that are able to list the versions they use in production (vs ‘pick one’) have indicated that for many teams with exposure to Java 8, they also have newer versions in production - showing that Java 8 is increasingly about maintenance than ongoing development (with the blocks to moving forward being a mix economic and technical factors).

    The most dominant frameworks in the industry are ending their support for Java 8 - so not too far down the track, staying on Java 8 will mean that while you can pay for platform support, framework support is going to disappear anyway.

    …we are currently at ~java 20.

    Yes Java 20 is the current release, with Oracle’s LTS being Java 17 (the previous ones being 17, 11 and 8 - with 8 having the largest paid support window).

    Java 21 is out in a couple of weeks and will become the new Oracle LTS (other vendors and frameworks tend to align on this LTS designation so it continues to be important).






  • Are they kidding.

    This is slavery, not even indentured servitude, let alone a fair exchange of labour for compensation… There is no point at which the slave is released to make use of those skills.

    Any and all skills gained are either used as tools by the owner, or as coping/survival mechanisms by the slave.

    Slavery is, in all ways, an abhorrent exploitation and degradation of a human being.

    That there is even the slightest tolerance for this curriculum change is appalling. Is Florida really so filled with the morally bankrupt and apathetic that this can pass without ending the careers of the contributors?

    How can we ever expect greater progress on stamping out the ongoing modern forms of slavery, when things like this can make its way into the classroom.

     

    I really hope this change is crushed before it reaches the ears of impressionable children. But the fact that it got this far means that this is the kind of thinking that too many already get at home.