Java, Perl and Lisp have much more in common than e.g. Java and C++.
Name:
Anonymous2015-10-10 15:10
The most important thing is the state of the community you will be sourcing your libraries from. Pick a hipster language if you want to be a big fish in a small pond, pick a language with a strong and active community if you want to do something useful.
Never pick a language with an idiot community, like Javascript or PHP. Even if the language itself was good, the libraries will have awful APIs and be subtly incorrect and insecure.
Specific language features, like Erlang's knack for concurrency or Rusts memory safety are just nice-to-haves.
Name:
Anonymous2015-10-10 17:24
rust memeory safety
yet..... there is no formal model of the type system and no proof of preservation and progress.
>>5 Rust's type system is based on multiple decades of research on linear logic and type theory. It's not been formally proven correct, in the same way that no full language has had a formal proof; only strict toy subsets.
IHBT.
Name:
Anonymous2015-10-10 19:53
>>6 Multiple decades of failed research? It's time to grow up and realize that just because someone has spent a lot of time on something doesn't mean it's good. Niklaus Wirth has spent decades on Oberon, Oberon OS and Modula, but they're all utter useless shit.
Name:
Anonymous2015-10-10 19:56
This whole "rust memory safety hasn't been proven" thing is one of the worst forced memes I've ever seen. Almost as bad a horses.
Name:
Anonymous2015-10-10 19:57
>>8 1. It's unverified. 2. It's a pain to use. 3. You get stuck with raw pointers anyway.
>>7 JFGI and you'll see it's not one guy jerking himself off. You made the assertion, so you have to find the evidence to back up your point. Fucking sage your stupid shitty comments as well, you arrogant shitlord.
Name:
Anonymous2015-10-10 19:59
>>9 1. No other language is ``verified''. 2. C++ is a pain to use. Go is a pain to use. Python is a pain to use. Your mother's anus is a pain to use. 3. You haven't written a line of rust.
Name:
Anonymous2015-10-10 20:01
rust is shit
Name:
Anonymous2015-10-10 20:04
>>11 1. SML is verified 2. C++ is a pain that gives you access to tons of libraries and megatons of legacy code. With Rust, you have to start over from rocks and spears for no reason. 3. No, I haven't, but the Anons on /prog/ posted their experience of Rust and the type system was insufferable.
Name:
Anonymous2015-10-10 20:09
>>13 1. Still with some arbitrary definition of ``verified``, and nobody uses it. 2. Rust has a proper FFI mechanism which gives you access to all C libraries ever, if you don't mind rewriting a few function signatures. 3. Don't do things like this. Use your own opinions. You are not twitter.
>>13 I don't recall seeing much experience reporting on Rust. Nearly all of the negative assessments I've read here were posted by people who haven't used it or were demonstrably lying.
If you can write it well in your favourite ML do that, as always. If it's more of a C++ problem, do it in Rust.
If you think C++ has a better type system, just stop programming altogether. If it's the region system I don't know what to say, regions need disambiguation sometimes. If babby wants RC/GC types instead, they're available.
Choose Life. Choose a programming language. Choose an editor. Choose an operating system. Choose a fucking big machine, choose compilers, libraries, compact toolchains and version control systems.
Choose sitting on that couch coding mind-numbing, spirit-crushing enterprise applications, stuffing fucking JAVA into your mouth. Choose rotting away at the end of it all, pissing your last in a miserable home, nothing more than an embarrassment to the selfish, fucked up brats you spawned to replace yourselves. Choose your future. Choose life...
But why would I want to do a thing like that? I chose not to choose life. I chose somethin' else. And the reasons? There are no reasons. Who needs reasons when you've got Racket?
>>31 Didn't On Lisp already feature a Prolog compiler built... On... Lisp? Anything done by the Racket project is as bloated as shit as they constantly expand everything to support twenty different variants of the language.
>>32 It's slow, but not for that reason. I don't think you know what you're talking about.
Name:
Anonymous2015-10-15 7:20
I refuse to program in a language that doesn't support GC. I spent $7 a day on coffee, might as well spend $0.01 on CPU to do memory mgmnt for me.
People who don't want to pay the GC price are pauper pleb, too broke to afford cycles because they don't contribute anything. Yet still blowing high of their ivory tower about their stoic practices. as if that makes them cool.
gimme a break and go code some node, nerds
Name:
Anonymous2015-10-15 7:52
Yeah this is why you have systems like ThinLisp, GOAL, Symta hosted on top of Common Lisp usually, also libs like trivial-garbage. Just like typing should be strictly opt-in, garbage collection should be opt-out.
That was literally one guy complaining because he was trying to write his own bindings and didn't know how to make it work. If he was serious about his project he would have just used the unsafe memory manipulation functions in the Rust standard library, like everyone else does (at least until a convenient solution is available).
Point being, it's not that Rust is incapable of doing certain things. It's just that this one guy didn't know how to do them.
It's just that this one guy didn't know how to do them.
It's a little more than that. He needed to provide the functionality in a seamless way to library consumers without adding overhead. It can be done, but you end up with a convoluted solution and will have to rely on the optimizer to fix it up for you. He should complain, but not at the Vulkan people, except about the actual API deficiencies.
provide the functionality in a seamless way to library consumers without adding overhead
he would have just used the unsafe memory manipulation functions
Overhead my foot
Name:
Anonymous2015-10-16 16:24
>>45 Are you an idiot? Yes, he can use the unsafe functions, but he's writing a (safe) library that has to provide access to this information. It's right there in the text you quoted.
It turns out Rust can manage this, at least for unions with a small number of variants. This depends on having better inlining and related optimizations than Clang at -O2, not something I expected. My first test eliminated all of the code since the results weren't used.
But I would never use this technique. Defining the union in Rust was hard and accessing it would break on other machines. One of the few safety features they try to assert in unsafe Rust keeps you from accessing data of the wrong size for the type. Unions fuck that shit right up because you have to describe a struct with non-overlapping fields in Rust to get the repr sized right. It might be impossible to reclaim performance with certain layouts.
If I absolutely had to deal with it I would either write an inefficient wrapper in C (return a struct with all union fields laid out sequentially, i.e. no union) or, if performance/memory was paramount I would push the minimum of logic into a C switch. Since Rust's ABI is unspecified you can't just return enum values out of the switch, so it would have to be more involved than that.
Name:
Anonymous2015-10-16 18:59
>>42-46 These memory layouts can be done safely. They're safe. Rust just doesn't give you good control over memory.
