Hacker Newsnew | past | comments | ask | show | jobs | submit | nirui's commentslogin

Qwen is still controlled by Alibaba, one company. We can't let the future be in the hands of a few companies, can we?

Fun fact: Qwen was not initially a Apache Licensed project, it was based on a custom license from Alibaba that restricts commercial use: https://github.com/QwenLM/Qwen/blob/ba2d85a13b28ed1ee0dde2d6.... There's no guarantee that they won't just switch it back later.

Kudos for them for switching to Apache License, of course. BUT, they're still a for-profit company. So as DeepSeek btw.


> we have no reason to believe their statements about risks are insincere

Why? Because they said it a few times? Then if they know the risk, why do they still making it? Comes out the "some one will do it eventually, better be us 'good' people to do it first" talking point?

See? It is a marketing strategy after all. These all talks, it's all to fit themselves into the "'good' people" narrative. It's a centuries old strategy to shield it's user from responsibilities while luring the support from the stupid.

However, the most harmful damage, which is mass layoffs, is already partially done. This could really kill, a massive genocide even, by making people jobless and potentially incomeless. And it is shown that these tech CEOs, they don't care any bit of that beyond the point "I've already told you so".


> Speaks volumes to the strengths of the language

Memory safety is just a tiny part of over all security. If a LLM can transcode correctly, then it should also output 100% correct C code.

On the other hand, If a LLM cannot correctly transcode, then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.


> Memory safety is just a tiny part of over all security.

No, it's a pretty massive part with disproportionate severity.

> If a LLM can transcode correctly, then it should also output 100% correct C code.

Translating code seems to largely rely on having a strong suite of existing tests, not on ability to code correctly.

It's unclear if LLMs are great at writing safe C code, it's much clearer that they can meet targets with external feedback properties like "test passes/fails".

> On the other hand, If a LLM cannot correctly transcode, then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.

This is very unclear to me.


> Memory safety is just a tiny part of over all security.

70%[1][2] is tiny?

[1]: https://www.zdnet.com/article/microsoft-70-percent-of-all-se... [2]: https://www.chromium.org/Home/chromium-security/memory-safet...

> On the other hand, If a LLM cannot correctly transcode, then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.

Isn't it the other way around? Rust guarantees lack of undefined behavior in safe code. If you have undefined behavior in your code your bug might become a heisenbug, or make the rest of your program behave weird, or the bug might simply be dormant until a very specific situation occurs (i.e. be "soundless" as you say).

If you're going to automatically translate your code from one language to another then a memory-safe target language (whether it's Rust, Java, C# or something else) is the only sane, reasonable choice. And if you want C or C++-like performance (i.e. you want to maximize performance) then you're pretty much left with Rust on the table.


> If you have undefined behavior in your code your bug might become a heisenbug

OR, the OS might kick in and throw a segmentation fault etc, often with some information associated to it.

Again, if a LLM can output 100% correct code, no bug of whatever kind should exist. Seeing a segfault could just invalidate that assumption completely and definitively. That's the point.

> Rust guarantees lack of undefined behavior in safe code

And that don't guarantee heisenbug-free, that just means your heisenbug was fully checked by Rust compiler and is now managed by the language runtime/facilities.

So, now instead of a crashed program and a "sever" DoS vulnerably, you got a disconnected user every time they trigger the bug. The user might assume it's the network, so does your logging stack. After a few times, the user starts bitching about your stupid network, and left for your competitor's product, while you busily trying to figure out why the network suddenly ain't as good as it used to.

> 70%[1][2] is tiny?

It really depends on how they define what counts as "vulnerably", or in Chrome's case, "'high severity' security bugs" which is very specific. Microsoft probably have many decades-old code written before the invention of better checkers, that contributed to the problem.


> Memory safety is just a tiny part of over all security

Sure, in the same way that foundations are just a tiny part of house construction.

Foundations come first, it's great if you've got more on top, I recommend it actually, but if you don't have the foundations it's not even worth having the discussion about what else you built, it's all worthless.


But current LLMs have a context window limitation, so you can't fit your whole source code into the context, that's why compilers guide the LLMs when they are producing code and that's where Rust compiler shines, it has very good diagnostics that help fix the issues with a few iterations.

