News for hackers. Stuff that matters.
Re:Rust and the Future of Systems Programming [video] by z3t4 on Wednesday November 16, 2016 @12:56PM (#12969510)
when you can run javascript on a pebble watch it blurs the boundaries ... Want to concat an number and string ? JavaScript wont complain.
Re:Rust and the Future of Systems Programming [video] by 0xAA55 on Wednesday November 16, 2016 @01:15PM (#12969699)
Want to make a fast application on a pebble and with actual type checking? C and Ada won't complain or blur your lines... http://blog.adacore.com/make-with-ada-formal-proof-on-my-wri...
Re:Rust and the Future of Systems Programming [video] by steveklabnik on Wednesday November 16, 2016 @01:16PM (#12969717)
You can do it in Rust too; though most of the demos I see on GitHub are just demos.
Re:Rust and the Future of Systems Programming [video] by z3t4 on Wednesday November 16, 2016 @02:31PM (#12970565)
And real programmers write in machine code. Want to get shit done ? Most systems now a day has more then 20kb RAM! Where do you draw the line between systems programming and non system programming ? And why not write some quick and dirty code in say JavaScript and then do what needs optimization in C/assembly ? Assuming you are not restricted to a CPU that cost less then a dollar. And where does Rust come in ?
Re:Rust and the Future of Systems Programming [video] by Retra on Thursday November 17, 2016 @01:25AM (#12974890)
What kind of engineer goes around saying "It could be faster, leaner, and more efficient? No! Build the biggest, flakiest, ugliest thing that gets the job done today!"
Re:Rust and the Future of Systems Programming [video] by takeda on Wednesday November 16, 2016 @04:18PM (#12971635)
With smart watches we still have problems, mainly to hold enough power. Yes, Pebble can last a week, but that's because it is running less resource intensive hardware, and even then 1 week is still laughable when comparing to old watches that require battery change once per 2 years.

By being more conservative, you can achieve more with less resources.

Re:Rust and the Future of Systems Programming [video] by 0xAA55 on Thursday November 17, 2016 @11:36PM (#12984391)
Every single application or website is a system (see the push in recent years for web assembly).

The difference is that a "systems programming language" has the capability of being used low level if needed while a "shit scripting language" such as javascript does not. Basically what I am saying here is that Javascript is an underwear taint-stain for modern computer science. With any luck it will be rid of this world in 20 years and you javascript programmers can stop torturing yourselves with new "hot libraries" and "ECMA transpilers" every 2-4 years.

Re:Rust and the Future of Systems Programming [video] by wyager on Wednesday November 16, 2016 @03:58PM (#12971455)
There isn't actually a trade-off between efficiency and ease of use across all languages. For example, JavaScript is both slow and memory hungry while also being inconvenient to use.
Re:Rust and the Future of Systems Programming [video] by wyager on Wednesday November 16, 2016 @01:10PM (#12969643)
> Want to concat an number and string ? JavaScript wont complain.

Is that supposed to be an endorsement?

Re:Rust and the Future of Systems Programming [video] by z3t4 on Wednesday November 16, 2016 @02:42PM (#12970685)

  foo = (string, number) => string + number
Now go write that in your preferred language!
Re:Rust and the Future of Systems Programming [video] by wyager on Wednesday November 16, 2016 @03:55PM (#12971426)
Why would I want to? Better to explicitly convert the number to a string.
Re:Rust and the Future of Systems Programming [video] by z3t4 on Wednesday November 16, 2016 @04:41PM (#12971847)
This is something you do often in JavaScript, for example:

  "You have " + messages + " new messages"
Re:Rust and the Future of Systems Programming [video] by colemickens on Wednesday November 16, 2016 @11:24PM (#12974251)
So, since we're talking about Rust...

    print!("You have %d new messages", messages)
Was that supposed to make me want to abandon all type safety and embrace a GC'd language that runs in a VM?
Re:Rust and the Future of Systems Programming [video] by z3t4 on Thursday November 17, 2016 @03:05AM (#12975401)
There are advantages to GC, even Rust has runtime GC. But where is the memory freed ? You don't have to think of that at all in JavaScript. Also when something goes wrong with types in JavaScript the worst case scenario is "2"+2 turns into "22" witch is easy to avoid, compared to a silent overwrite/overflow. Even if the types in JavaScript is very loose, they are much safer.
Re:Rust and the Future of Systems Programming [video] by lmm on Thursday November 17, 2016 @06:46AM (#12976555)
> There are advantages to GC, even Rust has runtime GC.

If you want GC there are any number of good languages to pick with it (e.g. OCaml).

> Also when something goes wrong with types in JavaScript the worst case scenario is "2"+2 turns into "22" witch is easy to avoid, compared to a silent overwrite/overflow.

It's memory-safe but it's not safe. What if an error like that happens in your permission-checking code? I agree that silent overwrites and silent overflows should not happen and that language that have those things are bad, but that doesn't make silent type errors any better.

Re:Rust and the Future of Systems Programming [video] by z3t4 on Thursday November 17, 2016 @04:05PM (#12981552)
The problem here is that + is used for both addition and concatenation. Most of the time you know what you are doing though (smile) and string is the default. When I started out with JavaScript I used -- (minus minus) for addition just to be safe. If you where to compare "22" == 22 ? it would be true, so the type doesn't really matter. If you want to do arithmetics on a string, no problem! Even null behaves like a teddy bear compared to other languages where it can bite you hard. Also note that this child toy language can run on embedded systems, and doing memory safe IO concurrency is so easy it's hard not to, like oops I did ten thousand concurrent request, but it finished in less then a second, because this is 2016 and not 1986 and computing performance and memory has grown exponentially since. Don't get me wrong though, systems languages has their place in lower level where the bits, bytes and performance matters. Someone once told me that JavaScript is a lot like assembly because you are so free, there is no one telling you "No, you shouldn't do it that way" like in Rust.
Re:Rust and the Future of Systems Programming [video] by lmm on Friday November 18, 2016 @03:55PM (#12990003)
> Someone once told me that JavaScript is a lot like assembly because you are so free, there is no one telling you "No, you shouldn't do it that way" like in Rust.

Um, yeah. I think that's a fair comparison. And anyone who's had to debug or maintain a large system written in assembly/javascript knows why that's a bad idea.

Re:Rust and the Future of Systems Programming [video] by steveklabnik on Thursday November 17, 2016 @12:48PM (#12979638)

  > even Rust has runtime GC
Only in an extremely narrow sense; there's no tracing GC, only reference counted types. And they're not used very often.
Re:Rust and the Future of Systems Programming [video] by kaoD on Wednesday November 16, 2016 @05:50PM (#12972354)
"You have undefined new messages"

Glorious!

Re:Rust and the Future of Systems Programming [video] by z3t4 on Thursday November 17, 2016 @02:37AM (#12975235)
It's very easy to spot the error here, compared to for example a segfault.
Re:Rust and the Future of Systems Programming [video] by lmm on Thursday November 17, 2016 @06:42AM (#12976531)
That's damning with faint praise if I ever heard it. (And it's not even true; undefined tends to propagate further, the segfault usually happens closer to the actual error. Not that I'm defending languages that segfault by any means)
Re:Rust and the Future of Systems Programming [video] by kaoD on Thursday November 17, 2016 @08:03AM (#12977046)
Not to mention a SEGFAULT in Rust is a bug in Rust the language/std, not your program (unless you're writing unsafe code, which is pretty much never).
Re:Rust and the Future of Systems Programming [video] by nixos on Thursday November 17, 2016 @12:52AM (#12974739)
And in Java, and in any language with operator overloading
Re:Rust and the Future of Systems Programming [video] by z3t4 on Thursday November 17, 2016 @03:16AM (#12975457)
operator overloading and meta is very nice, but can add a lot of complexity.
Re:Rust and the Future of Systems Programming [video] by nixos on Thursday November 17, 2016 @03:28AM (#12975534)
Yes, but you can have static typing and ease of use
Re:Rust and the Future of Systems Programming [video] by wyager on Wednesday November 16, 2016 @10:12PM (#12973916)
"You have " ++ show messages ++ "new messages"

This is type safe.

Re:Rust and the Future of Systems Programming [video] by bsder on Wednesday November 16, 2016 @03:14PM (#12971027)
> when you can run javascript on a pebble watch it blurs the boundaries

And yet Javascript can't access a network socket or my flash storage in any useful portable way.

Javascript is hampered by everybody trying to bolt on "security" after the fact and basically hobbling usage of the language.

Re:Rust and the Future of Systems Programming [video] by z3t4 on Wednesday November 16, 2016 @05:25PM (#12972180)
You also need a hardware abstraction layer with Rust, so why not use a higher level language like JavaScript or Haskell, besides optimizations and personal preference !?