bakery2k

Are similar mitigations also needed in the VMs for other dynamic languages, such as CPython/PyPy, Ruby MRI and Lua/LuaJIT? What about the JVM and Microsoft's CLR?

Or are these other VMs not susceptible to this form of attack?

[1] https://www.chromium.org/Home/chromium-security/ssca

[2] https://blog.mozilla.org/security/2018/01/03/mitigations-lan...

[3] https://blogs.windows.com/msedgedev/2018/01/03/speculative-e...

[1] https://bugs.ruby-lang.org/issues/5583#note-7

I think that consistently using "!" to mean "mutates in-place" would be a good convention for a language to use, but that's not what Ruby does. From Matz himself [1]:

The bang (!) does not mean "destructive" nor lack of it mean non destructive either. The bang sign means "the bang version is more dangerous than its non bang counterpart; handle with care". Since Ruby has a lot of "destructive" methods, if bang signs follow your opinion, every Ruby program would be full of bangs, thus ugly.

[1] https://www.ruby-forum.com/topic/176830#773946

Roberto Ierusalimschy, the creator of Lua, believes that "Local by default is wrong." [1].

I don't necessarily agree that local-by-default is inherently wrong, but every implementation of local-by-default that I've seen has had flaws.

It looks like MoonScript is no different - its scoping rules seem to suffer from the same "madness" as CoffeeScript [2].

[1] http://lua-users.org/wiki/LocalByDefault

[2] https://donatstudios.com/CoffeeScript-Madness

Part 3: https://www.synopsys.com/blogs/software-security/swift-progr...

-5 to 256 (inclusive) [https://github.com/python/cpython/blob/master/Objects/longob...]

-5 to 256 (inclusive) [https://github.com/python/cpython/blob/master/Objects/longob...]

Compare this with PUC Lua [2], which seems to have very few bugs: only 4 in 5.3.3 and 3 in 5.3.2.

LuaJIT and PUC Lua appear to be very similar superficially ("LuaJIT is Lua, but fast"). The relative bug counts reinforce the fact that in the details, the two implementations are very different - for example, LuaJIT uses a lot of assembly language while PUC Lua is pure C89.

The advantages of LuaJIT over PUC Lua seem to be performance and its FFI. I thought PUC Lua's only advantage was portability, but perhaps PUC Lua is also a generally more "correct" implementation?

[1] http://luajit.org/changes.html

[2] https://www.lua.org/bugs.html

YARV? No.

YARV is the current official Ruby interpreter - it replaced MRI in this role from Ruby 1.9 onwards.

Not the original MRI, but YARV. For this particular program, the performance of different language interpreters is:

MRI (Ruby 1.8) < CPython 3.5 < CPython 2.7, PUC Lua 5.1/5.3 < YARV (Ruby 1.9/2.3) < LuaJIT -joff

There is a factor of ~5x between the slowest and fastest of these interpreters. LuaJIT with the JIT enabled is ~10x faster than even its own interpreter.

That's good to hear. Perhaps LuaJIT isn't "unsupported", but it does seem to be "in maintenance mode".

I would love to see, not just bug fixes to LuaJIT, but ongoing improvements. Unfortunately with Mike having stepped down, and there being no successor, nobody is making these improvements and nobody is driving the project forward.

For example, will the new garbage collector [1] ever be implemented? Will LuaJIT remain stuck at version 5.1 while PUC Lua continues to add new features?

[1]: http://wiki.luajit.org/New-Garbage-Collector

LuaJIT is at least 10x faster than all three.

Recently, however, I came across https://www.reddit.com/r/Julia/comments/4c09m1/, which suggests running with `--precompiled=yes` to reduce startup time. I have now run the Julia version with that command-line option, and the runtime is impressive - comparable to C#/Go/V8.

* CPython, Jython, Lua, MicroPython, Ruby (1.8): >100 seconds

* Cython (naive), IronPython, Ruby (2.3): 50 - 80 seconds

* LuaJIT, PyPy, Cython (with type hints): ~4 seconds

* C#, Go, JavaScript (V8): ~1.5 seconds

https://github.com/python/typing/issues/258

However, I would like to build the application into a standalone binary for end-users to run on their own systems. This seems to be difficult with Python, and when I was able to build such a binary (using PyInstaller on Windows) it was large and slow to start-up.

(Qt itself is ~10MB (QtCore4.dll + QtGui4.dll) and (when using C++) can be made smaller by static linking, but PyQt doubles the size (python27.dll + PyQt4.QtCore.pyd + PyQt4.QtGui.pyd).)

http://www.slideshare.net/jpetazzo/docker-and-go-why-did-we-...

So, thank you for listing some less-popular languages as well. Unfortunately, of all 8 languages listed in your post, is C++ the only one which can produce standalone binaries and thus match the easy deployment of Go?

It's a shame Go's flag package is so poor. Even Docker, who seem to be hugely invested in Go, say "seriously just don't use it". [1]

[1] http://www.slideshare.net/jpetazzo/docker-and-go-why-did-we-...

The Python runtime is relatively poor (slow and limited by the GIL) but the language is extremely popular [1].

Is there any other language which is a "best of both"?

[1] https://news.ycombinator.com/item?id=3746692

1. A typo on the LHS of an assignment will create a new variable rather than being flagged as an error.

2. There is no way to create variables which are local to the current block, for example, the body of a loop.

"The problem is that without local declarations, you cannot say where the variable is local to" [2]. Take Python, for example, where "local by default" means "local to the current function". Variables are created in the current function's scope on assignment, which causes 2 problems:

1. It is awkward to modify variables in outer scopes, because an attempt to assign to them creates a new variable. Python works around this with the `global` and `nonlocal` keywords.

2. Python does not support variables which are local to the current block, for example, the body of a loop.

[1] http://lua-users.org/lists/lua-l/2006-10/msg00056.html [2] http://lua-users.org/lists/lua-l/2006-10/msg00063.html

Why is this problem not shared by Lua? Does Lua somehow prevent "process_file" from modifying the equivalent of "os.path"?

    for x in os.listdir(PATH):
        y = os.path.join(PATH, x)
        process_file(y)

> LuaJIT also gets serious wins from lifting the lookups out of loops since they can't change. This is only due to the fact that Lua doesn't have threads that can muck with each other's state.

Would Lua code equivalent to the above Python have the same problem - that "process_file" could modify the value of "os.path"? Would this prevent LuaJIT from hoisting the lookup out of the loop, even in the absence of threads?

Compared to the simple thread-based server, the generator-based server presented in the second half of the talk avoids the above problem. Does the generator-based approach have any other advantages?

Do you think anyone will ever use the lessons learned about interpreters and write a "better next time" implementation of Python, or do you only see an improved runtime appearing alongside a significantly different language?