• 0 Posts
  • 40 Comments
Joined 2 years ago
cake
Cake day: June 18th, 2023

help-circle

  • Mojo’s starting point is absurdly complex. Seems very obviously doomed to me.

    Julia is a very clever design, but it still never felt that pleasant to use. I think it was held back by using llvm as a JIT, and by the single-minded focus on data science. Programming languages need to be more opportunistic than that to succeed, imo.




  • Out of the ones you listed I’d suggest Julia or Clojure. They are simple and have interactive modes you can use to experiment easily.

    Experienced programmers often undersell the value of interactive prompts because they don’t need them as much. They already have a detailed mental model of how most languages behave.

    Another thing: although Julia and Clojure are simple, they are also quite obscure and have very experimental designs. Python might be a better choice. From a beginner’s perspective it’s very similar to Julia, but it’s vastly more popular and lots of people learn it as their first language.

    Based on the languages you found, I’m guessing you were looking for something simple and elegant. I think Python fits this description too.




  • They are not stupid at all. Their interests are in conflict with the interests of tech workers and they are winning effortlessly, over and over again.

    The big tech companies are all owned by the same people. If these layoffs cause google to lose market share to another company, it’s fine because they own that company too.

    What matters is coordinating regular layoffs across the whole industry to reduce labour costs. It’s the same principle as a strike: if the whole industry does layoffs, workers gradually have to accept lower salaries. In other words, the employers are unionised and the employees are not.

    This process will probably continue for the next 20 years, until tech workers have low salaries and no job security. It has happened to countless industries before, and I doubt we are special.

    I’m sure the next big industries will be technology-focused, but that’s not the same as “tech”. They won’t involve people being paid $200k to write websites in ruby.



  • “As we’ve said, we’re responsibly investing in our company’s biggest priorities and the significant opportunities ahead,” said Google spokesperson Alex García-Kummert. “To best position us for these opportunities, throughout the second half of 2023 and into 2024, a number of our teams made changes to become more efficient and work better, remove layers, and align their resources to their biggest product priorities. Through this, we’re simplifying our structures to give employees more opportunity to work on our most innovative and important advances and our biggest company priorities, while reducing bureaucracy and layers”

    There was this incredible management consultant in france in the 18th century. Name eludes me, but if he was still around Google could hire him and start finding some far more convincing efficiencies.

    The guy was especially good at aligning resources to remove layers


  • I greatly fear refactoring in Rust. Making a single conceptual change can require a huge number of code changes in practice, especially if it’s a change to ownership.

    Refactoring in languages like Java and C# is effortless in comparison, and not error prone at all in a modern codebase.

    You can use RC and clone everywhere, but now your code is unreadable, slow, and might even have memory leaks.

    You can use slotmaps everywhere, but now you’re embedding a different memory model with verbose syntax that doesn’t even have first-class references.

    I don’t even dislike Rust; I recently chose it for another project. I just think it has clear weaknesses and this is one of them.


  • porgamrer@programming.devtoProgramming@programming.dev...
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    8 months ago

    I believe Mercury is intended to be comparable to languages like Java, C# and Ocaml, in terms of the performance profile and generality. I don’t know what it’s like in practice though.

    I view it more as a fascinating proof of concept than a language I’d actually like to use. Really I just want new projects to steal ideas from it.


  • Datalog is sometimes used as an alternative to SQL. Prolog is used by researchers experimenting with rule systems (e.g. type systems, theorem provers, etc).

    Mercury has been used to write regular desktop software, with a couple of notable successes.

    One way to think about Mercury is that it’s like Haskell, except it’s so declarative that the functions can run backwards, generating arguments from return values! Obviously that comes with some pretty big caveats, but in many cases it works great and is extremely useful.


  • Prolog, Mercury, Datalog. Very of intrigued by Verse now that I know it has some logic programming features.

    Mercury is, roughly, a fusion of Haskell and Prolog. Bizarre and fascinating.

    Prolog and Datalog are great but not aimed at general purpose programming.

    Really I just want to see more people trying to adapt ideas from logic programming for general purpose use. Logic programming feels truly magic at times, in a way that other paradigms do not (to me at least).




  • What a whirlwind!

    Also, Rust is perhaps, the shittiest, slowest compiled language out there. Even TCC has a leg up on it.

    TCC is written exclusively to compile quickly, not to do any real optimisation. There is no conceivable situation in which TCC output will outperform equivalent Rust code.

    If you really like how Rust handles its syntax, use a real functional language like OCaml

    Rust takes inspiration from OCaml in almost every area except syntax. Close to zero syntax similarly.

    In fact, SML compilers like MLton are sometimes faster than Rust.

    Lmao, this is a classic line from ~2009 message boards, but with “C++” swapped out for Rust.

    Almost every single thing you said is wrong, but in a way too precise to be attributed to random noise. Like scoring zero in a multiple choice exam. I don’t know if you are some kind of performance art troll, but please continue. I’m an instant fan of your work.


  • Is it really fair to say retain doesn’t compose as well just because it requires reference-based update instead of move-based? I also think using move semantics for in-place updates makes it harder to optimise things like a single field being updated on a large struct.

    It also seems harsh to say iterators aren’t a zero-cost abstraction if they miss an optimisation that falls outside what the API promises. It’s natural to expect collect to allocate, no?

    But I’m only writing this because I wonder if I haven’t understood your point fully.

    (Side note: I think you could implement the API you want on top of retain_mut by using std::mem::replace with a default value, but you’d be hoping that the compiler optimises away all the replace calls when it inlines and sees the code can’t panic. Idk if that would actually work.)



  • 5 years ago everything was moving to TypeScript. Now everything has moved. Developers are still catching up, but it will be one-way traffic from here.

    I’m guessing your manager thinks TypeScript is like CoffeeScript. It is not like CoffeeScript.

    Also, TypeScript is only the beginning. In the halls of the tech giants most devs view TypeScript as a sticking plaster until things can be moved to webassembly. It will be a long time until that makes any dent in JS, but it will also be one-way traffic when it does.