17 ms·

4x Smaller, 50x Faster

• lxe 5y ago
  The immutable hype is finally fading. People starting to realize the drawbacks of treating hardware as an infinite resource.
  • azakai 5y ago
    This article doesn't really support that. ClosureScript targets JavaScript, which is a platform that doesn't have special support for optimizing immutability.
    • notacoward 5y ago
      How would one optimize for immutability in this case, other than turning it back into mutability behind the scenes? I've certainly seem some code written in an "immutable" style where it was pretty clear that the intent was for one data structure to be a mutation of another, just called something else because the language required it. That case might be easy to optimize ... but the general case?
      • azakai 5y ago
        I'm not an expert on this, but one example is that immutability lets you operate safely on things in parallel. But JS VMs are not aware of objects that are immutable in Clojure's semantics, and in any case, do not operate on objects in parallel anyhow.
      • memco 5y ago
        > How would one optimize for immutability in this case, other than turning it back into mutability behind the scenes? Roc-lang, which is a functional, systems language in development uses something called opportunistic in-place mutation to do just that. Here's a video where the creator talks about it: https://youtu.be/vzfy4EKwG_Y?t=1276 https://youtu.be/vzfy4EKwG_Y?t=1276
      • kevin_thibedeau 5y ago
        Pretty bog standard behavior for a compiler backend translating immutables in IR. Including a runtime compiler into app code is the next stage in the evolution of cycle burning leetness.
      • fulafel 5y ago
        Generally in compiler technology, immutability is an important tool in letting compilers reason about and make program transformations. See eg the "single static assignment" intermediate-representation form that is mainstream in low level language compilers. But SSA form isn't as good as having the original program expressed immutably, because you get false or incidental data dependencies if the compiler has to conservatively derive the optimization-friendly SSA representation out of the original non-immutable code. In practice a JS implementation that had special optimizations for code using immutability as a convention might for example auto-parallelize code. Also it by no means a bad thing if a compiler turns a piece of easy to reason about functional code "back" to generated code that exploits local mutability behind the scenes in some circumstances, that's exactly how we want it to work. We still get the robustness guarantees of semantics where our objects don't change from under us in programmer visible ways.
        • gpderetta 5y ago
          Talking about parallelization opportunities is a bit pointless when you need 50 cores to match the performance of the single threaded code (in the best case, assuming perfect scaling).
          • azakai 5y ago
            Fair enough, but parallelism isn't just about cores since SIMD can also help. Also, immutability doesn't just help through parallelism, it also allows other things (as another example, avoiding redundant work like loads of an immutable field and computations on them). Would that help with a huge 50x difference? Maybe not, but the point is that evaluating the benefits of immutability on a VM that does not optimize it - JS VMs - is not relevant. (And that 50x might also be caused by other limitations of JS VMs and not immutability at all, like say deopts.)
          • fulafel 5y ago
            I disagree - lots of compiler work is done on languages that aren't best in class for high performance work. Look at all the effort that people are putting into making Python faster. And indeed JS itself, it wasn't always this fast. High level language users live by "There's more to life than increasing its speed" and then if they take off, people come work on performance and make them faster. Also let's not forget that this was already "fast enough" for a long time before the 50x rewrite.
  • rektide 5y ago
    mutability is a data structuring virtualization but i'd just as much suspect the runtime virtualization. that the bundle used to be 570kB isnt an immutability issue. itcs that clojurescript drags in a whole clojure runtime, a new virtualization layer atop the js runtime. that, to me, is the most likely suspect. that said, for sure, short tbeow away high gc allocation patterns are generally not good. at work there's a lot of "functional" patterns, nary a for loop in sight. this endless .map() .filter() usage causes near exactly similar issues, with shortived objects. it seems ultra sad & silly to me. waste after waste. but i also think we have much more deeply rooted problems.
    • jdlshore 5y ago
      Are you sure about the short-lived allocations being a problem for the collector? My understanding of modern generational garbage collectors was that they performed quite well with short-lived garbage. Not as well as not creating the garbage in the first place, of course, but not so badly as to be a problem in most cases.
      • ncmncm 5y ago
        "Perform quite well" is always relative to some reference. The oldest trick in the book is comparing to something even slower and saying "see? fast!". GC apologists seek to normalize this behavior. They often succeed, at that. Performing quite well against actually fast things, less often.
        • jdlshore 5y ago
          You seem to have an axe to grind. Performance isn’t black and white. Optimizing your memory usage isn’t going to do you a whit of good if you’re constrained by your database queries. Optimizing your DB queries isn’t going to do you any good if you’re constrained by a chatty microservice architecture. Optimizing your UI response time isn’t going to do you any good if you’re already below the threshold of perceived speed. Etc. GC performance on short-lived objects is quite good in enough situations to matter, such that optimizing for it, rather than your application architecture, is likely foolish outside of performance sensitive loops. Time is always limited. Spending your optimization budget on micro-optimizations is short-sighted.
  • deleted 5y ago
    [deleted]
  • notacoward 5y ago
    This part... > for the high frame-rate, heavy animations this puts a lot of pressure on CPU and memory ...does seem to suggest that the "garbage multiplier" effect of immutability is an ill fit for applications that also create a lot of garbage naturally. Note that this is about as close to an apples-to-apples comparison as we're likely to get - the same application implemented two different ways - so it's not the application's innate object-lifetime characteristics that are the problem. That's an implementation artifact. The question is: how many applications are likely to hit this same limit? Is this a rare case, or is it common? If it's common, it is indeed an indictment of the "immutable" approach. Otherwise, not so much.
    • xyzzy123 5y ago
      I've always thought of immutability as great for situations where you want to "explore" (clone complex current state and go do some "what if"), need internal transactions, or allow time travel (snapshot/undo/redo) - situations where the state sharing is both efficient and feels "natural". Also if the data/history are relatively small compared to the available memory it's a fine default that generally leads to "nicer" code. Video doesn't seem at first glance like such a great fit.
      • kccqzy 5y ago
        Video can be played backwards and forwards, can be sought, or jumped to a particular point in time. It fits well with the "time travel" benefit of immutable data structure. The author mentioned it was extremely easy to implement some kind of a checkpoint or key framing with immutability. That's exactly using immutability to its strength.
        • titzer 5y ago
          The downside of immutability is the sheer volume of data (in the form of pixels) that needs to be pushed around. A single 4k frame is 8.3 million pixels, so you are looking at over 30MiB of data for 32-bit color, and you gotta push 30, maybe 60 of those a second. Maybe if you have a really good garbage collector (or a custom one, because frames are all the same size) you can get away with allocating that much data and freeing it every second. But that doesn't free you from the fact that you are not utilizing hardware caches well; you don't get good spatial locality at the hardware level unless you reuse the same physical pages of memory for every frame. And you can basically only do that if you have a mutable design.
  • slmjkdbtl 5y ago
    I fantasize about a future where we have enough CPU and memory that we can waste them on nice stuff like immutable data structures and software rendering.
    • josephg 5y ago
      I fantasize about a future in which buying a faster computer means my software runs faster. I don’t spend thousands on computer hardware so that lazy devs can get lazier.
      • slmjkdbtl 5y ago
        I wouldn't characterize hoping to use immutable data structures and software rendering as trying to be lazy
        • ncmncm 5y ago
          Yet, we may characterize lazy programmers as hoping to use immutable data structures and pay no attention to performance. We all know that performance takes extra work to ensure, then, and is uncertain even with the extra work.
        • drenvuk 5y ago
          I would. Instead of properly managing mutable state (which can be difficult in situations with growing teams and complex application logic) people are opting to just copy everything or copy a subset of the tree they need so they don't have to think about it. Immutability is bad for performance when the purpose is not recalculating a certain state after a certain number of operations(memoization). Many of the best practices that have cropped up in the past few years has been more for helping teams of people deal with growing code bases rather than helping programmers deal with limited hardware. In computer science this should be self explanatory. For optimal runtimes the act of making copies is avoided. Why people usually seem to ignore the fact that they're wasting cycles for the sake of the holy grail of clean, functional programming and immutability has eluded me. Typescript, focus on immutability, microservices even. I hate all of them but they have their purposes. They solve people problems. Maximizing hardware performance is not in the list though.
  • bachmeier 5y ago
    This is an application where the goal is to squeeze every last drop of performance possible out of the processor. The "every last drop of performance" crowd has never been the source of the "immutability hype". Your comment is dismissive of many domains of programming - immutable didn't become a thing because others weren't as enlightened as you.
    • deleted 5y ago
      [deleted]
    • jcelerier 5y ago
      > This is an application where the goal is to squeeze every last drop of performance possible out of the processor. I have a hard time thinking of an application for which this isn't the case. If my cooking recipe app / website is too slow and/or eats too much battery (and god fucking knows they are) I'll look for a competitor immediately.
      • detaro 5y ago
        not being too slow and "squeeze every last drop of performance possible" is not really the same, and the latter is an expensive tradeoff to make.
  • bsg75 5y ago
    What is the connection between mutability and excessive hardware usage?
    • cjcampbell 5y ago
      As an oversimplified example, in using an immutable screen buffer, a change between frames results in allocation of a full buffer rather than overwriting memory within the buffer (though one could probably think of ways to optimize this for the use case). Excess comes either in the form of unnecessary (relative to mutable) memory usage and/or CPU cycles necessary to support high-levels of garbage collection.
      • peoplefromibiza 5y ago
        that's only because js is "stupid" if you have the string "hello" and somewhere else "hello world" you can retain only one copy of "hello" because it's guaranteed it won't change. but js vm it's not smart enough for that.
        • __s 5y ago
          You're wrong, JS has immutable strings & so VMs use ropes to make mutable usage & slicing fast https://gist.github.com/mraleph/3397008 https://gist.github.com/mraleph/3397008 https://twitter.com/rauschma/status/1269964154275799041 https://twitter.com/rauschma/status/1269964154275799041
          • peoplefromibiza 5y ago
            thanks my bad, I learned something new. anyway this proves that immutable data structures are not inherently slow, this is infact an optimization that makes things faster.
      • knubie 5y ago
        > in using an immutable screen buffer, a change between frames results in allocation of a full buffer rather than overwriting memory within the buffer That’s actually not how clojure’s immutable data structures work. They use structural sharing, so only the portion that changes (roughly) needs new memory allocated, and only the parts that changed get garbage collected, so it is a bit more efficient than that.
  • rtpg 5y ago
    What a boring takeaway from this. Beyond the fact that the immutable data structures proposed by Clojure/script tend to perform very well in a lot of "normal" cases (and in a lot of normal web-app workflows your stuff is immutable, like "query then display the result from an API"), at least to me it feels like asciinema is a very good example of a case where you have tougher-than-average performance requirements. Not to say that we shouldn't have "everything be performant" but drawing a bunch of stuff to screens is _the classic_ performance question. Whereas most "business apps" people here work on to a day-to-day have different performance issues. Rewriting your CRUD frontend in Rust isn't going to make your DB queries faster
    • hedora 5y ago
      > Rewriting your CRUD frontend in Rust isn't going to make your DB queries faster A typical consumer disk can do 1,000,000 IOPS (enterprise is one generation behind, and slower at the moment), with millisecond read and write latencies. Are there any managed CRUD frontend languages that are fast enough to keep up with that? (By “keep up”, I mean “be less than half the hardware I provision at scale”)
    • ncmncm 5y ago
      Won't make them slower, anyway. There are often performance bottlenecks you didn't know about, and had blamed on database (or whatever) interaction overhead. It will never feel worthwhile to dig into each candidate, because any payback seems too unlikely. Not having left scope for such bottlenecks means you can be confident they are not there. Re-implementing once is a lot less work than diving into each possible bottleneck. Improving your actual database operations, after, is more likely to have an effect when some other bottleneck doesn't mask the improvement. You don't have to do it in Rust. Any optimization you could do in Rust is probably easier in C++, and also easier to find maintainers for.
      • Ar-Curunir 5y ago
        > Any optimization you could do in Rust is probably easier in C++, and also easier to find maintainers for. At least the first part is not necessarily true. E.g., in C++, you might make defensive copies, whereas in Rust the lifetime system will track things for you.
  • niels_bom 5y ago
    This talk by Richard Feldman about Roc (a new language) goed into why immutable does not necessarily mean slow and given enough attention can mean higher performance in certain cases: https://youtu.be/vzfy4EKwG_Y https://youtu.be/vzfy4EKwG_Y
  • peoplefromibiza 5y ago
    or maybe is JavaScript hype and the make concurrent programming impossible that it's finally dying. Immutability is alive and well, it's simply a matter of js runtime not supporting it, because the developers thought "one thread ought be enough for anybody".
  • mping 5y ago
    Well the immutability hype allowed the author to build the previous incantions of the library. At this point, I hoped everyone understood the tradeoffs of using abstractions. Otherwise we should all be programming on assembly.
    • zupa-hu 5y ago
      This. If the project was reimplemented in assembly, it would be faster and smaller and the same conclusion could be drawn: “finally the high level programming hype is over”. come on..
  • legulere 5y ago
    The benefits of immutability are still there though. You should generally design immutable by default and use mutability for performance where it matters. Rust which was used here also has immutability by default and mutability is an explicit opt-in.