So while LLMs are good at writing walls of code, they do not produce good code, just good enough and sometimes it is wrong (here is where Rust can help a bit by checking that the program is sound, but for the most part you should also validate the logic).

The dream language for LLMs would be one that has some kind of proving that function inputs/outputs are what you expect (I think it's called proof theory, but it's not my area of expertise, so I could be wrong), you kind of can emulate this with new types[0].

[0] https://doc.rust-lang.org/rust-by-example/generics/new_types...


> If a LLM can transcode correctly, then it should also output 100% correct C code.

Well LLM's cannot transcode perfectly correctly, so the fact that Rust has lots of static checking is really important. Not just for memory safety - Rust helps with many other classes of bugs too.

> then using Rust may just make the bug soundless, because the language runtime/code-gen "avoided" usual punishments that might make the bug (and bug report) obvious.

I think what you're saying here is that LLM's often cheat to solve the immediate error, e.g. by using `unsafe` where you really shouldn't, or just making a test not test anything. That's definitely possible.


> If a LLM can transcode correctly, then it should also output 100% correct C code

An LLM can't (currently) transcode correctly in a vacuum. It needs tight guardrails to keep it on the straight-and-narrow (such as an existing conformance test suite that is extremely comprehensive).

The value of transcoding to Rust specifically is that the compiler gives you a pretty substantial set of guardrails "for free" - in a C port, your conformance test suite would also need to test every aspect of memory safety and fearless concurrency...


Pity. I recently started a fun activity to rebrush my math my where I tries to solve problems while asking Gemini Live mode for confirmation and suggestions, sometimes step by step.

It kinda was fun, like a very patient professor stand right besides you. It was the one of the best math learning experience I've ever had, and you don't even need to send bribe/gift to Gemini to keep you in it's favor.

On the other hand, if you ask a LLM to completely finish the work without thinking it through by yourself, then it sounded like cheating, to yourself.


The most disappointing part is not the price alone, it's that despite the price increase, the quality of the modules are still the same or even worsened.

> and then abscond to China

I'm a Chinese, from what I learned, you probably don't see the situation clearly.

The problem is influence. America wants to solve the Cuba (and Iran) problem since very long ago, and right now, while China is busy patching up their economic slop/mismanagement and Russia is trapped in Ukraine, is simply the best time to do so.

With Cuba is cleared out, the Americas continent will be cleared of major (and loud) threats against America. That alone is beneficial.

It's the same but opposite reason why America is supporting Japan, Taiwan and Europe etc, to control the influence of their competitors like China, Russia, India, Brazil etc (a.k.a Global South). It also allow Americans to keep a tap on Japan, Taiwan and Europe (etc) so they remains in American control.

That's probably the 4-D chess you talked about.

Also, the "Trump the 'Nation Builder'" part: In China, "Nation Builder" was a popular forename, it means "someone who contributes to their own country/nation". In the Trump context, it means that Trump's policies is benefiting China's goal. That is, when compare to Biden's policy which is much sophisticated and on point (while Trump's is blunt and wasteful).

But I don't think American's soft gesture towards China will last after Cuba and Iran is dealt with (if) in a American victory though. Unlike what the "New World Order" conspiracy suggests, I don't think this world is stupid enough to not to pursue the maximums goal when possible. That's probably why Americans are working towards the maximums goal inches by inches.


There is no "Cuba problem" that needs to be solved.


How many cuban ex-pats do you know? I would say “not many”.

Every cuban ex-pat I know (and thats quite a lot because I live in FL) will tell you there is a Cuba problem. They all still have family suffering under that regime.


Let me rephrase. The is no "Cuba problem" that the US needs to deal with any differently than it deals with/has dealt with the many other countries in the Americas that have/had people suffering under their regimes who had family in the US.

As far as Cuba in particular goes, the suffering there would be a lot less if the US would drop its 65+ year old embargo and let them trade like all the other repressive regimes it is indifferent to.


Most of them don't have a history of direct hostility towards the US and specifically having the willingness to allow a US foe to use their proximity to plant tactical weapons to threaten the US.

Bit of a difference…


That was in 1962, nearly 44 years ago, and it was after the US had tried to invade Cuba.

Castro was already playing footsie with the Soviets and Castro nationalizing US business interests was one of the reasons we decided to invade.

