/λ/ - programming

Rust got a mascot? You always see it with that Fallout logo ripoff.

because it's still not a decent language.
everyone that thinks it's good are just going along with the fad.
"it's a popular new language so it must be good!"
enjoy your CoCk.

>>267
Fallout? It's a rusty gear.

>>270
When I saw this thread I was thinking to myself about how nice rustaceans are. Unlike you. Don't cut yourself on that edge now ya hear.

>>271
you don't even know what edge is, you're just mad I insulted your language.

the least a glitterboy like you can do is be honest.

enjoy your restrictions.
C/C++ is still better.

>>272
But does C/C++ have a cute mascot? I think not.

This is now a computing mascot thread. Say hi to Hy's very own Cuddles the cuttlefish! :3

>>274
Cuddles is cute, but why not start a Hy thread instead?

>>274
>tfw no ruby lisp
But seriously, why would anyone just not use Python instead.

>>276
>Ruby Lisp
Sounds like a project

But I like my friendly Python.

>>278
Rust's mascot would snip your snake in half!

>>270
>>271
>>272

Keep it civil..

>>274
I wanna cuddle that fish.
I think Hy's the only Lisp with a decent mascot.

Recently started writting a discord bot using the rust api. It's been annoying for me. Coming from a mostly C background it's uncomfortable finding myself in a language with so many abstractions. I'm never sure what exactly my code is doing.

I wanted an array of function pointers I could call from my parse commands routine, but wasn't sure how function pointers worked because I don't know what the hell a function even is in rust. After some searching and reading I reasoned that I needed a hashmap of function references, but when trying to add a hashmap element to a struct I was hit with a bunch of lifetime errors. I had read through the ownership sections in the books a few times, read through the lifetime section again, and still couldn't seem to organize this lifetime buisness in a way that satisfied the compiler. (not to mention it made my code ugly as FUCK) In the end I had to redesign the entire command parse routine around the fact that I couldn't have an array of function pointers.

This is my first project with rust. All in all the language looks really cool, but after more than a few incidents like this along with the fact that I feel as though the abstractions are obfuscating what the program is actually doing, I'm very frustrated and considering abandoning it.

>>284
Functions and closures are first class citizens in Rust so it would be possible to make an array of functions pointers. The only time it should be somewhat tricky if you're passing a reference to your function pointer. Perhaps looking at https://doc.rust-lang.org/book/first-edition/closures.html will help you.

Don't give up on Rust Lain!

Gonna be setting up a laptop purely to do rust development and dogfooding.

My goal is to contribute to making usable everyday tools written in rust.

Any cool rust project that you've seen lately?

Ruma.io is cool, I'm really excited for that.

The incremental rewrite of Firefox and tor in rust are incredibly lofty goals, but they have the blessings of each respective project.

RedoxOS is fucking cool looking (muh microkernel ❤)

Perceptia is a i3wm rewrite in rust (I believe it supports Wayland as well?)

I'm trying to get involved in back end dev at work having to do with SNMP and I've been keen on using rust for it, but we'll see.

As someone who likes FOSS and security but has little-to-no programming expertise but wants to eeventually learn Rust; should I go C > C++ > Rust or can I manage skipping C++?

>>504
You could probably start with Rust and then move to C/C++. It really just depends whether you prefer having to learn the harder language now or later, but in reality I don't think it matters as long as you have the drive to learn.

>>505
Why on earth would you start with Rust and then move to C? Start with C first because it's one of the simplest programming languages out there.

I would not recommend Rust to anyone who has very little programming experience. I know some people with a lot of experience with languages like Java who are seriously struggling with Rust. Knowledge of C++ may help, but it isn't the same as C++ so being too familiar with C++ may hurt because the typing is different in a lot of ways, even though it may sometimes look similar.
I would suggest diving into Rust if you have experience with C and, more importantly, functional languages like OCaml or Haskell.

I don't understand the lengths some people will go to to avoid Garbage Collection.

Yes, I get that there are are some domains that benefit from lack of GC pauses. But a huge amount of software being written in Rust doesn't need to be hard realtime, or memory-sipping, or anything fancy. So I don't get all the fanfare - other than that Mozilla has a lot of pull and it's very fashionable to use corporate-sponsored languages.

