If Rust is so good, why are there so few programs written in it?
You all shit on Go (including me) but there are actual major projects written in it. Ethereum along is a bigger deal than any shit Rust has been used for. So what's the deal with Rust?
If Rust is so good, why are there so few programs written in it?
You all shit on Go (including me) but there are actual major projects written in it. Ethereum along is a bigger deal than any shit Rust has been used for. So what's the deal with Rust?
Go is a google project
Problem with Rust is that it's not brainlet friendly. Hence good programmers are busy writing C++ at their job and have a little or no time to use Rust and make a heavy project.
Which is why you see brainlet langs like Go/JS/C#/Python projects so popular among (mediocre) devs.
Hence many companies are trying out Rust, for example VMWare, Google, Dropbox etc
>If Rust is so good
lol
>why are there so few programs written in it?
A combination of things is probably involved. It's new and still pretty unstable as I understand it. Also you know how Sup Forums projects spend all their time jerking off over lo/g/os? CoCs are like that but for other people. They jerk off over finding non-issues and pretending like they're changing the world. This runs off most of the people who see a programming language as a tool to write programs not change the nature of reality. This is actually the desired effect. It's subversive as hell.
>You all shit on Go (including me) but there are actual major projects written in it.
I don't know a whole lot about its merits as a language. I do know that it was created by a software company to work on projects there. They probably made sure it solved some problem they needed and succeeded. Even a shit programming language that gets out of your way and let's you write programs gets used. Programming languages that just wave their CoCs in your face don't so much.
Most people are happy with their gender and sex being in agreement.
go's good, rust sucks, that's about it.
Rust is C++ with training wheels you can't take off.
Maybe someone will use it if it ever comes out of beta.
Rust is nothing like C++. Take your brainlet tier analogy somewhere else, brainlet.
>bloated systems programming language with OOP features and C inspired syntax
>nothing like C++
>systems language
They said the same thing about Java, and look where that got us.
You need C/C++ to write low-level code. You always will. It's a fact of life.
you may see it in microcontrollers before anything else
>unsafe
>unproven broken shit language
>microcontrollers
doubt.jpg
rust is c++ combined with standard ml
as such it is rubbish
>They said the same thing about Java
mmmmm I dunno, you're gonna have to back that claim up
>unproven
people.mpi-sws.org
>broken
Less undefined behavior than C or C++, in general way less broken than both put together.
>shit
Better than C or C++.
>language
On this we agree.
The only thing between Rust and microcontrollers is the fact most MCU companies are fucking retarded and there's going to be a lot of work that needs to be done by people, especially implementing HALs and such.
For companies the main issue is that if you don't use the shit provided by whatever shitty company to work on your shitty project you won't get any support, hell, most of the time you don't even get to pick the RTOS if you want support.
>You need C/C++ to write low-level code. You always will. It's a fact of life.
yeah, you can only interface to syscalls with C ohwaitnevermind forgot rust-lang/libc exists
Redox OS is an entire OS written primarily in Rust. If the lead dev manages to move from VESA BIOS Extensions to Mesa and direct rendering it'll be usable.
Funny, you could say the same for Lisp.
no software
Because rust is new.
Most answers in this thread aren't about Rust but about it's community.
Also amount of programs written in a lang is a poor metric for a great proglang. 'Cause then Java would be the apex omega uberlord of langs, I'd rather choke on 500 dicks than accept that.
I didn't like Rust, for my purposes but it's ecosystem was great and most of it just werks. However a majority of people don't need it's borrowcheck and powerful type system to complete their fizzbuzz so they get along with Python/Go, which is great.
Also I have no idea why you compare Ethereum to Rust.
>Also amount of programs written in a lang is a poor metric for a great proglang. 'Cause then Java would be the apex omega uberlord of langs, I'd rather choke on 500 dicks than accept that.
Being popular doesn't equal being good, but if something is UNpopular, there must be a reason for that. Quite often that reason ends up being "it's just not that good".
Pretty much this. Traits are neat but templates are more powerful. Variable ownership thing is also nice but memory management isn't really a problem for proficient people anyway.
>Also amount of programs written in a lang is a poor metric for a great proglang.
In a world where code reuse is a thing it helps if there's code in your language to reuse.
github.com
can go do this?
github.com
or this? didnt think so. rust will soon make it possible to run emacs on a kernel that both share the same language
what do you think is so special about emacs and rewriting the C part to another language when majority is still written in the crappiest lisp implementation under the sun?
textadept is better than your meme editor
>Rust
>OOP
>C inspired syntax
0/10
>OOP
Nope. Traits (Haskell-style typeclasses and ML style modules).
2/10 post needs work
Rust has everything necessary to do OOP.
OOP doesn't mean "have classes"
And if you don't think Rust syntax is C inspired, then you must think the same of Go's.
>Traits are neat but templates are more powerful.
I actually kind of agree, even though templates are kind of monstrosities. Templates let you pun dependent typing, which isn't (yet) a part of Rust. You can kind of simulate this with the macro system, but I can see why someone adept at using templates for metaprogramming might find the trait system kind of wanting.
>Variable ownership thing is also nice but memory management isn't really a problem for proficient people anyway.
This is where I don't entirely get the detractors. If memory management isn't a problem for proficient people (ie: the ones writing large-scale software systems), where do the thousands to tens of thousands of exploits discovered each year come from? Just because you've never seem a program you wrote exhibit flaws doesn't mean they aren't lurking in there somewhere.
Emacs already runs on a kernel that shares the same language. Emacs and Linux are both written in C.
>Most answers in this thread aren't about Rust but about it's community.
The language itself is nothing special. If you add a few opt-in lints to C compilers you'll have the same amount of safety without the burden of fighting the borrow checker all the time. Once you realize that, you remember that all languages are more or less the same (give or take syntax sugar) and what matters is the tooling around a language and the community that builds and maintains it. In this department Rust fails completely. The people behind it talk about the language and the ideals it represents instead of writing code. They're using it as a soapbox because they want to increase their political reach, and anyone who participates in the community helps them achieve that.
The only winning move is not to play.
>If you add a few opt-in lints to C compilers you'll have the same amount of safety without the burden of fighting the borrow checker all the time.
I doubt this. Which opt-in lints are you thinking of?
Memory and data race safety are very flow-sensitive properties, which lints (strictly syntactic checks) can't really get at. Proving them of C programs requires using separation logic. The only flow-invariant way to recreate them is to implement something like the borrow checker, and if you do this in C, you might as well use Rust since it comes with a package manager and a standard library built for this use-case.
And by the way: my claim isn't that you can't or shouldn't use separation logic conditions with an SMT solver to show your C programs are correct. If you can do this, I'd probably hire you. You're about 1 in 10,000 in terms of knowing your shit and being diligent about your work.
My claim is that actually doing this to get comparable safety out of C programming is considerably more work than developing in C, C++ or Rust, so if it's something you actually want, Rust is hard to dispense with.
I used to think that Rust was a niche systems language and was ignoring it for a long time. But recently I have been taking a look at it and I think its going to take off as a userspace language as the designers have made good decisions on syntax. For example I like how Rust has chosen Python's for-in loops as these can be used as universal mapping functions so you dont have to rely on map/reduce/filter methods on container types. The really big buy-in for Rust that you have to accept is ownership/borrowing. You have to get used to the idea that only one variable can point to heap allocated memory. I personally think this is ok because a CPU can only execute on thing at a time, so its not like this is a restraint on how hardware handles data. Even when you are doing concurrency you only want one variable mutating data, so one-variable ownership fits into modern multi-threading.
>implying I don't hate both
Rust is younger, and doesn't have a large corporation backing it.
Well there's plenty of libraries written in Rust. Just not as many complete programs.
Unproven unstable libraries that you can't trust.
Might as well use node.
>ethereum
>big deal
wrong
>you may see it in microcontrollers before anything else
What size of runtime has it got? That's more than a bit critical for a microcontroller, where there's often a really tiny amount of memory available.
>The really big buy-in for Rust that you have to accept is ownership/borrowing. You have to get used to the idea that only one variable can point to heap allocated memory. I personally think this is ok because a CPU can only execute on thing at a time, so its not like this is a restraint on how hardware handles data. Even when you are doing concurrency you only want one variable mutating data, so one-variable ownership fits into modern multi-threading.
This 100%.
Rust FORCES you to develop in the way you'd use modern C++ if you were very diligent about delegating ownership so it can guarantee safety properties. Fighting the borrow checker is really unpleasant, so after doing it for a bit and not getting the big picture, >muh C++ with training wheels meme is born. But if you actually stop fighting and learn to use the ownership system as intended, you're a little more productive than you'd be using C++ well without having to sweat the program shitting the bed under weird circumstances you'd never considered.
Also I fully admit the Rust community is overfull of sanctimonious tie-dyed douchebags bitching about people not rewriting their 20-year-old C codebases in Rust and not quietly building their own shit, but that's not a demerit on the technical details of the language itself.
Since no one will respond: lintlets BTFO by actual verification facts universities are too plebeian to bother instructing people in at the undergrad level. Open-access paper related is how to actually get Rust-level safety in C (aside from, ya know, using Rust):
sciencedirect.com
>runtime
>microcontroller
>tiny amount of memory
Language hobbyists don't know what any of that means.
It's a language designed by SJWs and deranged trannies. It's not used for serious work.
Lol. No. Good luck convincing electrical engineering and embedded engineers with your language theory crap. They want to move bytes around, not write some pseudo Haskell.
Hint: Both Rust and Go are shit, even if Go may be marginally less shit since at least it appears it can solve problems that might probably have been equally well solved with fucking PowerShell or BASH script in the same amount of time required to code the solution.
>deranged trannies
Are they cute?
No
You're much more likely to convince a hardware vendor to add borrow checker support to their C compiler than to convince them to support Rust.