That was 64 years ago and are you suggesting here that things that happened that far back have no bearing today? Hell, the brother of the dictator from 64 years ago is currently in charge there today still oppressing the Cuban people so it’s not like there hasn't been some continuity.


From my G^7P comment: "settle decades old vendettas held by aging boomers"

Taiwan. That’s the reason these little low value wars and erosion of soft power are ill timed, ill considered and ultimately supremely destructive to our relevance and influence in the world.

But, good news for China!


> Weaponizing Bureaucracy

Don't over interpret this. You can also weaponize efficiency too, just like what USSR did to itself, hyper optimizing their industrial sector and leaving everything else to a free dry.

Truth is, keep something alive is just hard. It dies if you overdo, and it also dies if you underdo. A sabotage could just tip the balance, that's all.


> It confuses easiness with simplicity

A lot of libs/packages in Go's stdlib also has this problem. They like to package everything in a very tight interface (very obvious example includes crypto/* and http), without exposing implementation detail to the end user.

Doing this of course has it's benefits, but if the feature provided by the stdlib slightly don't fit you needs, then you might have to write your own (potentially unsafe and/or less performant) one from zero.

Rust is great overall, but there's some oddities. For example their lib.rs / `mod` is very, very unintuitive, it felt overdesigned and unnecessarily complex (just see [their book]). I like what Go or Java did to their lib/package systems, it's much better that way.

[their book]: https://doc.rust-lang.org/stable/book/ch07-05-separating-mod...


I've come to hate hiding internals. Put them in a namespace which makes it clear there's no API stability guarantees, but make them available if needed.

As you note it's just pain with no gain to properly hide them. Users can't readily work around bugs or extend functionality.


Sometimes hiding internals is reasonable, but it could cause inconvenient. Exposing everything could make it harder to do interface management etc.

It's really a system design problem rather than access control: if you separate functional modules in a reasonable way, then it can be better reused.


Only if you use a backwards language with non-existing namespaces. I don't see how it changes anything if you have namespaces. After all, private/protected/public are just namespaces, they are just implicit rather than explicit.


If I remember it correctly, the "Java-lite" part comes rather late. PHP was more close to Perl and/or other old-days scripting language, it allows you to quickly launch a web page. Just

    <p><?php echo(htmlspecialchars($_GET['user'])); ?></p>
and you get a hello page with a parameter specifiable via `?user=` query.

But then people started to actually use it to build big sites, `echo($_GET['user'])` alone is not enough, it has to be:

    <?php
    $user = "guest";
    if (!empty($_GET['user'])) { // Have to remember to do this check everytime when handling $_GET/$_POST etc
        ... safety check etc etc
        $user = htmlspecialchars($_GET['user'], ...more parameters...);
    }
    ...
So people started to add module/components as well as ways to load and use those components, to enable them to write code like:

   <?php

   use My\Beautiful\InputFilter;
   use My\Beautiful\InputFilters\Integer;

   function get_page_num_from_query(InputFilter $f, array $source, string $name): bool {
     return $f->is_valid(new Integer(0, 100), $source, $name);
   } // Or something like that, hasn't write a single line since PHP5.
That's when it got it's Java look.


>That's when it got it's Java look.

Nice Java burn! But now days all you have to say to burn Java is "Lawnmower".


Namespaces were added long after that step.


> We can stop reading LLM-generated code just like we don’t read assembly, or bytecode, or transpiled JavaScript; our high-level language source would now be another form of machine code.

My opinion is very close to this. Currently the reason that it's bad to not reviewing/testing the code LLMs generated is because the LLMs can sometime generate bad codes. But it's a bug that can be improved. One day you'll have LLMs generating code consistently better than what a human could write. And then you just stop needing to review them. (And that's probably also the time where most programmers/developers got fired too)

Don't get surprised if anyday the LLMs starts to generate binaries directly. THAT will be impossible to read and costs more time to analyze.


> Currently the reason that it's bad to not reviewing/testing the code LLMs generated is that the LLMs can sometime generate bad codes.

Sometimes?

I am heavily into vibe coding and I think they almost always generate bad code. At least as soon as you're distant enough from the code to call it vibe coding.

When you're still in touch with the code, have at least been recently talking to it about code rather than 100% about features, and its context is filled with good code, it can generate good code.


Is it possible to reason or prove the correctness of an LLM?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: