6 ms·

> The problem you're having is only a problem because you haven't tried hard enough. You just need to read another 50,000 word fasterthanlime essay. Then you'l

• Keyframe 2y ago
  this reminds me of Lispen of ye olde.. wait untill it clicks, man!
  • msla 2y ago
    Lisp is pretty normal if you're accustomed to, like, Python: It's a GC'd procedural language.
    • kleiba 2y ago
      Haha, nice one! :-) (can only assume you're joking)
      • Pxtl 2y ago
        Since every other language now has higher order functions and lexical closures and things like that Lisp isn't as special as it used to be. Now it's mostly just a really ugly version of those languages but with a weird emphasis on recursion and a very fancy macro facility. I find I can move between dynamic languages and Scheme pretty easily.
        • deleted 2y ago
          [deleted]
        • cultofmetatron 2y ago
          as someone who writes elixir all day, I really love what lisp is but I feel lisp's major weakness is that it makes everythign unergonomic in order to make macros very ergonomic. You will never find another language in which writing macros is easier. the problem is it comes at the cost of doing everything else a bit of a pain in the ass. I love elixir because it feels like the syntax clojure would have if it had a syntax imho.
          • gorjusborg 2y ago
            > it makes everythign unergonomic in order to make macros very ergonomic I think 'everything is unergonomic' is a too strong of a statement to be true. I'd argue that lisp is very ergonomic for those who work with it regularly (and are into using Emacs). It sounds like you are beefing with the syntax (or lack thereof) and homoiconicity of Lisp. I can understand that. It is a very different language than others currently in the mainstream for that reason. As far as overall ergonomics, I'd say the REPL/image-based development style and the macros that are enabled due to homoiconicity actually make it one of the most ergonomic languages in existence. The biggest thing that prevents Lisp-likes from going mainstream is that it is too ergonomic, specifically, when you start reading a Lisp codebase, you essentially are signing up to learn a new project-specific dialect. Very ergonomic for writing code, but at the cost of understanding how that code operates.
          • lispm 2y ago
            > major weakness is that it makes everythign unergonomic in order to make macros very ergonomic. Generally Lisp has two main goals: * allow code to be data and data to be code * make coding and coding code (let code manipulate code) interactive The s-expression based syntax was found to be useful for both. For the latter it means that code can be manipulated interactively for example by structure editors or in read-eval-print-loops which work with data. That makes interactive code writing very ergonomic.
          • kazinator 2y ago
      • wbl 2y ago
        Some jokes are serious some serious statements are jokes. Perlis's epigrams are one example.
        • quchen 2y ago
          Inhad to look up what Perlins' (!) Epigrams are. Worth a read! https://iiif.library.cmu.edu/file/Simon_box00075_fld05959_bdl0003_doc0002/Simon_box00075_fld05959_bdl0003_doc0002.pdf https://iiif.library.cmu.edu/file/Simon_box00075_fld05959_bd...
  • glonq 2y ago
    Yeah, this hits hard. Despite being proficient in a bunch of languages in college, I could just never wrap my poor brain around Lisp.
  • bee_rider 2y ago
    That’s sort of different, right? Rust is just another systems language. Lisp is the language that nobody knows but everybody secretly believes is better than their language of choice.
  • gwern 2y ago
    He mentions Common Lisp as something he did a game in, and you can see the link he praises https://www.youtube.com/watch?v=72y2EC5fkcE https://www.youtube.com/watch?v=72y2EC5fkcE as basically a very well-developed Lisp image approach with timetravel debugging etc aimed at game dev. So the implicit comparison to Lisps is sort of a big undercurrent to this whole article.
    • orthecreedence 2y ago
      A lot of the stuff he mentions he wants I kept thinking "Oh, you want common lisp!" I dabbled in some game dev in CL and loved it. I think the ideal would be low level engine, lisp on top driving it. If you could do it without the FFI barrier slowing things down a crazy amount, it would be the killer combo.
• msla 2y ago
  >> The problem you're having is only a problem because you haven't tried hard enough. And it actually does work that way with Haskell, in my experience. There's a big hill to get over where you flail against the type system, IO monad and all, and then you realize that, while Haskell's type system isn't perfect, being able to say Num t => (t -> b) -> [t] -> [b] is really pretty powerful, and being able to search for functions by type signature is just plain convenient. But Haskell isn't for every problem in the way Rust is apparently made out to be. For example, I've seen some posts about developing games in Haskell, but it isn't common, and nobody would try to push a game developer into using Haskell.
  • 8f2ab37a-ed6c 2y ago
    Maybe https://dev.epicgames.com/documentation/en-us/uefn/verse-language-reference https://dev.epicgames.com/documentation/en-us/uefn/verse-lan... is as close as we're going to get to game dev Haskell.
    • yakshaving_jgt 2y ago
      FWIW, I believe Else Heart.Break()[0] was written entirely in Haskell. [0]: https://en.wikipedia.org/wiki/Else_Heart.Break https://en.wikipedia.org/wiki/Else_Heart.Break()
      • deleted 2y ago
        [deleted]
      • febeling 2y ago
        The link works, but the link parser on HN (of all places) is confused by the parens.
      • simonmic 2y ago
        Off topic, but for those interested, some Haskell game [dev] links: - https://wiki.haskell.org/Applications_and_libraries/Games https://wiki.haskell.org/Applications_and_libraries/Games - https://wiki.haskell.org/Game_Development https://wiki.haskell.org/Game_Development - https://hackage.haskell.org/packages/#cat:Game https://hackage.haskell.org/packages/#cat:Game - https://hackage.haskell.org/packages/#cat:Game%20Engine https://hackage.haskell.org/packages/#cat:Game%20Engine - https://haskell-game.dev https://haskell-game.dev - https://www.reddit.com/r/haskellgamedev/ https://www.reddit.com/r/haskellgamedev/ - https://www.reddit.com/r/haskell/comments/z98ubk/defect_process_full_haskell_source_62k_loc_action/ https://www.reddit.com/r/haskell/comments/z98ubk/defect_proc... Re the original post: This was a brilliant writeup with lots of insights for Haskellers as well. Thanks!
• Aurornis 2y ago
  Parts of the Rust community are toxic indeed, but I've been around long enough to recognize the same pattern in communities of other hot programming languages or frameworks in their up-and-coming phase. There's something about the new hot language/framework/paradigm that always attracts the type of people who wrap their identity up in the hot new thing. They take any criticisms of their new favorite thing as criticisms against themselves, and respond defensively. What I see now in certain Rust communities feels a lot like what I saw in Golang communities in the early days. I had similar experiences when React was the new kid on the block, too. Some of these communities/forums are just inhabited by people who thrive on dunking on noobs all day long. The good news is that they tend to get bored and move on when the next new thing comes out. I'm already seeing this in my local Rust community as the chronically online people are moving on to Zig now. They even use one of the Rust discords to advertise their Zig meetups and proselytize about Zig at every opportunity. Eventually they'll get bored and move on. > > That being said, there is an overwhelming force in the Rust community that when anyone mentions they're having problems with Rust the language on a fundamental level, the answer is "you just don't get it yet, I promise once you get good enough things will make sense". I don't fully agree with this assessment. In my experience, Rust community members who arrive with well thought out complaints or suggestions are welcomed by the people who like working on programming language fundamentals. You can nerd snipe a lot of Rust enthusiasts by showing up with a difficult problem involving tricky parts of Rust, which will often result in some creative solutions and discussions. On the other hand, Rust communities are inundated with people trying to write Rust as if it was their old favorite language. I've spent a lot of time trying to get people to unlearn habits from other languages and try to adopt the Rust way of doing things. Some people refuse to let go of paradigms once they've used them for years, so doing things the Rust way isn't going to work for them. I've worked with enough people who spent more time fighting against Rust than trying to adopt Rust ways of doing things that I've also reached the point where I don't engage once I see the conversation going that way. Can't please everyone.
  • d0mine 2y ago
    unrelated: the word "toxic" is meaningless nowadays e.g., "dunking on noobs" is more specific.
  • 2y ago
• p0w3n3d 2y ago
  Sounds like a no-true-Scottsman fallacy
• ChubbyGlasses 2y ago
  This was my biggest problem with rust, the community is, at a surface level friendly, but the moment you try to say something against the grain you get met with some of the most insufferable people ever. I tried to mention a problem with a lint on the official forms and the replies were so condescending (from regulars at that too). And at no point did they try to understand the issue, they just assumed I was dumb/new/doing something wrong.
  • jonnycat 2y ago
    The attitude is perhaps not surprising from a community whose unofficial tagline is "Rewrite it in Rust".
• Dalewyn 2y ago
  >> The problem you're having is only a problem because you haven't tried hard enough. >You just need to read another 50,000 word fasterthanlime essay. Then you'll not have problems any more. I'm reminded of a line from Hachiman in Oregairu: "Something is only a problem when someone makes it a problem."
• decremental 2y ago
  [dead]
• cornholio 2y ago
  Rust is a language with a very high mental cost to use effectively. It requires some fundamental paradigm shifts in the way you write software, hence it's a hard language to be productive in. For some tasks, the tradeoff is worth it. Some individuals are naturally very inclined to use it. But for most people, for most tasks, it's simply not the right tool. It's not a general purpose language by any stretch of the imagination.
  • emporas 2y ago
    If there were only two programming languages in the whole world, just two, no more; one better fitted for OS kernels and one better fitted for game programming, which one would be considered a general purpose language? I would argue, OS programming is definitely more general than game programming. Rust is great for OS related tasks, math, deep learning n other stuff, and maybe not so great at GUIs, or even bad at that, or just inconvenient as the article points out. That means, it should be used for general stuff, and for programming games should be used a niche language, like Lua, Python etc. Especially for fast iteration and experimentation, break things and move lightning fast, typed languages are in disadvantage for sure, compared to untyped/weakly typed.
    • cornholio 2y ago
      I would argue that OS kernel programming is actually a very specialized niche of software engineering; it demands near iron performance, fine control down bit level granularity, perfectly deterministic memory manipulation, flawless security and maintainability, and all at the same time. These are conflicting requirements and meeting them naturally spills over into decreased productivity, which is acceptable because OSes are well engineered and evolve over decades. If C or Rust would not be available, you could still write your kernel in a well documented assembly dialect - some people still do - and then complete your OS userland in some garbage collected/interpreted/WASM abomination. But it's unlikely you could write Microsoft Word or a modern browser in assembly. And this I think is true for games too, since, other than the performance requirement, they don't need the other features of Rust and are quite tolerant of failure. They also tend to be unwieldy beasts hard to design cleanly because the internal world simulation would become ever more complex, imposing weird data access patterns etc. If your online play code suddenly requires access to some internal "tank fuel" state, in C you would just pass the pointer and pray to the goods of rock and roll it's still valid at access time; a garbage collected language would at least give you that; but in Rust, you are looking at a complete refactoring of the entire "tank" module to make the new access pattern fit the ownership model. As the post explains, this will kill quick iteration, which I think is a very general need of most programmers.
• deleted 2y ago
  [deleted]