blog VS Opal

It is flawed for (otherwise) veterans too if they are trying to do something that they haven't done before so do not know what they do not know.

This really only works if you have done the same or something very very similar before and so you have practically no unknowns. Notice that the developer who did that commented above that they had already done similar work at the past.

Also related this quote about how Joe Armstrong (of Erlang fame) approached problems (from [0]):

> Joe wrote amazingly simple programs and he did so in a peculiar way. First he wrote down the program any old way just to get it out of his head. Then once it worked he would then immediately create a new directory program2 and write it again. He would repeat this process five or six times (program5, program6, ...) and each time he would understand the problem a little better and sense which parts of the program were essential enough to re-type. He thought this was the most natural thing in the world: of course you throw away the first few implementations, you didn't understand the problem when you wrote those!

[0] https://github.com/lukego/blog/issues/32

Eh, with the benefit of 14 years of hindsight, I want to push back on some of the things in that talk. (Context: I work on SpiderMonkey.)

First, all the stuff about tracing and trace trees is kind of obsolete. SpiderMonkey abandoned TraceMonkey a long time ago. (To the best of my knowledge, V8 never implemented a tracing JIT at all.) The problem with tracing is that you can get really good performance when everything goes right, but it's brittle. There's a reference in the talk to how implementations of the Game of Life can have exponential blow-up, for example. You can usually fix any individual pathological case, but the inherently exponential number of possible paths through a program make it difficult to completely eliminate weird performance cliffs.

If your goal is to maximize performance on a known set of benchmarks, go wild. If you want a robust engine that can handle whatever weird code the web is throwing at you, tracing JITs are (as far as I can tell) a dead end.

(Counterpoint: LuaJIT seems to be doing alright with tracing, although it may just solve the problem by punting to the programmer: https://github.com/lukego/blog/issues/29. That's more feasible when you don't have multiple engines with performance cliffs in subtly different places.)

Second, the idea that JIT-compiled code can be faster than AOT-compiled code has been floating around for a long time, but I don't think it really holds in the general case. Doing work at runtime isn't free: not just time spent compiling, but also time spent profiling and validating that your speculative optimizations continue to be correct.

SpiderMonkey had a top-tier optimizing compiler, IonMonkey, that got pretty darn close to native code on hot benchmark loops. We tracked whole-program information to ensure that type checks could be elided in inner loops. (For example, if the `x` property of a certain set of objects only ever contained 32-bit integers, then we could unbox it without checking the type. If any code elsewhere ever stored a non-integer value in that property, we would notice and invalidate the optimized code.)

We threw IonMonkey away, because it was too brittle. In practice, real-world code falls off the happy path often enough that we got better performance by accepting that even your highly optimized JS code will include some runtime checks. Invalidation and recompilation are real costs. So is the upkeep of all the global data necessary to support Ion. There's an engineering tradeoff between pushing up the performance ceiling and bringing up the performance floor; we've been happy with our choice to shift focus more towards the latter. Our numbers are down on artificial benchmarks, but it seems to have paid off in real-world performance. (Also, bugs in the optimizing compiler are significantly less likely to be exploitable.)

A lot of really smart people have done some incredible work on the JVM. Nevertheless, I'm still not aware of any code written in Java instead of (say) C++ or Rust because Java was faster. I think it's more accurate to say that JIT compilation can be fast enough that the other advantages of the language can make it the right choice.

It's been a long time dream for me since about 2013 when I started getting deep into Ruby and Rails, to be able to write Ruby code for the frontend instead of JavaScript. I was a lover and adopter of CoffeeScript (which had it's flaws and imperfections), but that mostly got killed by ES6. I wrote some PoCs with Opal[1] that felt pretty good to write, but the overhead was rough (this was many years ago so things might be different now) and I never really felt like I didn't have to know about or care about the underlying javascript. I tend to discard leaky abstractions as I feel they often add more complexity than they were meant to cover in the first place.

Has anybody used this or Opal or anything else? What is the state of "write your frontend in Ruby" nowadays?

[1]: https://github.com/opal/opal

Every time I see a respectable project use a Code of Conduct I remind myself that, unfortunately, Caroline Ada won[1]

[1] https://github.com/opal/opal/issues/941

But we shouldn't overstate the difference: the JS and Ruby object models are actually similar in how dynamic both of them are. This makes Ruby-to-JS compilers like Opal easier to implement, according to an Opal maintainer.

This is an interview with the author of Opal, here's the project:

https://github.com/opal/opal

Not the OP, but from what I remember they would seek out every possible opportunity in every single possible open source community they could find and propose the CoC that they wrote. 0 contributions to the projects, with the exception of demanding that people implement incredibly verbose CoC's in their projects under the guise of "protecting the minorities contributing to the projects".

Most infamous instance is probably this one, in the Opal repo: https://github.com/opal/opal/issues/941

As well as this thread in the Ruby issue tracker that devolves into pure chaos with Ada refusing to actually participate in any of the valid points others bring up: https://bugs.ruby-lang.org/issues/12004

And I'm sure there's many other instances if you look around a bit.

My experience with ruby for front end web dev is via https://opalrb.com/

Here's an example of the creator of the most adopted CoC (the Contributor Covenant) trying to get an open source contributor removed from a project due to his political opinions expressed on Twitter which she didn't like and found offensive.

So ruby has a JS transpiler - opal - https://opalrb.com/

I tried using it a little bit but the reality is if you need JS to make your app more interactable it's really worth it to just learn some JS. As soon as you need something complex the extra layer of abstraction just gets in the way and becomes more of a headache, and if you don't need anything complex then you don't need JS in the first place.

I stumbled upon this thing from years ago. I did some more digging to see what other communities thought about it. Turns out that a lot of people are really against Coraline's side.