• atoav 5y ago
  While I applaude the engineering effort that went into the project, I really dislike documentation that uses asciinema for regular non-interactive CLI interfaces: instead of showing me the commands in an overview I have to sit through the whole thing.
  • qwertox 5y ago
    It's a lean-back experience, like the difference between a book and a video. It does have its perks.
    • vladvasiliu 5y ago
      I think it can work well as a demo, but I wouldn't call that documentation. If you need to find something out, having to wait or randomly click through a video is extremely frustrating.
      • vidarh 5y ago
        If it's a video, it does noe exist for me. I could watch them, but I have better things to watch if I want to watch something. So I move on to something else.
        • EdwardDiego 5y ago
          Most of us read far faster than someone umming and ahing through a presentation in a monotone can speak. At the very least, give us a frigging transcript.
          • vidarh 5y ago
            A transcript would be great, but it struck me in these days of deep learning it's just a question of time before someone does a "speedup" option for videos that instead of just increasing the speed of the video, combines that with "smart" cuts like removing umming and ahing and unnecessary dead space, and tries to apply other simplifications as well (I'd still prefer text, but I'm sure there'd be an upside for people who like video). And imagine even a more aggressive "video summarizer" generating articles from videos with interspersed screenshots or brief video segments where they matter for the understanding...