Why not use something with clean, elegant, beautiful code that you can understand at a glance, and never have to worry about lifetimes or fighting the compiler?

There can't be THAT many people doing embedded, hard-realtime code to warrant Rust's popularity.

I'm glad it exists but the all the collective energy focused into Rust seems pretty bizarre.

>>1559
some of the fastest web frameworks available are written in rust.

Post nice rust code and I'll think about it.

>>1560
Sure. And in the techempower benchmarks, Java either beats or is highly competitive with Rust every single time.

So is it really worth the extra cognitive overhead to get that performance? And if another GC'ed, compiled language had significant mindshare, could competitive frameworks exist in that languages as well?

I just don't yet see the evidence that Rust is immune from competition from smarter compilers / VMs / etc. Clearly the JVM is good enough to put Java ahead of Rust in some benchmarks, and there is still more optimization on the horizon for JVM languages.

If anything we're headed toward a future where "AI" (deep learning) will be the decisive factor in optimization, not humans manually keeping track of where everything is. We might come to the point where everything is written in a much higher level language than anything we're used to, and yet performance will rival or exceed anything that could be done by hand - perhaps by analyzing the entire corpus of code on github and figuring out the optimal implementation for a declaratively-specified outcome.

>>1562
>If anything we're headed toward a future where "AI" (deep learning) will be the decisive factor in optimization, not humans manually keeping track of where everything is. We might come to the point where everything is written in a much higher level language than anything we're used to, and yet performance will rival or exceed anything that could be done by hand - perhaps by analyzing the entire corpus of code on github and figuring out the optimal implementation for a declaratively-specified outcome.

Very very far future, maybe.

>>1562
How often do people actually use a sub-optimal algorithm that could be detected or fixed by scraping Github? I really doubt that it is a common occurrence. There are no optimal implementations of algorithms since their performance will depend on the typical input, for example you would write different code if you expected something to be run often on short inputs than if it is supposed to be run on huge inputs. The problem is that often the input can vary greatly. Another problem with performance is adjusting to the actual CPU that the code will run on, the costs of instructions can vary greatly even among closely related products and an instruction sequence that is blazing fast on most CPUs of a family can be disastrous on some others. Not to mention that some newer CPUs will have additional features that could improve performance but cannot be used on older CPUs.

Of course Rust does not address these problems.

>>1564
all of these can be addressed by a suitibly advanced JIT compiler(like java), probably better than a AOT compiler.

HOWEVER: getting rid of null pointer exceptions is good enough reason to have a fancy ass type system like rust.

I also think rust is really good and intuitive to write once you get used to the BC.

>>503 (2017)
>rewriting Tor in Rust
I think this has now been largely accepted as a mistake by the people involved.
https://hooktube.com/watch?v=_CdQHfLhmvI

>>276
>But seriously, why would anyone just not use Python instead.
Some people find Python's syntax to be brittle, inconsistent and functionally crippling (e.g. lambdas), so a small library that translates Lisp syntax into Python AST is extremely nice. It is important to remember that it's just a thin wrapper though, e.g. code that looks like it should be tail recursive will explode because the limitations of Python still apply.

>>266
>Why are you not using language with the best mascot?
The main thing I have against Rust is how Cargo and the Crate ecosystem operates. When you create a new Rust project the first thing Cargo does is phone home and pull down a thousand random dependencies behind your back. And then you can't even start a new project with the exact same dependencies offline. Cargo has to phone home again, update random things, download more random things. It feels like you have no control over your own project, everything has to be tightly integrated with the Cloud Overlords. I hate that soykaf. Its the exact opposite of what freedom and open source should be about.
https://github.com/rust-lang/cargo/issues/5655

>>1559
>There can't be THAT many people doing embedded, hard-realtime code to warrant Rust's popularity.
Rust is not at all suitable for embedded projects because the binary sizes are astronomical and only supports LLVM targets, there are tons of basic things missing from the language (see link) and the language doesn't actually offer very much over plain C when half your genuine low level code winds up being a giant `unsafe` block anyway.
https://blog.japaric.io/embedded-rust-in-2018/
https://jamesmunns.com/blog/tinyrocket/

