GLM does seem to have security related safeguards but they revolve around just confirming whether or not you own the system being operated on. As soon as that check is cleared, it will do anything.
Someone who isn’t me tried using GLM to crack some software, it wouldn’t comply. They had to use the abliterated version. I wonder how much of the Chinese models’ safeguards are a result of distillation, versus intentionally implemented safeguards.
It will conform if you are deeper down the context. Just use abliterated/another model for a first few thousand tokens. Or call the directory CTF and don't leave that much trace about what are you reverse engineering around that will see through your tricks.
what's the value of that when you can call it with any context? As a proof of concept, you could have it do the attack on a dummy target of your own, take the tokens up until the point where it decides you're authorised, swap out the dummy name with your desired target, and continue the session from there
Reminds me of 'NOBUS', where security agencies would believe that so long as you just don't tell anyone about a vulnerability that you discovered or introduced, nobody else would abuse that vulnerability to exploit a target while you can get access at any time. Training an LLM in such a way that it only generates the desired tokens if its memory demonstrates authorisation (surely nobody else could inject the right context otherwise) feels like a strange anthropomorphisation
Its a protection for the person who deploys the model and controls the context against some exploits, on the expectation that that operator will take steps to prevent large scale context manipulation.
It is not a protection for society against the person deploying the model.
I think this is just an in-progress shift caused by new technology. Whether it's "good" or "bad" is a separate concern. It looks a lot like how bullying got worse with phones + social media, or how food mass-production results in lots of unhealthy food that people are addicted to. There are a lot of activities we have that are self-limiting, where once we figure out how to remove the limits, there are some negative consequences. Either it will balance out in time (with much pain) or we will just go extinct.
Let's all remember we can return to primitive living at any time. If you don't like the brutality of the rat race, there are many societies out there that just don't play this game. Personally I suspect those societies are also on the brutal side. I'm not sure if we've ever had a truly comfortable existence. Maybe in some brief pockets of recent history. But it's the same human motivation that both drives us to the comfortable times, and brings us back to chaos.
Right - I think a lot of folks who thought they were in it for the joy of programming are realizing that actually it was about the outcome after all. Maybe causes a bit of an existential crisis - you thought you liked programming, but now that there's no money or recognition in it anymore, not so much.
Go is the best because it has a pretty fast runtime, very fast compile time, rich ecosystem, and is simple to deploy.
Fight me. As a classical software engineer, I hate Go, but in this new era it wins so easily. For web, at least. The subjective stuff about how the language feels is all out the window now.
All those things are true of Java/Kotlin, except even moreso. So LLMs should all write Java.
There's no good way to resolve these kinds of debates. I don't think AI changes much. It thinks in the same sorts of ways we do, just faster, so things humans find hard or unproductive can also be hard and unproductive for AI too. There are a few exceptions where it's able to reason fast enough that things which would be dumb for humans (like reading raw assembly or bytecode) are no big deal for AI. But mostly it's the same.
> All those things are true of Java/Kotlin, except even moreso.
The parent did mention:
> ...and is simple to deploy.
Also, my experience with Java programs is that the memory overhead is even higher than Go (where it's a ~2x of what the program holds as heap due to the GOGC=100 default).
It's not harder to deploy in my experience. When people say this they tend to imagine deployment as "scp binary user@host". Well,
./gradlew installDist # build the app for deployment
rsync -avz --delete build/install/my-app/ user@host:my-app/
Just repeat to upload new versions. rsync vs scp isn't harder and the Java version will be faster (incremental). If the host doesn't have a JVM installed, ok... apt-get install one and your distro will keep it up to date. One command.
But in reality most software isn't deployed by copying binaries around. You'd want it to be at minimum run by systemd or kubernetes, for example. And if you want a Docker container then it's pretty easy. Your framework probably configures it out of the box:
./gradlew dockerBuild
Push to the host and start it up.
The reason it's not harder in the end is that the above takes cares of many annoying details that crop up in real deployment, like knowing what CPU and CPU extensions does the host have? Can you deploy incrementally without recopying the whole thing or does that not matter?
The above is for servers, but it's not really harder for CLI tools either. Fat JARs exist. If the user doesn't have a JVM, once again, they can install one easily from their package manager and then it's done - no need to create and distribute half a dozen binaries for all the different OS and CPU combinations that are out there.
But if you want to make AOT compiled binaries and get lower memory usage too, there is GraalVM which can do both. You've got the choice.
Note how the above debate isn't changed by AI in any way. Their weaknesses remain weaknesses, their strengths remain strengths. I wouldn't personally use Go because of its poor feature set and debugging support (errors don't reliably create stack traces). But the arrival of LLMs changes nothing about these preferences and choices. At most you can talk about token efficiency, in theory, but the attempts to measure the real world impact of that don't seem to have yielded decisive evidence.
> And compared to Go, the production observability is very good.
Can you give some examples where Go is lacking and Java is great? (Ideally builtin things, and if not builtin, then things where Go doesn't have an externally developed alternative).
> I also use Clojure and can observe my running app with a full REPL.
Does this work with other JVM languages, like Java, too?
Clojure can to some extent help you get a full/true REPL into Java and any JVM language, but only to some extent. You'll have to use Clojure to get the full observability and program runtime-mutability.
> There's no good way to resolve these kinds of debates
This debate in particular is easy to resolve: there is no “best“ language for all use cases and I agree LLMs have not changed that. The best language for a scenario depends entirely on the scenario, so talking about best languages without a scenario in mind is completely the wrong discussion.
Absolutely agree. "Best"? Best for what? For writing programs? But what kind of programs? "General programming".
I've never written a general program in my life. I've written a bunch of specific ones, though. What I care about is which language is best for writing this specific program. Why do I care about which language is best at writing a program that I'm not trying to write?
I'm making a galaxy civilization simulation using go-lang and it is sooo fast to compile and run, even on many iterations of the simulation, and I have 0 dependencies on risky 3rd party libraries etc.
As a quite well seasoned software engineer working many years with Java, C#, PHP etc. both in complex calculation systems and webservices, go-lang just feels superior in so many aspects. While I might still fare better in say Java is purely a function of me spending much more time in it.
So I see your point in myself and agree and agree. (I just don't hate go, I think we need to give it a chance)
No. I’m sick of flame wars, and I already was before LLMs turned everyone even more insufferable. You can fight yourself in your own corner, if you like. Never thought I’d miss emacs VS vim.
Use whatever language you want, I couldn’t give less of a shit. I have no desire to waste time on a dick-measuring competition, and that’s doubly true because people in these fights are measuring other people’s dicks.
> As a classical software engineer, (…) The subjective stuff about how the language feels is all out the window now.
Subjective stuff never mattered to people who take no pride in doing proper work. That hasn’t changed because of LLMs, it only shone a brighter light on those people.
But it hasn’t changed. That’s the whole point of the comment. We’re still at the same flamewars and (lack of) care as before. We’re just doing more of it at a larger scale.
I do agree the comment came off strong and for that I apologise to the person above. I meant to make a general criticism, not condemn any particular individual.
AI + smaller docker images made me look at it again.
The fact I can test/build concurrently and much faster than rust, off the same repo without messing with sccache and worktrees, make it easily the winner for many web/self-contained scenarios.
I can imagine that for web dev. But as someone doing numerical physics simulations, would you really recommend Go over either C/C++/Fortran for low-level, Python for high-level, or Julia I guess for both categories?
Unless you are doing very low level C++ manual memory optimization, I would recommend using Go for both: it's on the same scale of magnitude of speed as C/C++/Fortran but the compile time is crazy fast that prototyping in a high-level scripting language like Python really isn't that necessary.
You also get very easy parallelism in Goroutines, excellent ecosystem, and one of the best performance profilers in any programming language, pprof.
Interesting. Parallelism and profiling are both strong selling points.
I’ve done pretty low-level C++ and Fortran in the past, but these days I’m honestly mostly used Python with either NumPy or CuPy for calculations, so not very low-level at all. My code is pretty performance-sensitive though, so unless the main operations can be framed neatly in terms of NumPy or CuPy primitives, one had to drop down to low level.
Do you know how the Go library support is for typical scientific computing stuff, e.g. matrix diagonalization, sparse matrices, or handing off such calculations to CUDA (or other GPU frameworks)? Is there a strong numerics community in Go these days, or would you have to implement most of what you need yourself?
For sparse, I think the best is still Intel's sparse libraries for MKL on CPU, it's just not a workload that runs well on GPU compared to dense SGEMM. You can call it via CGo.
For GPU offloading, there should be a decent amount of CUDA bindings available for Go right now, but I'm not as familiar in that front since I'm building my own GPU compute runtime in Vulkan, but it's still very much an experimental work in progress right now.
Thanks for the pointers, appreciate it and will look into it!
Yeah, my understanding is also that working with sparse matrices inherently requires heavy branching, which translates badly to GPU. I usually do everything I can via dense matrices via CUDA, but switch to sparse matrices on CPU if I run out of VRAM…
I've written plenty of C++ for embedded systems, and very little Go, but if I find anyone trying to connect C++ to the web I will try to get them fired for cybersecurity violations.
Go is close enough on runtime for all reasonable purposes.
If you statically link C/C++, you lose access to vDSO by default. Syscalls like clock_gettime incur normal syscall overhead. You can still retrieve vDSO at runtime like Go does, but that's something you have to do yourself in C/C++.
Java has an extremely fast runtime and rich ecosystem. If we're going to never look at code and let AI handle it all (not sure I agree, but let's assume), then Java is the obvious best choice.
Java has a slow iteration time - long compilation and slow startup. Common frameworks add even more time before the program does anything useful. A fairly complex Go web backend can recompile and completely start in under a second. A relatively simple Java backed can take more than ten seconds.
Only if you holding it wrong, write the same stuff in Java like in Go, without frameworks, all by hand and you will get your second.
Even better don't throw away the frameworks, learn to use JIT caches and hot code reloading tools, and you can even debug, edit and continue from the comfort of an IDE, doing several useful actions.
I wont argue that Go is the best. I will however argue how nice it is to be able to have extremely minimal distroless containers thanks to static Go compiled binaries.
reply