• eatonphil 5y ago
  Historically asciinema was not easy to embed in React because you can't have multiple copies of React. So my team at the time wrote and open-sourced an embeddable alternative to it. Unfortunately that project seems to have disappeared by now. But now that asciinema is no longer in React maybe it will be possible to embed now. See https://github.com/asciinema/asciinema-player/issues/72#issuecomment-955669533 https://github.com/asciinema/asciinema-player/issues/72#issu....
  • kazinator 5y ago
    Historically, you could embed an animated .gif into a web page going back before Y2K, and there are tools to make such a thing from recording terminal sessions. No Javascript, no third party websites.
    • codetrotter 5y ago
      You can’t pause and rewind or skip ahead in a gif in any of the major browsers.
      • kevin_thibedeau 5y ago
        Or copy/paste text.
        • hedora 5y ago
          FWIW, iOS 15 automatically OCR’s screenshots, so now copy paste works again (even from non-selectable text in apps). However, most times I have problems with copy paste, it’s not due to gif’s. It’s due to some BS framework thing rendering text in some non-standard way.
        • unrealhoang 5y ago
          Or render it beautifully for every future screen resolution.
        • kazinator 5y ago
• ryansolid 5y ago
  It's awesome to see performance-oriented projects to find their way to SolidJS(https://www.solidjs.com https://www.solidjs.com). So satisfying to see success stories like this one. Great work.
  • eatonphil 5y ago
    Congrats! One nit I have about SolidJS documentation is that it doesn't have a clear path for "migrating from React" which I take it is probably actually important to you given how similar SolidJS looks to React and how much faster it claims to be. Also might be good to include a section on how to interop with existing React libraries -- even if the answer is that you can't. And it might be worth putting in your HN profile that you are the creator of SolidJS. :)
    • ryansolid 5y ago
      Yeah it is sort of buried and probably not very clear: https://www.solidjs.com/guide#react https://www.solidjs.com/guide#react. And good point thank you about updating my profile.
  • ano88888 5y ago
    congrats on the performance. But I just hope that React will quickly catch up and improve in terms of speed & performance. It is really tough to learn a new framework every few months.
    • austincheney 5y ago
      Not going to happen. The key difference: virtual DOM.
    • ryansolid 5y ago
      It's unlikely. Solid has had this performance profile since 2017. React hasn't really budged. Fundamentally different approach. There are different types of performance to explore but raw performance for small things is not something React is going to "catch up" on. Might be worth a read: https://javascript.plainenglish.io/javascript-frameworks-performance-comparison-2020-cd881ac21fce https://javascript.plainenglish.io/javascript-frameworks-per...
