How do we feel about rust today?

How do we feel about rust today?

Other urls found in this thread:

nim-lang.org/
twitter.com/SFWRedditImages

Meh.

It's a reasonably nice language that failed to have a strong finish. It's neither good enough to be a C replacement nor good enough for high level "apps" programming. A language that has the features of Rust but with some kind of automatic memory management (some kind of GC) would be good for the second one.

You try it out side of fizz buzz yet?

Wrote a 3000 line project in it. I really like it. The borrow checker concept is amazing. The type system has blown my mind a couple of times.

All sorts of people are making user land applications with rust. Two of the highest ranking github repos for rust trending are a text editor app for Mac and a gui systemd manager for linux.

Sure. All sorts of people are writing their apps in C. Doesn't mean that C is a good language for writing apps. Rust is an alright language for writing programs, I know because I've written many of them. But for most programs Rust+GC would be even better.

Decided to at least try writing my Restful API using Rust, its really looking like the best general purpose language these days, the memory safety is what we should have had about a decade ago but meh it's here now at least

Seems to be a reasonable language for certain stuff, but it takes at least ten years for a language to mature and and there may be too much friction for many usage domains.

You can literally use any GC language to write your dumb FizzBuzz HTTP API with and get the same """safety"""

I know you faget, its just that I'm curious to try the nice features of Rust that don't seem to be available in other languages because only Mozilla are non-niggers.

Those features for the most parts aren't interesting for wepp epps.

Are you talking about the half-assed FP?

Is it half assed though? But no that's not all, the main draw is the safety, I couldn't give too many fucks about FP but having a server (or anything software-related) that is harder to attack is an instant win for most people

>GC
Golang

So Nim nim-lang.org/

> It's neither good enough to be a C replacement nor good enough for high level "apps" programming.

Mostly this. When Rust was in the making, there was a crucial time in which they had to decide if they wanted to include GC or not. No GC nowdays is like a suicide for new programmers, but they wanted to appeal the c++ audience.

So, they decided to remove GC, but in order to advertise the language they started making noise about how unsafe the world is.

Dealing with pointers is always going to be unsafe, so people just stay with c++. And nowdays even videogames are being done with c#. There is little space for full safety in unsafe land.

>a to-C compiler that leaks semantics
At least Vala has a good enough reason.

Those languages don't have the features rust provides.

>It's neither good enough to be a C replacement
Why not?

>And nowdays even videogames are being done with c#.
Let's not imply it's fast enough to implement actually whole demanding games.

What Unity does, aka the faggot version of scripting where you discover that, once you control a somewhat bigger number of objects on the screen you need a C++ plugin doesn't count. And I don't even think that's the VMs fault but binding is too costly.

It's too bloated, not portable, not standardized (not even trying), and doesn't support the C compilation model.

Except for the first point, literally none of what you just said is true. It runs on microcontrollers. I just don't see the point.

More than enough for indie dev.

Is it really worth 19.99?

Java runs on microcontrollers.

That's not such a high bar.

Your point?
It's bloated, but portable, standardized and does support the C compilation model as well.

why not? How many people make games for an AAA company compared to those that do games independently?

>Rust+GC would be even better.
So, Haskell with state?
OCaml with a type classes?
C++ with a GC?
F# without microsoft?

No.

What exactly does "Rust+GC" look like?
Nearly half the entire point of rust is avoiding the GC through a complex lifetime / ownership model.
The other half is just sticking functional programming concepts into a language that vaguely looks like C.

The point is, you want to aim for the high bar, not for the worse-is-better, Wordpress, Unity, Node.JS-PHP-Perl-Python stdlib it-somehow-works bar.

You'd probably still have regions to handle threads and help creating stuff like region based flame graphs n shit.

Rust+GC allows you to use GC where you'd use reference counting nowadays.

But that's unfair. Using python/lua would be the equivalent for using PHP. C# is quite fast, is more than enough. Isn't terraria a good example of indie gaming?

So that's what you wanted all along? Cyclical references? Are you serious?

>Isn't terraria a good example of indie gaming?
Sure, but if you were about to create a language or game engine and you didn't plan to make it GameMaker clone no 9769 you wouldn't want restrict it to such games.

Also, imagine Terraria would also run on your 1ghz first gen atom laptop or consume much less energy than now so you could play it like 5 hours in train or something.

Best language ever made. Almost perfect. If only it weren't for the coc, I'd use it and nothing else. Unfortunately, since it has a coc, I'm avoiding the communities as much as possible, which makes it a bit hard to use. Thankfully, pretty much every rust software is dual-licensed apache2/mit so you can just fork everything and remove any reference to any coc if that becomes an issue.

>too bloated
Literally how? It doesn't even need a runtime, unlike e.g. C++, which is the go-to choice in all modern embedded and low-level work.
>not portable
It runs on pretty much every architecture because of llvm.
>not standardized
(You)
>and doesn't support the C compilation model.
Not sure if lobotomized or inbred.

I have to agree with another user, terraria has insane system requirements for what it does.

I find most indy games lately have just asshole blasting requirements for shitty bit art graphics.

It's not half-assed at all, actually. It's true first-class support. Although the way they implemented closures was using anonymous traits, and I don't know how heavy-weight this approach is.

> Although the way they implemented closures was using anonymous traits, and I don't know how heavy-weight this approach is.
It's done this way for performance reasons, it's almost exactly how C++ handles lambdas (creates an anonymous struct type for the closure).
This doesn't restrict you from doing things like, say, creating an array of closures, in that case you would have to box them and use "trait objects", which represents a runtime typed object that is an instance of a trait. So I would say it is as "heavy-weight" as it needs to be.

>It's done this way for performance reasons
I thought it was done for implementation simplicity rather than speed. Of course I know that it doesn't restrict what you can do with lambdas (i.e. it's not python lambdas, they're real legitimate first-class lambdas).

It's clunky as fuck. In a FP language you have something like
map list (+ 1)
In Rust you get stuff like
list.iter().map(|&&x| x + 1)
zip is even worse
list.iter().zip(other.iter())

And it gets even worse when you want to work with these map/zip results somewhere else because of their bloated Iterator types, where zip returns just another list in FP languages.

>I thought it was done for implementation simplicity
Maybe, but it's also more performant than heap allocating a generic closure object.

It is like this because of the lack of GC. Besides, map() on an iterator is better than specific map() implementations per list structure. This is a non issue in Haskell because every list structure can be converted to a lazy linked list, or just implement them all as linked lists because you don't really have a choice without explicitly mutable state. If you had removed the '.iter()'s it would look like
list.map(|&&x| x + 1)
list.zip(other)
The && might be able to be omitted due to deref semantics too. But if they can't, they are there because Rust is not about brevity of functional syntax, it's about safety of memory handling, in which case it makes sense to be explicit about references vs owned objects.

This.

I think rust's "modern" features are clunky like C++, but I'd like to see its reference counting and memory management in other languages. I think I still like the language though

It seems to have arrived too late.

jahky ass OEM coolers

No. You're comparing haskell to rust, not a FP language to rust. Equivalent in scheme:
(map (lambda x (1+ x)) list)


Additionally, you're comparing apples to oranges in that in the rust example, the operation is implemented for iterators and not for lists, while in haskell, it's actually implemented for lists and not for iterators.
Additionally, you don't need the other.iter(), you can just do list.iter().zip(other).

Just in time mate.

Everything you can do in Rust you can do in C++ including memory safety.

>haskell is not fp
>scheme is tho
tard...

Not even remotely true.

everything you can do in C++ you can do in C including everything unless you're a fucking retard

Were you dropped on the head as a child or were you born this way?

>I can't into programming
Just say so.

Oh and I forgot the worst thing about Rust; the absolute inane formatting style. In almost all languages, people agreed on:
IDENT = [
VALUE, VALUE
];

In Rust it's:
IDENT = [VALUE,
VALUE];

Which creates abominations like
const SOME_ARRAY: [u8; 8] = [1,
2,
3,
4,
5,
6,
7,
8];

everywhere in your code.

>I got told
kekeroonies!

>I don't have a clue what I'm saying
apex lel

>muh damage control
you kids sure are funny :^)

Are you retarded or just pretending?

Just pretending.

Well you got me good, I r8 it 6/8.

or you could, you know, just initialize your array of numbers between 1 and 8 using a range. or writing the numbers on the same line, if you meant for short entries. or accept the fact that this looks shit even with you're proposed formatting style (which i am using, so i fucking know how shit it looks sometimes).