Rust is not suitable for (hard-)realtime systems either.
For one thing you actually need to write code with consistent performance guarantees, it's not just a matter of saying there's no garbage collector therefor it's real time.
https://github.com/rust-lang/rust/issues/7462
https://github.com/rust-lang/rust/issues/52529

More importantly though, "hard" means Bad Things happen when the code misses a deadline, like an airplane will crash and kill everyone. You need verified and certifiable language and toolchain like Ada or CompCert C, not some trendy unstable meme-language from web weenies LARPing as "low level coders".
Rust might get there some day, but not at all soon. https://ferrous-systems.com/blog/sealed-rust-the-pitch/

>>1601
how old are you?

>>1606
>how old are you?
What are you getting at?

>>1607
>What are you getting at?
Caring about my languages working offline and actually writing low level C for a living makes me old apparently.

>>1611
Haha, I can relate to that. I have to write in the latest meme language (Go) and it is killing me inside. I'd rather be writing C++, or even plain C. And the ironic part of it all is that we are writing a piece of software that has high-performance requirements, so Go is not even very suitable for the project.

>>1612

Concurrency in Go is pretty well designed, and allows for some pretty high performance computing. I use it at my work doing transaction processing and we do have large portions of our processing backend written in it. A lot of the stuff there is written in C as well but they definitely each have their tradeoffs.

>>1613
See the C++ thread. It's really not as performant as they make it out to be. Of course, for many applications, it's good enough, but it's nowhere near where it could be.

>>1601
>I think this has now been largely accepted as a mistake by the people involved.
What makes you say that? The talk you posted seems fairly positive.

>The main thing I have against Rust is how Cargo and the Crate ecosystem operates.
I don't really understand this complaint, because as far as I can tell having tools like Cargo just give you more options. You don't need to use Cargo to use Rust, (a Makefile which runs rustc would work fine), but it's popular because automatic dependency resolution is more convenient for most programmers.

>When you create a new Rust project the first thing Cargo does is phone home
That's simply not true. Try it.

>It feels like you have no control over your own project, everything has to be tightly integrated with the Cloud Overlords. I hate that soykaf. Its the exact opposite of what freedom and open source should be about.
I feel like you're misunderstanding what Cargo does. "Cloud Overloads" implies that Cargo's behavior is somehow dictated by someone else, and that it's outside of your control. Cargo's documentation not as clear as it should be, but it is ultimately still just a tool under your control. If you ask it to use a remote resource, then it will go and fetch that resource. If it's hitting crates.io then that's because you've asked it to and didn't tell it not to.

>the language doesn't actually offer very much over plain C when half your genuine low level code winds up being a giant `unsafe` block anyway.
That's not how "unsafe" works. The whole point of unsafe is to build a safe interface over otherwise-unsafe operations, so if your application logic ends up in a giant unsafe block you're using unsafe wrong.

>not some trendy unstable meme-language from web weenies LARPing as "low level coders".
Now you're just being rude.

>>1613
Go's concurrency is quite useful for more mundane tasks as well. I've been replacing a lot of Excel/Access stuff for my small-business employer with Go-backend web apps. It's stuff like scheduling shop workers, time/material sheet data-entry, tracking cost statistics over time, etc. I love Go's excellent concurrency handling for stopping data races before they happen. Plus, it was fun to show the boss how fast it all is. Our pretty-damn-fast CAD workstations just chugged on some of the old crusty Excel/Access VBA crap we had. The Go stuff I've built screams on a cheap little Intel NUC.

I never understood some of the hate that Go gets. Sure, it's not a one-size-fits-all language - someone would have to be mental to write a kernel in it. But it's a fantastic web app language. I love being able to jettison both PHP and nginx from my life entirely, and dramatically lessen how much I need to do in javascript.

>>1730
>The Go stuff I've built screams on a cheap little Intel NUC.
What did you mean with "scream"?

>>1741
I mean that it runs fast.