Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Umka: A statically typed embeddable scripting language

github.com

Post reply on HN
Print view View original

11–20 of 22 posts

Re: Umka: A statically typed embeddable scripting language

#11

Post by mr_ms »

latchkey wrote: post #10
rad_gruchalski wrote: post #9

Earlier quoted context omitted.

Yes. And? It’s not like you’d embed that in a C program. Yaegi was built with a very narrow use case: golang plugins for Traefik proxy. It’s a golang library for evaluating golang code. That’s it. You can go through the hoops of calling from C into a golang program that then evals some other golang code via Yaegi but that’s probably not going to be the most efficient way of doing it and it’s far from embedded. So yea…

> Umka solves a different problem. And my point is that I don't get what problem a golang-like language that can be called from c solves exactly. Why not just write the code in c? If you aren't going to write in c, then you might as well write in golang or rust or some other higher level language that has a whole suite of tooling, supporting libraries, documentation, community and ide support. If the end benefit is j…

Tophat[1] is a game engine using umka for scripting. This means all the performance critical parts are written in c, but game scripts are made in umka for simplicity and less crashes. A lot of game engines do that (godot, löve).

Embedded programming languages can also be used for user made scripts. Either in games as a form of modding or in other software (see blender and its use of python).

[1] https://th.mrms.cz

Re: Umka: A statically typed embeddable scripting language

#12

Post by rad_gruchalski »

latchkey wrote: post #10
rad_gruchalski wrote: post #9

Earlier quoted context omitted.

Yes. And? It’s not like you’d embed that in a C program. Yaegi was built with a very narrow use case: golang plugins for Traefik proxy. It’s a golang library for evaluating golang code. That’s it. You can go through the hoops of calling from C into a golang program that then evals some other golang code via Yaegi but that’s probably not going to be the most efficient way of doing it and it’s far from embedded. So yea…

> Umka solves a different problem. And my point is that I don't get what problem a golang-like language that can be called from c solves exactly. Why not just write the code in c? If you aren't going to write in c, then you might as well write in golang or rust or some other higher level language that has a whole suite of tooling, supporting libraries, documentation, community and ide support. If the end benefit is j…

> And my point is that I don't get what problem a golang-like language that can be called from c solves exactly. Why not just write the code in c?

It says in the readme. It provides scripting capabilities using a strongly-typed go-inspired language in compiled languages. You don't write the scripting code in C because C isn't a scripting language.

> ... what's wrong with a system() call to bash?

Okay. Because you need to fork, because you need to have permissions to fork the process you want to fork, because fork is time consuming and requires resources you might not have a lot of, because maybe there is no bash. Or on one machine there is bash, on another there isn't. Because depending on what you are going to call, you may need a whole shebang of dependencies, which may or may not exist. Because maybe you compile to tinygo and you can't use Yaegi, but then maybe wasm is a better choice. There are tons of reasons why not.

> Like I said, neat research project, but if I came into a company to work on a project and this was tossed in my lap, I'd probably walk away.

It doesn't seem to solve a problem you are facing but it doesn't mean it's useless. You said multiple times that you don't understand what problem does it solve. It provides an embedded, type-safe, cross-platform, go-inspired syntax, performant scripting language. You know, Yaegi was some time ago also someone's "neat research project", albeit for a totally different use case.

Re: Umka: A statically typed embeddable scripting language

#14

Post by socialdemocrat »

latchkey wrote: post #2

This is great as a research project, but if I needed something like this to be embedded in an existing project, I'd just go with Yaegi [1] instead of going with something that is similar to golang, but not. Having all the golang ecosystem and tooling is a huge advantage as well. [1] https://github.com/traefik/yaegi

Thanks for mentioning this. This does in fact look a lot more interesting to me. As a huge fan of REPL environments, I have been looking for a way to do this in Go, so I can more easily explore and try out things.

Re: Umka: A statically typed embeddable scripting language

#15

Post by credit_guy »

The performance benchmark is extremely underwhelming.

Multiplication of 2 400x400 matrices takes about 25 seconds, compared to more than 50 seconds for Python. But in Python everybody uses numpy to multiply matrices, and at this size the runtime is less than 1 millisecond on any recent CPU.

Re: Umka: A statically typed embeddable scripting language

#16

Post by IshKebab »

credit_guy wrote: post #15

