That is a great strategy. It gets easier over time though. My tipp is to still join smoking friends, but just don't smoke. Makes you robust against the temptation longer term.
I'm in Italy right now, and it's not really possible, here everyone smokes, I am trying now to stay away from society, but went for a walk saturday and in the bar I usually go, you can even smoke inside (it's a little underground bar hidden from law/society)
Any language can be sandboxed on the VM level. It's a property of it's implementation. So you can say that Lua has no sandbox friendly implementation right now.
For example, termination you can solve by unwinding the stack in efficiently polled safepoints. You need to take down the entire sandbox-capable Lua VM instance but you can.
Lua has debug hooks that can be used for the purpose; for example an instruction counter coupled with a pool allocator should get one quite far. I would never trust third party bytecode, only source code.
Is anyone familiar with Roblox luau security features?
I work on Truffle for more than 10 years and I recently wrote a comment on hackernews using Futurama instead of Futamura. That comment had it wrong twice.
That's the way I have been saying it in my head this whole time! Think you have enough weight with the team to get them to officially change their terminology?
Pkl was built using the GraalVM Truffle framework. So it supports runtime compilation using Futamura Projections. We have been working with Apple on this for a while, and I am quite happy that we can finally read the sources!
I know it's partly on me for not knowing the domain, but I honestly suspected somebody is trying to make fun of me with some concentrated technobabble.
Especially since I wouldn't expect the topic (configuration languages) to require complex mathematical machinery to work with. Now I have something interesting to dig into.
What has most impressed me about GraalVM and Truffle is their capability of deep-optimizing high-level code like Python and Ruby.
I once saw a demo where someone took a simple operation in Ruby using inefficient-but-elegant syntax (including creating and sorting an array, where a simple loop would have been the appropriate approach in C). He compiled that using TruffleRuby and the entire array construction and sorting was completely optimized out of the generated bytecode.
Glad I'm not the only one who had this reaction. I just can't bring myself to accept that a problem that could be solved with a slightly better version of JSON or property lists requires this many buzzwords.
Those aren't "buzzwords" though, it's a very specific way to implement programming languages. It's not really meaningful except for the PL implementation nerds.
Especially the Futamura projections. It's almost magic and very few people have even heard of them.
Very few people have heard of them. That is exactly the reason why I mention them as often as I can. They are a great entry into the world of meta compilers.
If Futamurma means what I think it means skimming across the Wikipedia entry, it would mean that simple value-holder-file configurations would be parsed and checked at the speed of a general purpose tokenizer. But without closing the door to what the language can express in more elaborate configuration file "landscapes". Best of both worlds and presumably all without requiring anybody but the toolmakers to understand what the buzzwords really mean.
>...suspected somebody is trying to make fun of me...
I think that too, "Futamura projections" are important but they are very very far from "complex mathematical machinery" as you may hear it. They are indeed very simple (even mathematically trivial) and require no special background to understand.
Are you really this upset because people don't know a 60 year old movie reference, and downvoted a comment that didn't add to discussion? And you need to flex your age because of it?
If you get this upset you don't have to post on this site. Or you can learn to be not as reactive to social media.
>Are you really this upset because people don't know a 60 year old movie reference, and downvoted a comment that didn't add to discussion?
Maybe you should read more carefully before replying.
I already said above that I was not complaining.
As for my comment (the supercali... word) not adding to the discussion, you are wrong again. The comment was in the same spirit as my parent and grandparent comments, who used words like cromulent, embiggen and perfectumentous.
>And you need to flex your age because of it?
Wrong again. Nothing in my comment shows that I was "flexing my age", as you call it.
>If you get this upset you don't have to post on this site.
Oh, I don't mind posting. I am having fun. I don't let comments like the one that I replied to, spoil my fun.
>Or you can learn to be not as reactive to social media.
Er, the term is "social" media, not "lone wolf baying at the moon" media.
It indicates people reacting (by replying) to other people, which could include approvingly, neutrally or critically, just like in real life, you know.
But there is something in what you say. This "comments about comments about comments about ..." scenario is getting boring and tedious.
From now on, I'll let the blind downvoters be blind downvoters and keep doing their thing. As I said earlier, HN points are not at all important, to me, at least.
You joke but newer rails versions come with a front end framework named Turbo, and there's also a JS bundler named Turbo, so this is actually too close to reality
This comment is what PKL is going to be remembered for. Tbh I wouldn’t even have the courage to write the comment myself as the framework was coming from Apple.
GraalVM is an alternate JDK that can, among other things, do ahead-of-time compilation for Java.
Truffle is a framework for building languages, that sits on top of Graal.
Futamura Projections are a particularly interesting use case for compile-time partial evaluation.
With partial evaluation you have static (known at compile time) arguments to your function, and dynamic (known at runtime) arguments.
When “your function” is an interpreter, and your static arguments are source code, the output is effectively a self-contained compiled binary.
When your function is an interpreter, and the static arguments are the source code for the interpreter itself, that “self-contained compiled binary” is now itself a compiler.
If you want a tool to be able to generate executable validation from a schema, a compiler framework should come in handy.
It seems like they did not aim to make yet another mvp configuration language, but something that can scale across a wide range of usage scenarios spanning all the way from short-lived processes reading a number from a file to huge libraries of default/override hierarchies. Lack of universality sets an upper bound for the value of a configuration language, particularly when seen through the lens of configuring heterogeneous tech stacks.
I’m also curious, because Graal is pretty exciting stuff, what this might give over Jsonnet or Cuelang. It’s already a hard enough sell to try to get people to adopt these and they are much older and more robust than Pkl.
I'm very wary of anything Java-based, having been burned by Java tooling in the past. I work on a few different Android projects and I have to switch between three different JDK versions depending on which I'm working on. What happened to "write once, run anywhere"??
Pkl’s native binaries are larger than those of other config languages.
It should be as fast and easy to use and reliable as something like esbuild, so I'd suggest they may want to rewrite it in Go like esbuild. I'm not a Go fan at all, but it clearly does some things really well.
You know that the code compiled using future version of java won' work in older versions..rt? I would like to know if any other programming language does that kind of thing.
> t should be as fast and easy to use and
How did you conclude that it's not fast? They are creating native binaries just like Go or any other AOT languages with GCs. Graal native images are as fast or faster than Go. Also it contains a REPL, that's why bigger size. So for CLI tooling as a developer using pkl, you won't see any difference if it's written in java + kotlin or golang.
You know that the code compiled using future version of java won' work in older versions..rt? I would like to know if any other programming language does that kind of thing.
Of course, but what surprises me is the lack of backwards compatibility -- future JVMs refusing the run old code. I get that you have to deprecate old unsafe APIs sometimes, but it feels silly that I need three different Java versions for different Android projects.
They are creating native binaries just like Go or any other AOT languages with GCs. Graal native images are as fast or faster than Go. Also it contains a REPL, that's why bigger size. So for CLI tooling as a developer using pkl, you won't see any difference if it's written in java + kotlin or golang.
That's good! I thought you needed Java to run it.
I figured I should give it a proper try, so I just downloaded it. 105MB!! They're not kidding when they say it's big. I also checked bun (47.7MB) and esbuild (9.8MB) for comparison.
pkl does seem to start up pretty fast, though. 1.6s on the first run (presumably just the time needed to cache that big binary) and ~100ms thereafter.
Pkl is newly open sourced, but it not new. It's been used for years at Apple, and has been battle tested internally.
I'd actually say that our tooling in some ways is more mature. For example, I think our IDE experience (at least in JetBrains editors) is the best out there.
There is no trust in the words “we tested this internally.”
Apple employees can rate it as an old project among themselves, while it is more convenient for everyone else to rate the product from the moment of publication.
Looks like a more robust type system than Jsonnet (but less than Cue), with some amount of flow-control that Cue doesn't seem to support. I am not very familiar with Cue though.
On tonights episode of Futurama bender and the gang explore the temple of Pkl on planet VM where truffles are considered the holy graals and barely run away in time from - The Compilations - an ancient secretive order of silver voiced kong-fu monks tasked with protecting the shrine from alien invaders as has been foretold in prophecies - and strangely reminiscent of 20th century Earth doo-wop group The Drifters.
Cue chase montage shenanigans with Under The Boardwalk playing in the background
Too close to the "reliably solvable by simple heuristic" end of the spectrum to be a good game: if the text is short it's probably a joke, if it is a very long wall of words it's LLM and anything of somewhat reasonable length can only be a legitimate technical explanation, no matter how unlikely.
It's GPL-licensed, and it works. I'm happy they haven't Oracle-ized the JVM, and have been investing into great features that are available to everyone for free.
Your mention of Futamura Projections was a nice reminder of how very mathy/theoretical foundations underpin Nice Things in high-level languages, like Hindley–Milner inspired type systems and modern optimizing compilers targeting SSA form. Value Lattices in Cue [1], another config programmable configuration language, also fall into this bucket.
Not completely related to the OP, but is Truffle going to be upstreamed as part of Project Galahad or will it remain as a library maintained by Oracle Labs?
I ask cause the Project Galahad page on openjdk.org is a bit sparse on details.
The truffle compiler extensions in Graal will be part of Galahad. For example the partial evaluator. The truffle framework and all the languages are consumed from a maven repo as a regular java library these days.
It'd be interesting to understand what kind of performance problem Apple had and tried to solve with GraalVM/Truffle. I've seen some instances of heavy configs that generate literally several gigabytes of data, but those were usually not significant bottlenecks since configs are not updated very frequently.
Of course, I know those two frameworks are one of the engineering marble of the age and would understand even if they decided to go without any concrete needs for it.
I wish people named more tech products after popular media instead of common words. Would make it equally hard to web search, but at least it would be funny for non-techies to listen to
Oh wow, this wasn’t the sort of language I expected to see being built on Truffle, but I’ll be really interested to take a closer look when I’m on a decent net connection.
Truffle has no opinion on how you parse the sources. It cares about how you execute them from an intermediate Truffle guided representation produced by the parser.
In other words antlr and truffle are a great fit. We even use this pairing for our example language simplelanguage.
Alternative to working with a big silicon valley giant. If you want to integrate/use YouTube you need to deal with whatever that company puts you up with. And as the article states, you don't want them to become grumpy at you; otherwise, they will turn you off even quicker. The only alternative I see is to develop a new YouTube, which seems unreasonable given how dominant Google is.
You don’t need a direct alternative to youtube to stop using youtube. You can just not deal with it, or access it via browser when needed, and use other platforms/media more instead. It might even become irrelevant on its own, like facebook and google search are slowly becoming.
But sure, if that’s not enough and you need a clone of youtube then yes, you need to develop a new youtube.
Many content creators have started hosting videos on other services like Patreon because of Youtube's censorship and demonetization policies. Which doesn't entirely avoid the centralization problem but it's better not to put all of your eggs in one basket.
It's also possible (although obviously not always feasible) to self-host or torrent.
Worth mentioning that Rumble, Odysee, and Bitchute are all excellent alternative platforms to host videos at, without the concerns YouTube has introduced. Although, I can't speak to monetization for any of these — which is where Patreon excels here.
X.com is also trying to enter the space by hosting longer videos and allowing accounts to earn ad revenue as well as building a subscriber base who can support creators directly. It's not half bad.
Full disclaimer:
I think it might be implied, but there's certainly a lot of political distaste around these platforms since they finally freed themselves from the shackles of government-aided censorship, and takedowns that are heavily biased towards promoting progressive views (especially radical).
With that said, everyone please refrain from attacking this reply for merely mentioning these platforms as options, as they are equally valid ways to build a following and/or monetize your content, even if they support creators who run against your own views. As they say, diversity is our strength!
I can't see how you can avoid the centralization problem and also have decent monetization for the videos. But I want to certainly become convinced that it can work. Crypto made me a decentralization skeptic.
I think the idea was that they would develop apps that don't require the giants. Which sure, could be your own YouTube, but more often it's a smaller in scope project because you're a solo dev. If i understand them correctly, they're just acknowledging the risk.
Ie work in a way that doesn't require the giants shadow, as the giant may move unexpectedly. The shade can be quite lucrative though, if you're nimble.
Not sure I have questions, just generally interested in making it easier/lighter weight/built-in to constrain ambient authority (for example, to mitigate supply chain risks), thus have it be done more.
The Polyglot sandfox feels very loosely analogous to Deno per process (and thus subprocess) permissions, though it looks like ISOLATED and UNTRUSTED can limit a bunch of things not possible with Deno.
We do not do process isolation yet, although we have plans to implement that as well as a fallback strategy.
The advantage of the native-image-isolate-based isolation is that it is much more lightweight. For example, calls from and to the host application are much faster. There is no copying or expensive synchronization necessary. The disadvantage is that we need to do our own protections against attacks, as the OS protections between processes don't apply to such isolates. By default, we deploy software/compiler-based protections but are also very close to supporting hardware like Intel MPK.
Another java fork like Lombok. But this time the authors didn't take the time to support all java compilers/IDEs, so the situation is even worse.
If this is just to highlight the merit of static extension methods with a follow up JEP I am all for it, but please don't advertise this as a feature for production. It's a trap.
I did some digging on past discussions, and yes, it seems the stars are not aligned for extension methods in standard Java.
But tbh, there are some very good arguments against extension methods. Also, some tricky questions about overloading handling and compatibility are lurking in the shadow. But if you have good suggestions on how to fix them, I'd take the time to propose something on an OpenJDK mailing list, maybe you get some support.
Well a language fork. But not a full implementation fork of course. Or would you argue that what Lombok does is part of the java spec? It effectively extends the java spec in non backwards compatible ways.
