141–150 of 244 posts
It would be nice if there was more meat on the article though, like what types of things to do, or how each memory error happens, etc.
Nowhere does it call out Rust by name. Go / Zig / Pony / Haskell are all valid contenders.
Pony isn't that well known, here's their home page, for the curious. [0] I remember a recent HN comment said that if you create a website for your new programming language, you should always ensure there's a meaningful example right there on the landing page. A pity that Pony's page fails to do this. Here's one of their example programs. [1] [0] https://www.ponylang.io/ [1] https://github.com/ponylang/ponyc/blob/main…
It seems like it's best grouped together with Go, Erlang, Elixir, and Crystal.
Earlier quoted context omitted.
Your missing what the two parent comments are driving at. Google says that's what it is doing, but this money is going to "an organization" that will seemingly get it's money from Google, giving Google control over whatever open source projects they target.
> control over whatever open source projects they target. but if they rewrite the project in rust, why _shouldn't_ they control that project? If other people choose to switch, then it's not wrong for them to move, and not wrong for to google gain control of those users. The original project maintainers is a third party to this whole process, and i would argue, is uninvolved tbh. It is up to the users of the project t…
If the rewritten project gets more successful than the original (perhaps due to corporate promotion), you have morally stolen the work of the original authors.
If you write a project from scratch without looking, this of course does not apply. But I doubt that is how Rust rewrites actually happen, the temptation is too great.
Nowhere does it call out Rust by name. Go / Zig / Pony / Haskell are all valid contenders.
I suppose D would also fall into this category. Although I find it interesting that Common Lisp gets left off these lists. It's memory-safe (with GC of course), has great integration with existing C libraries via CFFI, has a formal spec, has a solid library ecosystem, supports a "mostly-functional-but-imperative-if-you-need-it" programming style, has optional/gradual compile-time type checking, and at least one open/…
Nowhere does it call out Rust by name. Go / Zig / Pony / Haskell are all valid contenders.
Go, Pony and Haskell all have complex runtimes and a GC, which makes them unsuitable for embedding into other applications or exposing them as widely usable libraries. Rust, Zig, and to a certain extent D or Nim without GC, can easily expose a C API and have a minimal runtime. But the others do not provide the same guarantees as (safe) Rust with the borrow checker. All very cool languages in their own right, but memo…
it's truly superior to any other programming language (5+ years of pro experience talking), so why waste my time with the manual labor of imperative programming?
Earlier quoted context omitted.
> control over whatever open source projects they target. but if they rewrite the project in rust, why _shouldn't_ they control that project? If other people choose to switch, then it's not wrong for them to move, and not wrong for to google gain control of those users. The original project maintainers is a third party to this whole process, and i would argue, is uninvolved tbh. It is up to the users of the project t…
If you translate an existing project into Rust, it is a derivative work and should retain the original license. If the rewritten project gets more successful than the original (perhaps due to corporate promotion), you have morally stolen the work of the original authors. If you write a project from scratch without looking, this of course does not apply. But I doubt that is how Rust rewrites actually happen, the tempt…
By this logic, WINE is a derivative of Windows and should retain their license.
It's buried in there, but it doesn't specifically say Rust: > That’s why we’re expanding our collaboration with the Internet Security Research Group to support the reimplementation of critical open-source software in memory-safe languages.
Nowhere does it call out Rust by name. Go / Zig / Pony / Haskell are all valid contenders.
Rewriting the world in Rust or other "memory safe" languages is not going to be the silver bullet that is being claimed. In the case of Rust, I am tired of people evangelizing it when it's plagued with issues that undermine its goals and rewrites will bring about more nasty bugs. "Unsafe" code will still need to be written and not being able to use or have stable toolchains to work with is a non-starter for a lot of projects. Until all of these languages have set standards and stable toolchains, hopefully the Rust Foundation will push, these languages are a non-starter.