The performance benchmark is extremely underwhelming. Multiplication of 2 400x400 matrices takes about 25 seconds, compared to more than 50 seconds for Python. But in Python everybody uses numpy to multiply matrices, and at this size the runtime is less than 1 millisecond on any recent CPU.

Sure but using numpy is not really Python anymore - at that point you'd be comparing to C, not Python.

Anyway I think the benchmark is underwhelming for a different reason - Python is extremely slow so beating it surely isn't that Impressive?

I guess on the other hand... one guy has made a faster language than one made by an entire army of Python developers.

Re: Umka: A statically typed embeddable scripting language

#17

Post by agoose77 »

IshKebab wrote: post #16
credit_guy wrote: post #15

The performance benchmark is extremely underwhelming. Multiplication of 2 400x400 matrices takes about 25 seconds, compared to more than 50 seconds for Python. But in Python everybody uses numpy to multiply matrices, and at this size the runtime is less than 1 millisecond on any recent CPU.

Sure but using numpy is not really Python anymore - at that point you'd be comparing to C, not Python. Anyway I think the benchmark is underwhelming for a different reason - Python is extremely slow so beating it surely isn't that Impressive? I guess on the other hand... one guy has made a faster language than one made by an entire army of Python developers.

Eh, but Python isn't designed to be fast. In fact, you might say Python is designed to be slow (it's not, but that's a fun way to look at it) because it does so much. If you don't want to have the kind of runtime flexibility that Python has, then arguably you should have better performance to show for it - Python is planning on finding ~40% speed ups in the coming year.

That said, I don't know what the goals of this language are, and bluntly, perf isn't everything ;)

Re: Umka: A statically typed embeddable scripting language

#18

Post by vtereshkov »

mike_hock wrote: post #13

Is it easily sandboxable, i.e. can you block or virtualize any file system and other non-memory resource access?

Umka has a limited support for sandboxing, i.e., you can block the file system and disable executing native code from external libraries.

Re: Umka: A statically typed embeddable scripting language

#19

Post by vtereshkov »

IshKebab wrote: post #16
credit_guy wrote: post #15

The performance benchmark is extremely underwhelming. Multiplication of 2 400x400 matrices takes about 25 seconds, compared to more than 50 seconds for Python. But in Python everybody uses numpy to multiply matrices, and at this size the runtime is less than 1 millisecond on any recent CPU.

Sure but using numpy is not really Python anymore - at that point you'd be comparing to C, not Python. Anyway I think the benchmark is underwhelming for a different reason - Python is extremely slow so beating it surely isn't that Impressive? I guess on the other hand... one guy has made a faster language than one made by an entire army of Python developers.

Certainly, Python is slow. But I would say it's incorrect to compare Umka to C in terms of performance. Interpreted languages are always slower than compiled ones. The only way to close the gap is to use a JIT compiler, like LuaJIT for Lua. But such a compiler can never be portable.

Re: Umka: A statically typed embeddable scripting language

#20

Post by vtereshkov »

latchkey wrote: post #10
rad_gruchalski wrote: post #9

Earlier quoted context omitted.

Yes. And? It’s not like you’d embed that in a C program. Yaegi was built with a very narrow use case: golang plugins for Traefik proxy. It’s a golang library for evaluating golang code. That’s it. You can go through the hoops of calling from C into a golang program that then evals some other golang code via Yaegi but that’s probably not going to be the most efficient way of doing it and it’s far from embedded. So yea…

> Umka solves a different problem. And my point is that I don't get what problem a golang-like language that can be called from c solves exactly. Why not just write the code in c? If you aren't going to write in c, then you might as well write in golang or rust or some other higher level language that has a whole suite of tooling, supporting libraries, documentation, community and ide support. If the end benefit is j…

Of course, any program can be written completely in C. This, however, does not mean that it's always the best way to write programs.

Suppose you have a piece of code that you have to modify frequently until you find an acceptable solution to your problem. For example, it may be a game character behavior, or automatic vehicle control equations, or something else. If you write this piece of code in C, you have to recompile this module and link the whole project each time you modify the source. With a scripting language, you can write 90% of your code in C, and remaining 10% in this scripting language, so that you compile your C project only once. You can even hand over writing the remaining 10% to the people who are not familiar with low-level programming in C but perfectly understand the problem domain (like engineers or game designers).

Another scenario is when you want your application to be customizable by its users, but only in a controlled way and without exposing the sources.

Post reply on HN