• cunthorpe 5y ago
  Maybe it’s just me, but I don’t think showing a string on screen requires React or any other view library. I’d probably paint it on canvas and then overlay an invisible plaintext node to allow selection.
  • eatonphil 5y ago
    If you made a library that does this I'm sure it would be welcome competition!
  • winstonewert 5y ago
    But that just means you have to manage both the text (what React/SolidJS are already doing) and a canvas, which means your twice the work for no good reason.
  • Cthulhu_ 5y ago
    Yeah but how can you quickly re-render the plaintext node in sync with the canvas? How are you doing font rendering? How are you handling things like accessibility and interactive controls? I feel like you may not be seeing the whole picture / problem domain.
  • sickill 5y ago
    The player has other UI parts, mainly the control bar with current time, progress/seek bar, full-screen toggle etc. Of course it could be built with plain JS but a small library like Solid.js does the job well. The terminal lines with (colored) text definitely don't need a view library if you just want to display it, true. Canvas would be way more efficient here, and it's not out of the question for the terminal part in the future. One thing that using DOM (spans here) gives for free is copy-paste. Like you mentioned it could be solved by overlaying a text element on top of canvas (on mousedown, or when paused) or custom implementing copy-paste for canvas with mousedown/mousemove/mouseup, but that's all extra work, and as I mentioned in the blog terminal emulation was the bottleneck, not rendering.
  • stjohnswarts 5y ago
    People work with what they know and I'm sure they'd love to see a similar implementation done with the method you suggest. It's open source and hugs and thumbs up all around here :)
• qwertygnu 5y ago
  Went to https://asciinema.org/ https://asciinema.org/ and clicked the demo video. I'm a bit confused because it looks like future lines are being rendered after the cursor while lines are being typed. Is that...correct? It looks like either a blatant bug in their product (that they're displaying on their homescreen demo!) or on purpose for some reason I can't find.
  • nawgz 5y ago
    You made me click through, and I could not recreate. Is this the new viral marketing? I truly just was reverse psychology'd
    • qwertygnu 5y ago
      not a plant I swear!
  • sickill 5y ago
    Feel free to report a bug here https://github.com/asciinema/asciinema-player/issues/new https://github.com/asciinema/asciinema-player/issues/new (including browser version, OS would help a lot). Btw, it's not a product, just a side, hobby project of mine.
    • qwertygnu 5y ago
      Ohhh weird, I thought it was a literal mp4 on the front page haha. Must be one of my browser extensions messing with it!
      • nawgz 5y ago
        Ohhh this makes a lot of sense to me now too, I also thought it was an mp4 until reading your comment and thought you were totally insane to have "watched the video" wrong lol. I see now it's an animated terminal rendering via HTML elements, very cool
• corn13read2 5y ago
  That's what she said
• ajaxexact 5y ago
  > ClojureScript is not that easy to integrate with the JS ecosystem. I know, there’s been a lot of improvements done in this space over the years, and I’m sure someone will immediately point me to relevant docs, but it’s still the extra mile you need to go when compared to regular JS codebase This always kills me. Clojure(script) is one of the neatest languages I've ever used, but it is just such a pain to work with. I spent hours getting NPM imports working in a project, when it ought to take seconds. It really makes it hard to recommend, even though the language itself is amazing.
  • jaxn 5y ago
    I have also spent hours getting npm packages to work in JS before.
  • Cthulhu_ 5y ago
    I just wonder why not just write straight JS? Adding a layer on top just means you have more complexities and steps to worry about. And clearly, in this case it was a big compromise in terms of performance and bundle size.
    • keymone 5y ago
      You'd have to torture me before I would make a conscious choice to pick JS over Clojure.
      • michaelcampbell 5y ago
        It sounds like that's exactly what happened to the GP.
        • keymone 5y ago
          GP didn’t pick JS for a rewrite either, so yes, I’m pretty sure GP is with me on that.
          • 5y ago
