Community is a huge part of learning anything, so if you’re wanting to talk with others who have experience making languages I can’t recommend enough the r/ProgrammingLanguages and their Discord server. Lots of talented developers there!
This is giving V vibes. The Python interop looks like it’s solely present for riding the AI hype tsunami. The mobile framework might be the only functioning part right now.
Haskell is being used as the generator of a declarative UI, rendering is done through another technology that is well established. The cool part is that the dev doesn’t have to know anything about it, only Haskell
- Nick
Sounds cool, no clue what the market is for this. If you’re a seasoned Haskeller, you’re not using this. If you’re new to Haskell / functional languages, a lot of work is required before this is able to be recommended. I think it would have been smarter to market the mobile framework as a mobile framework and the python interop as a different library instead of this combined “language” package. Saying “I’m a maintainer of some Haskell libraries” is a lot nicer on everyone’s ears than “I’m BDFL of a ‘fork’ of Haskell”.
“Generator of a declarative UI that is well established” sounds like QML/QtQuick to me. “The developer doesn’t have to know anything about it, only Haskell” would be a lie though.
I’ve heard that Graphite “fixes” GitHub by building changesets / stacked diffs into PRs. They have their own CLI + site that works with your existing GH repos. The workflow Theo shows off looks promising, but I’d prefer something baked into GH.
Overall I am extremely disappointed with GH’s lack of innovation in UX. I have been on GH almost a decade and somehow it has only become a worse tool. I am begging that SourceHut or Pierre or literally anyone else takes a larger market share so I can convince employers/coworkers to jump off this clusterfuck of a website. I think seeing “Code 55% faster with GitHub Copilot” in the code viewer was the final straw for me.
I have never been more irritated by the design of a website. Whilst I am sure this exploit would have been cool to read about, it’s a hard pass from me.
A very cursed workflow I had early in high school was using my iPad to edit code on GitHub that would be compiled in Travis CI… syntax errors would result in many spammed commits
sadly a lot of “real” “programming language” “discussions” are only marginally more productive than the points in this talk. quite fun!
Other great quotes:
Talking about Rust on the internet makes you a popular person.
Traits are really bad, they were stolen from Haskell, and they’re fucking shit.
All of Rust is stolen from Haskell and ML anyway.
Here is the github link - I can’t get the hackmd.io site to load.
This is some pretty targeted malware that at its core exploits the trust the Minecraft modding community has for mod authors. “Minecraft mods” are arbitrary code - the potential for this to happen has always been here and will continue to be here as long as mods aren’t sandboxed in any meaningful way.
The quick version, while we get this document in shape: client.jar searches the entire filesystem for files that look like mod JARs, and infects them with Stage0. This includes entire Gradle and Maven caches, as well as tons of things mod devs would likely never think to check. The potential scale and scope of this infection has gone from “a couple weird mods” to potentially infinite.
Mojang & Microsoft have no intention of changing how mods work, and this incident will be repeated in the future. I was lucky enough to bump into a Mojang employee at GDC’23, and we had a quick talk about modding as I’ve been making Minecraft mods since 2011. He reiterated a sentiment that has been around for a long time: Minecraft: Java Edition is here to stay, security issues and all, and the modding community is on its own to build the infrastructure & regulations it needs. This is not the first attack on Minecraft users, and it will certainly not be the last.
Mojang & Microsoft have no intention of changing how mods work
Some context for other people: Mojang doesn’t provide a (real) modding API, they’re all fanmade.
On another note, back when I played Minecraft I ran it in a sandbox, out of the worry that something like this might happen. I’m sad that my paranoia got proven right yet again, but also amazed it took so long for this to happen. Thankfully it seems like this attack jumpstarted discussions on sandboxing mods in future modloaders, which will definitely be a welcome change.
The impression I got when I looked into it years ago is that Mojang really, really doesn’t want mods to exist at all. As much as I’d like to paint them as the bad guys, when the mod community treats security like an afterthought, it just makes the hostility of Mojang seem more justified and probably encourages others to react the same way.
I don’t know where you got that impression from. Notch wanted a modding API basically from the start, he hired Bukkit’s author. Nowadays Mojang releases official deobfuscation maps to make modding easier. I don’t think they went through a period of disliking mods but I might be wrong.
Could be; the modding experience (not even making mods; just installing them) when I looked at it many years ago was so miserable I made an about face and never looked back. If they’ve reversed their stance that’s good to hear.
I have a feeling that a lot of it was due to how they’ve built their stuff to just work (for them).
If I’d have to compare it with something, it would’ve been their whole protocol design. Which was horrible. And kinda still is: They have things like custom compression, but use the Java deflate on the protocol level if the packet gets too big anyway. Multiple layers of compression isn’t the most efficient thing anyway. And Java deflate doesn’t fully adhere to the standard deflate anyway which is another thing.
They are slowly getting rid of the worst offenders though.
It works for them. But it is incredibly annoying to implement the minecraft protocol without it breaking in the next patch.
They avoided basic standards on how to change protocol packets. Their design requires some custom mapping of IDs depending on the protocol version. Which is annoying.
Also the protocol packet definitions did depend on the world state up until 1.14 I think.
So the conclusion is that they never really were against modding. They have just built their stuff in a fashion which worked for them without considerations to other implementations. Which is bad for modding.
How do you sandbox Minecraft with the necessity for this like all the 3d graphics drivers and stuff to carry on working? Just run it as a different unprivileged user account?
I used Flatpak. It’s definitely not perfect, and it can be easily broken out of, but it seems like it would have worked against this particular piece of malware.
Doesn’t mojo run only on a proprietary platform? You can’t run it on your machine for now, you don’t have access to the source code and you need to create an account just to try it out?
In this sense, it doesn’t matter how good Mojo his, golden cuffs are still cuffs.
I don’t understand why this comment continues to be repeated on every story involving a soon-to-be open sourced project. The FAQ answers your first question:
Will Mojo be open-sourced?
Yes, we expect that Mojo will be open-sourced. However, Mojo is still young, so we will continue to incubate it within Modular until more of its internal architecture is fleshed out. We don’t have an established plan for open-sourcing yet.
Many projects go this route because “open sourcing” can entail a lot, especially when you’ve been developing in private for a long time. First impressions are, sadly, one of the most important things you need to get correct. Go, Rust, Kotlin, and many other languages were private before going public. This is a good strategy because the development teams can iron out key user-facing issues (installation, OS support, documentation, community guidelines, etc.) after creating the initial prototype.
It is proprietary for now, and I would place a substantial bet on Mojo being open sourced before Jai lol.
A lot of projects that promised to open source never open sourced, or perhaps open sourced with too many strings attached.
Pointing out that it’s proprietary right now is valuable to many people, as they may want to hold off on evaluating it until the promised open sourcing happens.
If you want to keep your new whizzbang close to the vest, then DO THAT and don’t announce it to the world until I can put my hands on it and kick the tires.
That’s my subjective opinion anyway. WAY too much vapor in the world, and way too many amazing languages died on the vine because they had barriers to adoption that killed them (REBOL anyone?)
But that has nothing to do with its virtues as a language. You’re confusing the business practices of an implementor with the design of the language, or at least going off on a tangent.
It does, though, because languages are about doing things, not just debating syntax and semantics in a void. Interlisp was great because it had the Interlisp environment, a whole system with a structural editor and a nice GUI and good documentation, but that’s also what makes it more of a curiosity than a practical language these days. The environment only lives in an emulator, disconnected from the outside world. It’s a ship in a bottle. It would have to be reinvented entirely to become useful again.
Mojo is similarly constrained, even if its effective “bottle” is bigger, and just as at risk of being left behind.
I get where you’re coming from, but I think you’d need a more finely tuned phrase than “virtues of the language” because, as others have cited, ecosystem and availability are most DEFINITELY virtues.
Look at Perl, an ugly duckling for many, and yet there are MILLIONS of lines of it squirming around in production systems worldwide.
Why? Because it’s EVERYWHERE, runs on EVERYTHING, and has a VAST library of plug and play software in the form of CPAN.
These things matter.
Now, if you’re talking about the virtue’s of a language’s design STRICTLY on the syntax level, I could buy that maybe…
That was for the launch, I just watched this long interview and Lattner said they’re working on a release that you can download and run on your machine:
That would go a long way towards me seeing it as a real thing.
Open sourcing is important, but being able to actually kick the tires is moreso in my book at last in terms of evaluation.
Longer term, if it’s not open sourced, UNLESS it has a super duper compelling niche that makes it orders of magnitude better than the free solution, it will die.
In that sense, using that rubric, yeah, it’s something to ignore. However, the implementation choices and design are still interesting, so in that sense, it’s a compelling read.
I didn’t know this was valid. I guess I assumed that pointer arguments in extern functions always had to be raw pointers? It seems like the semantics guaranteed by & and &mut could never be correct when passing pointers from C.
calling, say, add_twice(&bar, &bar) from C results in undefined behavior
Rust gives ABI layout guarantees for a few types. For example extern fn free_t(_: Option<Box<T>>){} is a valid useful implementation taking a nullable pointer and freeing it.
But it’s caller’s responsibility to pass valid data. Rust enforces this on its side, but C can’t.
Tangent, but note that assuming you care about portability and haven’t done things like setup custom allocators, you should only free something allocated by Rust like this, not something allocated in C with malloc. Freeing rust-allocated pointers in C or C allocated pointers in rust is a way to get undefined behaviour.
Elm 0.19 nuked any good thoughts I had towards the language. Limiting native modules to a small group of people was a bad design decision, and the lack of leadership has imo doomed the language. elm-janitor is a project that exists to cleanup the mess, and they link a useful but sad spreadsheet of all the fixes that have yet to be merged.
If I were to stick to a functional language today, I would bet on Roc succeeding where Elm couldn’t.
I think ReScript has pretty much taken that niche already. It did what Elm didn’t–provide a pragmatic, interoperable integration with the rest of the JS ecosystem while also providing type safety and fast compiles.
mm this does look like a proper replacement, whereas my Roc evangelism is probably premature. my first question would be how it differs from reason ml which also fills the functional-web niche
ReScript is a continuation of the ReasonML functional-web effort. It split off from the ‘ReasonML’ branding to create a more integrated, turnkey experience for typed functional web dev.
This may sound nit-picky or unreasonable, but the immediate blocker for me adopting ReScript is its take on Option/undefined/null.
I actually do use undefined and null to mean semantically different things in my JavaScipt/TypeScript code. For example, if I’m sending a POST request to my backend API, it will treat a missing field (undefined) as unset and needing the default value (if it is intended to be optional), and it will treat a present null to mean that the client is explicitly denoting “emptiness” for the value and it will NOT be overwritten with a default value.
Likewise, in languages with a generic Option type (Swift, Rust, Kotlin-when-I-write-it), I do sometimes represent the above semantics similarly by having an Option<Option<T>> (or Option<T?> in Kotlin) for an “optional nullable” value.
I realize that ReScript has escape hatches for these things, but I feel like “escape hatches” are for uncommon situations; I don’t want to have these “escape hatches” all over my code and have to fight against the grain of the language.
As much as I loathe TypeScript, I feel like I’m stuck with it.
Right, I know. It’s just that the standard library functions all use option<'a>, so I worry about needing to do a bunch of fiddling between three kinds of “maybe present” types instead of the usual two. Maybe in practice it isn’t bad, but I’ve dug myself into plenty of holes before while trying to go against the grain of the language I was using.
I don’t see any big problems, you just define your form fields with strong types like myField: option<string> and convert the weaker-typed values received over the network into strongly-typed internal values with checks and converter functions. It’s conceptually very similar to TypeScript except it doesn’t suffer from the ‘wrapping’ problem because the option type has special compiler support.
I think the biggest one is the compiler using MLIR for compilation to CPU/GPU/TPU/etc. Mojo exposes MLIR types & dialects, so you could write custom primitive types that target custom hardware and have them available from Mojo (and, in the future, Python code you’re running inside the Mojo interpreter). There are a lot of existing transformations in the MLIR ecosystem they can pickup today, along with whatever custom dialect transformations they’re making in Mojo.
This is killer for tensor/vector operations, and Modular has shown this performance increase accumulates to full programs with their inference engine being 2x-3x faster than TF & PyTorch (on their select benchmarks).
Their goal is to support 100% of Python syntax, so it should be possible to write and run Pure Python code in Mojo.
From what I understand, you will continue to write your Python code in Mojo but the parts which are performance critical you would write in the extended syntax provided by Mojo and use the efficient primitives provided by Mojo such as SIMD, loop unrolling, multi-core execution.
Although, you could do this today in Python as well. For example, by writing the performance critical parts in C, or by using Cython/Numba. But Cython/Numba cannot optimize everything, and the other advantage offered by Mojo is that it can target multiple hardware architectures without any effort on the programmer’s part.
Consider: What structural properties might Mojo have which allows it to do things that Cython, Nuitka, or other prior attempts have failed to do? How will Mojo handle eval and exec, for example? More pointedly, what does Mojo offer that a JIT compiler cannot also offer?
I’m quite excited about mojo. It seems like it will make python the language even more powerful by making it possible to create binaries. I’m curious to see how Modular is going to cultivate the community and choose to monetize it in the long run
I’m sure you can create binaries of Mojo code, but how would it work with Python code? Is that being claimed?
I think there’s been a great deal of confusion over the technical relationship between Mojo and Python.
As stated in their launch docs, Mojo doesn’t even support Python classes. So uh all NumPy objects are instances of classes.
What I saw shown was that you create vectors and matrices with Mojo struct , and then you copy them into NumPy objects to use matplotlib and so forth.
That seems like a good strategy for a fast low level language interacting with a slower dynamic high level one.
But I don’t see a real path to creating binaries from code of the typical stack: Python + NumPy + SciPy + matplotlib, etc.
I think there is going to be the “long tail” issue
With significant effort, you can create a version of Python that looks compatible enough to users writing new code. See Jython, IronPython, PyPy. I’m sure they can do this.
With great effort, write a Python interpreter that can run any pure Python code out there. MicroPython is an example of a useful project that falls short of this (e.g. its Unicode is different AFAIK), but I also think they can do this.
With even greater effort, your interpreter can run some C extensions. See PyPy’s long history with this. Note that Python is only recently getting a stable ABI – in the past you actually would have to emulate CPython 2.6, 2.7, 3.0, 3.1 APIs to run code !! PyPy has parallel releases to match different version of Python.
I think it’s basically an unsolved problem to run even 50% of the important C extensions out there. Is CPython is the only implementation that can run NumPy and Pandas? I think so. And if you add matplotlib and few others, I’m pretty sure it is.
I think you can get to #2 in a few years (although don’t underestimate how hard it is to implement Python classes compatibly !! It is a very big language semantically; the syntax is misleading)
I don’t want to be too negative since Lattner basically achieved the impossible with LLVM / Clang, improving all of open source … but I think 3 and 4 will take a lot longer than people think (if they are even goals, and I think they are).
Higher level can sometimes be harder, because you have more stuff that you sit on top of. Python sits on shakier foundation of things that have more versions than say x86 and ARM, which LLVM sits on.
Also I think doing things within a company could discourage outside contribution and knowledge, which I think is needed. It seems to me like LLVM succeeded in a large part because it was open source and also sponsored by Apple, Google, etc.
One concern I had is that I didn’t hear much mention of them hiring people in the Python community … like NumPy creator Travis Oliphant has his own company and projects around fast Python compilers. I think it would go a lot faster to approach things from both sides – i.e. basically fork NumPy for Mojo and then merge things upstream. But maybe that’s already happening and I don’t know, or they will quickly change strategies to something like that.
Their current solution to run Python code (from my understanding) is exactly like how Julia / Swift bridging to Python: running Python code in CPython interpreter and then bridging through CPython API. It works (I maintain my own fork of PythonKit for Swift, which owes it’s origin from S4TF project), but to go deeper, 1. you cannot make Python go faster; 2. the bridging of custom types such as numpy ND-array, PyTorch’s tensor would still take effort and not automatic; 3. it restricts the host language choices such as refcount over garbage collect (this is easier since Mojo is a new language and aim to have familiar syntax as Python).
Right, this is basically exactly what I was trying to say
I don’t know the details, since the project isn’t public
But everyone is thinking they ALREADY wrote a superset of Python. But what they appear to have done is
Wrote a small, fast, static language with Python syntax, and with a runtime bridge to CPython
SAID they would make it a superset in the future
There’s a huge difference between those 2 things. I’m not saying they can’t do that, or won’t do that – I just want to know what it is, without being clouded by marketing. I have huge respect for accomplishments of the Modular team, but the way it was presented was pretty confusing.
(And this substack post certainly didn’t help with that!)
They have their own standard library implantation and their own compiler. It basically supports python language features plus some new syntax for new capabilities like static types
Mojo still doesn’t support classes, the primary thing Python programmers use pervasively! This isn’t because we hate dynamism - quite the opposite. It is because we need to get the core language semantics nailed down before adding them. We expect to provide full support for all the dynamic features in Python classes, and want the right framework to hang that off of.
Having a Python compatible standard lib means you can run your Python code as is via mojo without changing it.
Some python libs would need to be ported over to mojo. If it becomes popular, I’m sure that all happen. If they keep the language and the tools open source, i think it would help become popular. We’ll see..
Btw I don’t think they will ever do #3 or #4. Mojo isn’t trying to be a better Python. It’s using python as a stepping stone because it’s a popular language, especially for ai/ml.
Yes, they have definitely got the attention. It seems promising, although in order to get the max performance we do need to step outside of the Python syntax and use Mojo’s extended syntax but that is the case in Python as well – you would write C/C++ or Cython code. The advantage here is that the same Mojo code will run on every hardware without any changes.
As far as monitization is concerned, I think Modular might leverage their platform such as the AI inference engine and other offerings. Mojo, they are going to opensource at some point.
In the last year I’ve really been focusing on R and Zig. R for classes & my grad research, hacking on my advisor’s R/C++ packages. I don’t particularly enjoy R, but I’ve become comfortable enough in it to (somewhat) read the insane incantations of veteran R statisticians. I’ve been learning Zig in an attempt to use it as a replacement for where I end up using C, and have recently started a compiler that uses Zig for small runtime components (similar to Roc). I find myself having a lot more fun in Zig than in C or C++, but Rust is still my go-to systems/low-level language.
Neither of those were my “latest” which goes to Mojo. I wrote a neural network from scratch a last year in Python, and I wanted to recreate it in Mojo to compare the languages. There were some issues I ran into, but I was able to get a small model working. Mojo caries over the mutable value semantics of Swift which I’m still trying to wrap my head around (the implicit copies were killing me before I added debug to every constructor I had).
As for “how did it changed the way you see programming”, I feel like every language has a bit to teach you. The compiler I started is for a language I’ve been designing for a while that takes inspiration from some of these and more. Zig’s comptime is incredibly eye opening in terms of what a language could provide for type manipulation. Mojo shows us a relatively simple language can achieve insane performance compared to standard C/C++ by utilizing better/different hardware and compiler architecture. R taught me…. well, I’m not sure what, but at least I can use ggplot well.
Generics are a Nightmare.
Generics are much harder to implement than templates.
I got curious about the implementation… I’ve been reading through the Vale blog posts for a while but it’s gonna take me a while to digest some of this!
Your understanding is correct! These generics don’t require traits, they only require that a function exists for a certain type. It’s a nice way to decouple functions from data. They’re explained more here: https://verdagon.dev/blog/concept-functions
Also, that Tup is actually a casualty of the great generics endeavor. Before generics, it used to work like in https://verdagon.dev/blog/const-generics-spread and handle any number of elements. It’ll be fun to get that working in a post-generics world.
#!DeriveStructDrop means “don’t automatically generate a drop function for this, I’ll be doing it myself”
Some planned syntactic improvements that might be relevant:
where ~T instead of where func drop(T)void
Default to #!DeriveStructDrop, so the automatic drop function is opt-in instead of opt-out.
Have some sort of block to surround e.g. those isEmpty funcs, so that we can write the common where clause once.
Happy to clarify anything, and feel free to drop by the discord too! Lots of folks toss around questions in there.
I’ve been using discord heavily since 2015, and I’m fine with moving to standard usernames. If you put a gun to my head, I couldn’t tell you my discriminator, and I’m not sure that I knew it was called that before the announcement. It has always been a completely random number to me, and I have to open discord every time I want to share it with someone.
However, some users wanted to be unsearchable, because they had stalkers or were very popular and didn’t want random people finding their discord account. Discriminators and case-sensitivity essentially created a searchability problem which users were utilizing on purpose to make it harder for people to search them.
& from the linked tweet:
Now that an account won’t use a discriminator, users are more prone to getting harassed and/or scammed, be it a targeted campaign or simply for owning that specific username.
I 100% agree people should be able to opt out of user searching. There are already some good privacy options in place, such as disabling messages from people that aren’t friends with you. I don’t however think this change impacts harassment much, or at least I’d need to see some data to backup that claim.
What I’m failing to understand is how switching your discriminator from jado#1234 to jado#4321 to avoid harassment is substantially different from switching @jado1234 to @jado4321. They seem identical to me, but maybe the search feature could/would interact with this change differently.
Additionally, impersonation is already a problem on discord, and I would say the discriminator system facilitates it because (ignoring Nitro) everyone has a random number. Prominent community members in one server will probably have a rank, but when they go to another server they look like every other member.
If your users are confused and angry about it, then it’s your fault, not theirs.
This can certainly be true, but I don’t think it’s guaranteed. Every time we push a user facing change that breaks some workflow, it is met with 1000 twitter replies saying “this new XYZ looks awesome” and 1000 replies saying “this new XYZ looks like trash”.
One aspect is massively psychological. A “discriminator” discriminates, visually, literally. You are not jado1234. You are jado, the 1,234th. Nobody can take the identity of jado away from you. Nobody is going to try and steal your Discord account because they’re upset they can’t be jado or their new cryptocurrency scam is jadocoin. They can be jado too.
(r.e. impersonation - you can’t impersonate someone’s discriminator, which is why people often stick with the same one. even between servers you’re still jado#1234, people often persist with one tag for this consistency to avoid impersonation.)
We measure 5x speedups over dense self-attention at length 8192 – 2x over highly optimized FlashAttention2
(Dao et al., 2022b) – and 100x speedup over FlashAttention at sequence lengths of 64k, where standard
attention implementation in PyTorch runs out of memory.
They’re matching GPT’s perplexity while being capable of a much larger sequence length. They also compared this to the recent RWKV which is another Transformer alternative, and they’re able to smoke everyone when the sequence length is > 30k (Table 4.2, page 10).
Got Covid! Doing AoC in Rust!
Community is a huge part of learning anything, so if you’re wanting to talk with others who have experience making languages I can’t recommend enough the r/ProgrammingLanguages and their Discord server. Lots of talented developers there!
This is giving V vibes. The Python interop looks like it’s solely present for riding the AI hype tsunami. The mobile framework might be the only functioning part right now.
Sounds cool, no clue what the market is for this. If you’re a seasoned Haskeller, you’re not using this. If you’re new to Haskell / functional languages, a lot of work is required before this is able to be recommended. I think it would have been smarter to market the mobile framework as a mobile framework and the python interop as a different library instead of this combined “language” package. Saying “I’m a maintainer of some Haskell libraries” is a lot nicer on everyone’s ears than “I’m BDFL of a ‘fork’ of Haskell”.
“Generator of a declarative UI that is well established” sounds like QML/QtQuick to me. “The developer doesn’t have to know anything about it, only Haskell” would be a lie though.
I’ve heard that Graphite “fixes” GitHub by building changesets / stacked diffs into PRs. They have their own CLI + site that works with your existing GH repos. The workflow Theo shows off looks promising, but I’d prefer something baked into GH.
Overall I am extremely disappointed with GH’s lack of innovation in UX. I have been on GH almost a decade and somehow it has only become a worse tool. I am begging that SourceHut or Pierre or literally anyone else takes a larger market share so I can convince employers/coworkers to jump off this clusterfuck of a website. I think seeing “Code 55% faster with GitHub Copilot” in the code viewer was the final straw for me.
There is also a follow up post
I have never been more irritated by the design of a website. Whilst I am sure this exploit would have been cool to read about, it’s a hard pass from me.
This looks like the slides for someone’s conference talk, I don’t think it’s intended to be a readable article per-se.
Reveal.js probably isn’t the most intuitive to use, but you can hit Space to go to the proper next slide instead of manually going down & right.
How do you do that on mobile?
A very cursed workflow I had early in high school was using my iPad to edit code on GitHub that would be compiled in Travis CI… syntax errors would result in many spammed commits
sadly a lot of “real” “programming language” “discussions” are only marginally more productive than the points in this talk. quite fun!
Other great quotes:
feels like I’m reading HN lol
My favorite was
If crabs are rubbish how do you explain that everything wants to become one?
Rust Evangelism Strike Force propaganda.
Fair enough.
Here is the github link - I can’t get the hackmd.io site to load.
This is some pretty targeted malware that at its core exploits the trust the Minecraft modding community has for mod authors. “Minecraft mods” are arbitrary code - the potential for this to happen has always been here and will continue to be here as long as mods aren’t sandboxed in any meaningful way.
Mojang & Microsoft have no intention of changing how mods work, and this incident will be repeated in the future. I was lucky enough to bump into a Mojang employee at GDC’23, and we had a quick talk about modding as I’ve been making Minecraft mods since 2011. He reiterated a sentiment that has been around for a long time: Minecraft: Java Edition is here to stay, security issues and all, and the modding community is on its own to build the infrastructure & regulations it needs. This is not the first attack on Minecraft users, and it will certainly not be the last.
Some context for other people: Mojang doesn’t provide a (real) modding API, they’re all fanmade.
On another note, back when I played Minecraft I ran it in a sandbox, out of the worry that something like this might happen. I’m sad that my paranoia got proven right yet again, but also amazed it took so long for this to happen. Thankfully it seems like this attack jumpstarted discussions on sandboxing mods in future modloaders, which will definitely be a welcome change.
The impression I got when I looked into it years ago is that Mojang really, really doesn’t want mods to exist at all. As much as I’d like to paint them as the bad guys, when the mod community treats security like an afterthought, it just makes the hostility of Mojang seem more justified and probably encourages others to react the same way.
I don’t know where you got that impression from. Notch wanted a modding API basically from the start, he hired Bukkit’s author. Nowadays Mojang releases official deobfuscation maps to make modding easier. I don’t think they went through a period of disliking mods but I might be wrong.
Could be; the modding experience (not even making mods; just installing them) when I looked at it many years ago was so miserable I made an about face and never looked back. If they’ve reversed their stance that’s good to hear.
I have a feeling that a lot of it was due to how they’ve built their stuff to just work (for them).
If I’d have to compare it with something, it would’ve been their whole protocol design. Which was horrible. And kinda still is: They have things like custom compression, but use the Java deflate on the protocol level if the packet gets too big anyway. Multiple layers of compression isn’t the most efficient thing anyway. And Java deflate doesn’t fully adhere to the standard deflate anyway which is another thing.
They are slowly getting rid of the worst offenders though.
It works for them. But it is incredibly annoying to implement the minecraft protocol without it breaking in the next patch.
They avoided basic standards on how to change protocol packets. Their design requires some custom mapping of IDs depending on the protocol version. Which is annoying.
Also the protocol packet definitions did depend on the world state up until 1.14 I think.
So the conclusion is that they never really were against modding. They have just built their stuff in a fashion which worked for them without considerations to other implementations. Which is bad for modding.
there were talks about releasing an official API for years, which never happened
and nowadays you won’t be gaining any grounds by breaking years of modding history, there are complete ecosystems of mods, gameplay, integration etc
Fabric was a brand new project relatively late in Minecraft’s lifespan, incompatible with old mods, but it still managed to achieve widespread usage.
I’m not saying that this is something that could repeat without a lot of luck, but it’s not impossible either.
How do you sandbox Minecraft with the necessity for this like all the 3d graphics drivers and stuff to carry on working? Just run it as a different unprivileged user account?
In Java custom class loaders can probably be used to prevent file access via
java.{n,}io. That’s in-VM sandboxing, not unlike in web browsers.Oh no I would not trust that, haha, I remember the 00’s.
I used Flatpak. It’s definitely not perfect, and it can be easily broken out of, but it seems like it would have worked against this particular piece of malware.
Makes sense, thanks.
According to the title of the hackmd, it looks like they’ve moved to GitHub. mods: is it possible to change the link?
Doesn’t mojo run only on a proprietary platform? You can’t run it on your machine for now, you don’t have access to the source code and you need to create an account just to try it out?
In this sense, it doesn’t matter how good Mojo his, golden cuffs are still cuffs.
I don’t understand why this comment continues to be repeated on every story involving a soon-to-be open sourced project. The FAQ answers your first question:
Many projects go this route because “open sourcing” can entail a lot, especially when you’ve been developing in private for a long time. First impressions are, sadly, one of the most important things you need to get correct. Go, Rust, Kotlin, and many other languages were private before going public. This is a good strategy because the development teams can iron out key user-facing issues (installation, OS support, documentation, community guidelines, etc.) after creating the initial prototype.
It is proprietary for now, and I would place a substantial bet on Mojo being open sourced before Jai lol.
A lot of projects that promised to open source never open sourced, or perhaps open sourced with too many strings attached.
Pointing out that it’s proprietary right now is valuable to many people, as they may want to hold off on evaluating it until the promised open sourcing happens.
That sounds like an aspiration. It doesn’t sound “soon-to-be open sourced” for any definition of “soon” that I like.
I do, for exactly the reasons others have cited.
If you want to keep your new whizzbang close to the vest, then DO THAT and don’t announce it to the world until I can put my hands on it and kick the tires.
That’s my subjective opinion anyway. WAY too much vapor in the world, and way too many amazing languages died on the vine because they had barriers to adoption that killed them (REBOL anyone?)
But that has nothing to do with its virtues as a language. You’re confusing the business practices of an implementor with the design of the language, or at least going off on a tangent.
Why does the discussion need to be limited to the virtues of the language?
Language and ecosystem are intimately intertwined.
If someone claims “X is a better Y than Z” then of course all the factors concerned with actually using it must be considered.
Making broad claims means taking into account broad concerns. Want to limit these considerations? Limit the claim being made.
It does, though, because languages are about doing things, not just debating syntax and semantics in a void. Interlisp was great because it had the Interlisp environment, a whole system with a structural editor and a nice GUI and good documentation, but that’s also what makes it more of a curiosity than a practical language these days. The environment only lives in an emulator, disconnected from the outside world. It’s a ship in a bottle. It would have to be reinvented entirely to become useful again.
Mojo is similarly constrained, even if its effective “bottle” is bigger, and just as at risk of being left behind.
I get where you’re coming from, but I think you’d need a more finely tuned phrase than “virtues of the language” because, as others have cited, ecosystem and availability are most DEFINITELY virtues.
Look at Perl, an ugly duckling for many, and yet there are MILLIONS of lines of it squirming around in production systems worldwide.
Why? Because it’s EVERYWHERE, runs on EVERYTHING, and has a VAST library of plug and play software in the form of CPAN.
These things matter.
Now, if you’re talking about the virtue’s of a language’s design STRICTLY on the syntax level, I could buy that maybe…
That was for the launch, I just watched this long interview and Lattner said they’re working on a release that you can download and run on your machine:
https://www.youtube.com/watch?v=pdJQ8iVTwj8&t=142s
I don’t know if it will be open sourced at the same time.
That would go a long way towards me seeing it as a real thing.
Open sourcing is important, but being able to actually kick the tires is moreso in my book at last in terms of evaluation.
Longer term, if it’s not open sourced, UNLESS it has a super duper compelling niche that makes it orders of magnitude better than the free solution, it will die.
In that sense, using that rubric, yeah, it’s something to ignore. However, the implementation choices and design are still interesting, so in that sense, it’s a compelling read.
The motivating example in the introduction is interesting:
I didn’t know this was valid. I guess I assumed that pointer arguments in extern functions always had to be raw pointers? It seems like the semantics guaranteed by
&and&mutcould never be correct when passing pointers from C.Rust gives ABI layout guarantees for a few types. For example
extern fn free_t(_: Option<Box<T>>){}is a valid useful implementation taking a nullable pointer and freeing it.But it’s caller’s responsibility to pass valid data. Rust enforces this on its side, but C can’t.
Tangent, but note that assuming you care about portability and haven’t done things like setup custom allocators, you should only free something allocated by Rust like this, not something allocated in C with malloc. Freeing rust-allocated pointers in C or C allocated pointers in rust is a way to get undefined behaviour.
Elm 0.19 nuked any good thoughts I had towards the language. Limiting native modules to a small group of people was a bad design decision, and the lack of leadership has imo doomed the language. elm-janitor is a project that exists to cleanup the mess, and they link a useful but sad spreadsheet of all the fixes that have yet to be merged.
If I were to stick to a functional language today, I would bet on Roc succeeding where Elm couldn’t.
I think ReScript has pretty much taken that niche already. It did what Elm didn’t–provide a pragmatic, interoperable integration with the rest of the JS ecosystem while also providing type safety and fast compiles.
mm this does look like a proper replacement, whereas my Roc evangelism is probably premature. my first question would be how it differs from reason ml which also fills the functional-web niche
My understanding is that ReScript is essentially a rebranding of ReasonML which has mostly been abandoned.
ReScript is a continuation of the ReasonML functional-web effort. It split off from the ‘ReasonML’ branding to create a more integrated, turnkey experience for typed functional web dev.
This may sound nit-picky or unreasonable, but the immediate blocker for me adopting ReScript is its take on
Option/undefined/null.I actually do use
undefinedandnullto mean semantically different things in my JavaScipt/TypeScript code. For example, if I’m sending a POST request to my backend API, it will treat a missing field (undefined) as unset and needing the default value (if it is intended to be optional), and it will treat a presentnullto mean that the client is explicitly denoting “emptiness” for the value and it will NOT be overwritten with a default value.Likewise, in languages with a generic Option type (Swift, Rust, Kotlin-when-I-write-it), I do sometimes represent the above semantics similarly by having an
Option<Option<T>>(orOption<T?>in Kotlin) for an “optional nullable” value.I realize that ReScript has escape hatches for these things, but I feel like “escape hatches” are for uncommon situations; I don’t want to have these “escape hatches” all over my code and have to fight against the grain of the language.
As much as I loathe TypeScript, I feel like I’m stuck with it.
ReScript can deal with
nullandundefinedseparately using its provided APIs:Right, I know. It’s just that the standard library functions all use
option<'a>, so I worry about needing to do a bunch of fiddling between three kinds of “maybe present” types instead of the usual two. Maybe in practice it isn’t bad, but I’ve dug myself into plenty of holes before while trying to go against the grain of the language I was using.I don’t see any big problems, you just define your form fields with strong types like
myField: option<string>and convert the weaker-typed values received over the network into strongly-typed internal values with checks and converter functions. It’s conceptually very similar to TypeScript except it doesn’t suffer from the ‘wrapping’ problem because the option type has special compiler support.Wow that spreadsheet is really depressing.
How is this different from other dialects of Python which compile a subset to fast native code?
I think the biggest one is the compiler using MLIR for compilation to CPU/GPU/TPU/etc. Mojo exposes MLIR types & dialects, so you could write custom primitive types that target custom hardware and have them available from Mojo (and, in the future, Python code you’re running inside the Mojo interpreter). There are a lot of existing transformations in the MLIR ecosystem they can pickup today, along with whatever custom dialect transformations they’re making in Mojo.
This is killer for tensor/vector operations, and Modular has shown this performance increase accumulates to full programs with their inference engine being 2x-3x faster than TF & PyTorch (on their select benchmarks).
Their goal is to support 100% of Python syntax, so it should be possible to write and run Pure Python code in Mojo. From what I understand, you will continue to write your Python code in Mojo but the parts which are performance critical you would write in the extended syntax provided by Mojo and use the efficient primitives provided by Mojo such as SIMD, loop unrolling, multi-core execution.
Although, you could do this today in Python as well. For example, by writing the performance critical parts in C, or by using Cython/Numba. But Cython/Numba cannot optimize everything, and the other advantage offered by Mojo is that it can target multiple hardware architectures without any effort on the programmer’s part.
Consider: What structural properties might Mojo have which allows it to do things that Cython, Nuitka, or other prior attempts have failed to do? How will Mojo handle
evalandexec, for example? More pointedly, what does Mojo offer that a JIT compiler cannot also offer?I’m quite excited about mojo. It seems like it will make python the language even more powerful by making it possible to create binaries. I’m curious to see how Modular is going to cultivate the community and choose to monetize it in the long run
I’m sure you can create binaries of Mojo code, but how would it work with Python code? Is that being claimed?
I think there’s been a great deal of confusion over the technical relationship between Mojo and Python.
As stated in their launch docs, Mojo doesn’t even support Python classes. So uh all NumPy objects are instances of classes.
What I saw shown was that you create vectors and matrices with Mojo
struct, and then you copy them into NumPy objects to use matplotlib and so forth.That seems like a good strategy for a fast low level language interacting with a slower dynamic high level one.
But I don’t see a real path to creating binaries from code of the typical stack: Python + NumPy + SciPy + matplotlib, etc.
I think there is going to be the “long tail” issue
I think you can get to #2 in a few years (although don’t underestimate how hard it is to implement Python classes compatibly !! It is a very big language semantically; the syntax is misleading)
I don’t want to be too negative since Lattner basically achieved the impossible with LLVM / Clang, improving all of open source … but I think 3 and 4 will take a lot longer than people think (if they are even goals, and I think they are).
Higher level can sometimes be harder, because you have more stuff that you sit on top of. Python sits on shakier foundation of things that have more versions than say x86 and ARM, which LLVM sits on.
Also I think doing things within a company could discourage outside contribution and knowledge, which I think is needed. It seems to me like LLVM succeeded in a large part because it was open source and also sponsored by Apple, Google, etc.
One concern I had is that I didn’t hear much mention of them hiring people in the Python community … like NumPy creator Travis Oliphant has his own company and projects around fast Python compilers. I think it would go a lot faster to approach things from both sides – i.e. basically fork NumPy for Mojo and then merge things upstream. But maybe that’s already happening and I don’t know, or they will quickly change strategies to something like that.
Their current solution to run Python code (from my understanding) is exactly like how Julia / Swift bridging to Python: running Python code in CPython interpreter and then bridging through CPython API. It works (I maintain my own fork of PythonKit for Swift, which owes it’s origin from S4TF project), but to go deeper, 1. you cannot make Python go faster; 2. the bridging of custom types such as numpy ND-array, PyTorch’s tensor would still take effort and not automatic; 3. it restricts the host language choices such as refcount over garbage collect (this is easier since Mojo is a new language and aim to have familiar syntax as Python).
Right, this is basically exactly what I was trying to say
I don’t know the details, since the project isn’t public
But everyone is thinking they ALREADY wrote a superset of Python. But what they appear to have done is
There’s a huge difference between those 2 things. I’m not saying they can’t do that, or won’t do that – I just want to know what it is, without being clouded by marketing. I have huge respect for accomplishments of the Modular team, but the way it was presented was pretty confusing.
(And this substack post certainly didn’t help with that!)
They have their own standard library implantation and their own compiler. It basically supports python language features plus some new syntax for new capabilities like static types
Yes, but the compiler and stdlib are not for Python – they’re for Mojo
Right now Mojo is a language that links with and talks to Python, and maybe some day will become something like a superset of Python
As mentioned, it doesn’t support classes. Think about how much of the Python standard library you can run without classes – basically zero.
it doesn’t support them yet
source
The goal is explicitly to become a superset of Python
Adding support for classes is on their roadmap
Having a Python compatible standard lib means you can run your Python code as is via mojo without changing it.
Some python libs would need to be ported over to mojo. If it becomes popular, I’m sure that all happen. If they keep the language and the tools open source, i think it would help become popular. We’ll see..
Btw I don’t think they will ever do #3 or #4. Mojo isn’t trying to be a better Python. It’s using python as a stepping stone because it’s a popular language, especially for ai/ml.
Yes, they have definitely got the attention. It seems promising, although in order to get the max performance we do need to step outside of the Python syntax and use Mojo’s extended syntax but that is the case in Python as well – you would write C/C++ or Cython code. The advantage here is that the same Mojo code will run on every hardware without any changes.
As far as monitization is concerned, I think Modular might leverage their platform such as the AI inference engine and other offerings. Mojo, they are going to opensource at some point.
In the last year I’ve really been focusing on R and Zig. R for classes & my grad research, hacking on my advisor’s R/C++ packages. I don’t particularly enjoy R, but I’ve become comfortable enough in it to (somewhat) read the insane incantations of veteran R statisticians. I’ve been learning Zig in an attempt to use it as a replacement for where I end up using C, and have recently started a compiler that uses Zig for small runtime components (similar to Roc). I find myself having a lot more fun in Zig than in C or C++, but Rust is still my go-to systems/low-level language.
Neither of those were my “latest” which goes to Mojo. I wrote a neural network from scratch a last year in Python, and I wanted to recreate it in Mojo to compare the languages. There were some issues I ran into, but I was able to get a small model working. Mojo caries over the mutable value semantics of Swift which I’m still trying to wrap my head around (the implicit copies were killing me before I added debug to every constructor I had).
As for “how did it changed the way you see programming”, I feel like every language has a bit to teach you. The compiler I started is for a language I’ve been designing for a while that takes inspiration from some of these and more. Zig’s comptime is incredibly eye opening in terms of what a language could provide for type manipulation. Mojo shows us a relatively simple language can achieve insane performance compared to standard C/C++ by utilizing better/different hardware and compiler architecture. R taught me…. well, I’m not sure what, but at least I can use ggplot well.
GradIEEEnt half decent was one of the most insane experiments I’ve seen!
Every entry by tom7 is fantastic.
that is even more cursed
I got curious about the implementation… I’ve been reading through the Vale blog posts for a while but it’s gonna take me a while to digest some of this!
It looks like generic functions can query the existence of function overloads? I think it’s like an anonymous trait impl lookup?
The implementation of
Option(Opt) is also interestingYour understanding is correct! These generics don’t require traits, they only require that a function exists for a certain type. It’s a nice way to decouple functions from data. They’re explained more here: https://verdagon.dev/blog/concept-functions
Also, that Tup is actually a casualty of the great generics endeavor. Before generics, it used to work like in https://verdagon.dev/blog/const-generics-spread and handle any number of elements. It’ll be fun to get that working in a post-generics world.
#!DeriveStructDropmeans “don’t automatically generate a drop function for this, I’ll be doing it myself”Some planned syntactic improvements that might be relevant:
where ~Tinstead ofwhere func drop(T)void#!DeriveStructDrop, so the automaticdropfunction is opt-in instead of opt-out.isEmptyfuncs, so that we can write the commonwhereclause once.Happy to clarify anything, and feel free to drop by the discord too! Lots of folks toss around questions in there.
I’ve been using discord heavily since 2015, and I’m fine with moving to standard usernames. If you put a gun to my head, I couldn’t tell you my discriminator, and I’m not sure that I knew it was called that before the announcement. It has always been a completely random number to me, and I have to open discord every time I want to share it with someone.
& from the linked tweet:
I 100% agree people should be able to opt out of user searching. There are already some good privacy options in place, such as disabling messages from people that aren’t friends with you. I don’t however think this change impacts harassment much, or at least I’d need to see some data to backup that claim.
What I’m failing to understand is how switching your discriminator from
jado#1234tojado#4321to avoid harassment is substantially different from switching@jado1234to@jado4321. They seem identical to me, but maybe the search feature could/would interact with this change differently.Additionally, impersonation is already a problem on discord, and I would say the discriminator system facilitates it because (ignoring Nitro) everyone has a random number. Prominent community members in one server will probably have a rank, but when they go to another server they look like every other member.
This can certainly be true, but I don’t think it’s guaranteed. Every time we push a user facing change that breaks some workflow, it is met with 1000 twitter replies saying “this new XYZ looks awesome” and 1000 replies saying “this new XYZ looks like trash”.
One aspect is massively psychological. A “discriminator” discriminates, visually, literally. You are not
jado1234. You arejado, the 1,234th. Nobody can take the identity ofjadoaway from you. Nobody is going to try and steal your Discord account because they’re upset they can’t bejadoor their new cryptocurrency scam isjadocoin. They can bejadotoo.(r.e. impersonation - you can’t impersonate someone’s discriminator, which is why people often stick with the same one. even between servers you’re still
jado#1234, people often persist with one tag for this consistency to avoid impersonation.)Could you elaborate on this? My understanding is that displaynames already don’t tell you anything about the user.
The Why Mojo? page describes their motivation a bit. There are some killer features here:
Once this is more mature, I can’t imagine I would choose Python for building ML models again.
There are some really cool results in here:
They’re matching GPT’s perplexity while being capable of a much larger sequence length. They also compared this to the recent RWKV which is another Transformer alternative, and they’re able to smoke everyone when the sequence length is > 30k (Table 4.2, page 10).