• w-m 5y ago
  The blog post mentions that seeking to any point works very well without having to create keyframes, just from the speed of the implementation. It would be great if the progress bar could actually respond to click-and-drag events, to quickly find a specific location.
  • Tobu 5y ago
    Scrubbing would be fun, I agree!
• MrYellowP 5y ago
  Reading through the comments and as an assembly programmer, I think this whole topic is completely bonkers.
  • deleted 5y ago
    [deleted]
  • genuine_smiles 5y ago
    Why?
• fnordsensei 5y ago
  As an enthusiastic Clojure/Script user, the new tech stack absolutely makes sense for this application. For the decrease in size, I expect most of the gain to come from dropping ClojureScript. For the speed increase, though, I expect most of the gain to come from WASM. JS and ClojureScript are within the same margin of error compared to the performance that can be achieved with WASM.
  • badestrand 5y ago
    > Due to ClojureScript’s immutable data structures, there’s a lot of objects created and garbage collected all the time ^ From the article, sounds like a plausible cause for the speed difference.
    • fnordsensei 5y ago
      It's almost certainly part of it. I doubt that a ClojureScript application written mutably (which you can do) would compare favorably to WASM regardless.
      • sickill 5y ago
        Before attempting JS/Rust rewrite I tried using transients [0]. I converted small part of the vt code to use mutable data structures to see if it's giving any improvements. It barely did, the difference was negligible. I believe it was because I didn't go all the way, so the perf critical pieces deep down were still using immutable data structures. Maybe it would bring decent improvement if I converted most of the vt code to transients, but it would absolutely destroy the idiomatic aspect of the code, and even then it would never compete with Rust anyway. [0] https://clojure.org/reference/transients https://clojure.org/reference/transients
        • fnordsensei 5y ago
          I get that. And then you'd have to find a way to get rid of React (and Reagent/whatever was used on top of it) to get it all the way to as lean as possible. At this point, you'd be leveraging almost nothing that ClojureScript brings to the table, while getting most of the cons.
• agys 5y ago
  For my own realtime browser based ASCII projects I update the DOM “manually”: the biggest bottleneck is frequent -horizontal- changes in color as each character with a new color needs to be wrapped in its own <span> element. After all you can’t avoid a DOM repaint. After several benchmarks I realized that the fastest way to update the entire window is to compose a string and assign it to each line/line-element via innerHTML. I usually get 60fps with 5-8k chars in fullscreen (browser text rendering has become really fast).
  • stjohnswarts 5y ago
    Maybe you could benchmark it against this. It would make an interest HN followup post.
    • sickill 5y ago
      It's not the rendering / DOM part that got 50x faster though, so that would be apples to oranges.
• iveqy 5y ago
  This makes me worry less about the end of Mores law. It's clear that software development still has a long way to go.
• unnouinceput 5y ago
  I get it, Clojure bad, Rust good. Yeah, absolutely nothing to do with the brain in the chair.
  • fnordsensei 5y ago
    More like, know when to apply Clojure and when to apply Rust. Having written a ClojureScript app with a Rust/WASM component, for me it's very clear that they have different strengths that can be complementary. That the author dropped CLJS along with React is fair enough, in my opinion. The CLJS ecosystem is pretty React-centric.
    • unnouinceput 5y ago
      Listen, Clojure isn't born yesterday, it's around for quite some time and it's a mature product. And when you have mature products that are still in development and people behind it do evolve it then you also get all kind of optimizations. I would expect the system maybe to be slower like 20 to maximum 50% (as in Rust to be maximum 2 times faster) but 50 times faster?. That's already brain in the chair mistake.
      • fnordsensei 5y ago
        If we were talking about Clojure, I would agree that 50x would indicate that something is off. But since we're talking ClojureSCRIPT, it doesn't surprise me. Although, fair enough, it's a rewrite, and the author has the benefit of experience with the first implementation when writing this one. A second implementation in ClojureScript would likely have been faster than the first one. But 50x faster? Unlikely. > Is WebAssembly faster than Javascript? > Yes - about 50 times faster in my experience. https://www.quora.com/Is-WebAssembly-faster-than-Javascript https://www.quora.com/Is-WebAssembly-faster-than-Javascript Just as a data point that the author isn't the only one to see this type of performance increase. I expect that it isn't 50x across the board over JS, but that it would vary wildly across the board, including being slower if you're doing something trivial and end up paying more in serialisation to and from WASM than you gain in speed.
• RMPR 5y ago
  Reposting here since the first submission didn't make it to the frontpage I started using asciinema two months ago and I must say that it's excellent! One minor annoyance though, it forces the use of the default shell instead of using the shell you launched it in. Other than that I am very excited by this release, more speed is always welcome.
  • sickill 5y ago
    It does try to launch the same shell as your current one by looking at SHELL env variable, and only falls back to sh if it's not there. See: https://github.com/asciinema/asciinema/blob/9ccf4efd4d3babc4065be767b375727c7d739d3f/asciinema/recorder.py#L14-L15 https://github.com/asciinema/asciinema/blob/9ccf4efd4d3babc4... It seems that's not the most reliable method.
• moonchrome 5y ago
  It's funny how it starts out with "immutability is really fast and GCs are soo good" and ends up with "rewriting everything in unmanaged code made it 50x faster". Similar how "Ruby and Python interpreters are slow but webapps are IO bound anyway so it doesn't matter" to "how can I get this to handle more than x req/sec, can we get a JIT to speed up our dog slow backend".
  • smrtinsert 5y ago
    It's almost like one side had the ability to say "we told you so" and they never bothered to :)
  • aasasd 5y ago
    > "Ruby and Python interpreters are slow but webapps are IO bound anyway so it doesn't matter" to "how can I get this to handle more than x req/sec, can we get a JIT to speed up our dog slow backend" Turns out that if you write business logic with abandon, you end up with a lot of business logic. Personally I wish that Python, Ruby and the ilk all get replaced with Lua, but also that Lua gets a proper `null`.
    • seniorivn 5y ago
      and array numbering from zero
      • mmastrac 5y ago
        This is why I've never been able to do anything serious with Lua. Small thing, but fatal for me.
      • LAC-Tech 5y ago
        No idea why this bothers people so much. How often are you manually indexing into an array with numeric literals?
  • gwern 5y ago
    One of the arguments high-level language proponents always made was that you could do exploratory programming and prototyping and develop your systems in nice easy high-level languages, and then FFI out or reimplement parts in the painfully low-level languages when you discover you need their performance. asciinema prototyped and worked out their design, and discovered it needed more performance. And then it got it. Sounds like a success story to me.
• 71a54xd 5y ago
  Asciinema server is still quite frankly my favorite Elixir Phoenix project of all time. https://github.com/asciinema/asciinema-server https://github.com/asciinema/asciinema-server
  • sickill 5y ago
    Oh wow, thank you! Frankly I'm the least proud of it, as it's been my first Elixir/Phoenix project and there's many things I'd have written differently today, especially after spending last 4 years writing Elixir at work. But time will hopefuly come to bring more love to it too :)