|
Pollyanna posted:Why is it a string? Why? For the Glory of Satan of course!
|
#
?
Nov 30, 2017 17:34
|
|
|
|
| # ? May 25, 2024 03:11 |
|
|
Thankfully, being C, it's still an array of bytes!
|
|
#
?
Nov 30, 2017 17:41
|
|
|
Munkeymon posted:Assuming you're getting it on one of the big email services, you should really report it as spam because it'll hurt their score on the filters and they won't take their lovely compliance seriously until people who actually want their daily whatevers don't get them. This is how I handle all unwanted email. "Oh, you've opted me into whatever stupid newsletter you decided to add to your site? Great, it's spam now. Maybe I'll let Google try to unsubscribe me but that's the most effort I'm willing to put into interacting with your POS customer relations team."
|
|
#
?
Nov 30, 2017 17:52
|
|
|
CPColin posted:Thankfully, being C, it's still an array of bytes! Hahahaha I love the idea of their unit test for exporting an array of bytes to be some sort of data quine.
|
|
#
?
Nov 30, 2017 19:25
|
|
|
iospace posted:C is the best Same. I will move to Rust or Go or whatever the latest fad in systems programming languages is when someone writes one that I can actually do low-level systems programming with. Maybe. CPColin posted:Thankfully, being C, it's still an array of bytes! yesssssssssss
|
|
#
?
Nov 30, 2017 19:33
|
|
|
Kazinsal posted:Same. I will move to Rust or Go or whatever the latest fad in systems programming languages is when someone writes one that I can actually do low-level systems programming with. Maybe. Yeah, I'm a low-level person myself. The only other realistic option at this juncture is assembly and FUUUUUUUUUUCK THAT
|
|
#
?
Nov 30, 2017 19:47
|
|
|
Assembly is an awesome cool language... as long as I never *have* to use it and only mess with it when I'm in the mood. gently caress actually writing anything big in assembly. Hell no. I think Rollercoaster Tycoon was entirely programmed by one guy IN ASSEMBLY, which is straight up bonkers.
|
|
#
?
Nov 30, 2017 19:49
|
|
|
Assembly was kinda fun in human resource machine.
|
|
#
?
Nov 30, 2017 20:10
|
|
|
iospace posted:Yeah, I'm a low-level person myself. The only other realistic option at this juncture is assembly and C++? With poo poo like RTTI disabled of course.
|
|
#
?
Nov 30, 2017 20:28
|
|
|
zergstain posted:C++? With poo poo like RTTI disabled of course. Unless you have a very good reason to disable RTTI and you know what you're doing ... don't.
|
|
#
?
Nov 30, 2017 20:31
|
|
|
Volguus posted:Unless you have a very good reason to disable RTTI and you know what you're doing ... don't. Mostly I was thinking for low level systems programming you would want to minimize runtime overhead. I mainly had Apple's IOKit in mind.
|
|
#
?
Nov 30, 2017 21:36
|
|
|
zergstain posted:Mostly I was thinking for low level systems programming you would want to minimize runtime overhead. I mainly had Apple's IOKit in mind. As far as I know, C++ RTTI only has runtime cost when you perform dynamic casts. It also has a cost in static data and generated support code, which is negligible for big systems, but could be an issue for embedded where storage is measured in kilobytes.
|
|
#
?
Nov 30, 2017 21:56
|
|
|
Zaphod42 posted:I think Rollercoaster Tycoon was entirely programmed by one guy IN ASSEMBLY, which is straight up bonkers. Apparently, only 99% was written in machine code. What a slacker.
|
|
#
?
Nov 30, 2017 22:02
|
|
|
Yet it seems like it was the last foray he did, sticking to what he knew. I work with a coworker who made some Commodore 64 games I enjoy, and it's really shocking thinking about how he's somehow progressed into the 21st century AAA development seamlessly. I can't imagine how weird the progression would have been working in the industry from assembly only with no debuggers to full ides and sdks along with all the tricks of engine development and spiralling game sizes.
|
|
#
?
Nov 30, 2017 22:05
|
|
|
Kazinsal posted:Same. I will move to Rust or Go or whatever the latest fad in systems programming languages is when someone writes one that I can actually do low-level systems programming with. Maybe. Of course it requires that you can compile with LLVM and not just some bespoke trash C compiler.
|
|
#
?
Nov 30, 2017 22:44
|
|
|
nielsm posted:embedded where storage is measured in kilobytes. 
|
|
#
?
Dec 1, 2017 01:57
|
|
|
Dylan16807 posted:I think Rust can do that? I'd give the language some more time to settle, but it's an explicit design goal. Rust has no std-lib features and direct memory fiddling capabilities. Somebody has written a toy, I believe self-hosting OS in Rust with some significant features like device and graphics interfaces (including a port of libmesa), and networking. I wouldn't like... use it for anything that you need to be cock sure is perfect atm, but you can do pretty deep low level stuff. (Especially crypto, nothing related to crypto in Rust has been verified by an expert, so if you need any crypto functionality you're boned without involving a C toolchain at some point).
|
|
#
?
Dec 1, 2017 02:14
|
|
|
Pollyanna posted:Why is it a string? Similarly, I've seen code store a set of booleans as "101101101" (a string).
|
|
#
?
Dec 1, 2017 05:32
|
|
|
SupSuper posted:You'd be surprised how many programmers don't understand bytes. PL/I flashbacks ...
|
|
#
?
Dec 1, 2017 05:35
|
|
|
I also don't understand the gripe against Rust for low-level systems programming. I'm not doubting it, just asking for a more obvious example. It's not obvious to me.
|
|
#
?
Dec 1, 2017 05:38
|
|
|
Here’s my favorite Rust take: http://notes.willcrichton.net/rust-the-new-llvm/
|
|
#
?
Dec 1, 2017 05:56
|
|
|
SupSuper posted:You'd be surprised how many programmers don't understand bytes. What. No really, what. BITWISE OPERATIONS MOTHER FUCKER, DO YOU KNOW THEM
|
|
#
?
Dec 1, 2017 06:06
|
|
|
SupSuper posted:You'd be surprised how many programmers don't understand bytes. We often represent byte arrays as base64 strings, and I've dealt way too many times with someone calling .getBytes() directly on that string without decoding.
|
|
#
?
Dec 1, 2017 06:12
|
|
|
The biggest complaint I usually hear about low-level Rust is that there's no support for custom allocators. I don't really do enough low-level stuff to know how big of a deal that is, though.
|
|
#
?
Dec 1, 2017 06:19
|
|
|
Coffee Mugshot posted:I also don't understand the gripe against Rust for low-level systems programming. I'm not doubting it, just asking for a more obvious example. It's not obvious to me. I've never personally used it or have had a need to use it, so I'm effectively neutral on it. So until someone proves that it's usable without having to write 9001 custom libraries for what I want, then C it is. (If someone has an Atmel library writen in it, I may try it for shits 'n giggles)
|
|
#
?
Dec 1, 2017 06:21
|
|
|
VikingofRock posted:The biggest complaint I usually hear about low-level Rust is that there's no support for custom allocators. I don't really do enough low-level stuff to know how big of a deal that is, though. There is but it's unstable, no idea how much of a PITA it is to use though.
|
|
#
?
Dec 1, 2017 06:21
|
|
|
Linear Zoetrope posted:Rust has no std-lib features and direct memory fiddling capabilities.
|
|
#
?
Dec 1, 2017 06:56
|
|
|
comedyblissoption posted:What are the "direct memory fiddling capabilities" that Rust doesn't have? As far as I'm aware you can write and read arbitrary bytes in Rust. Sorry, that was meant to read "no std lib" features and "direct memory fiddling capabilities". As in, it has features to eschew using the standard library. I just phrased it dumb.
|
|
#
?
Dec 1, 2017 07:04
|
|
|
Coffee Mugshot posted:I also don't understand the gripe against Rust for low-level systems programming. I'm not doubting it, just asking for a more obvious example. It's not obvious to me. This is a bit esoteric, but you can't implement libc with it because rust doesn't support functions with variadic arguments.
|
|
#
?
Dec 1, 2017 10:04
|
|
|
Linear Zoetrope posted:There is but it's unstable, no idea how much of a PITA it is to use though. There's also an approved RFC for per-container allocators: https://github.com/rust-lang/rfcs/blob/master/text/1398-kinds-of-allocators.md It's not fully implemented yet but they're getting there.
|
|
#
?
Dec 1, 2017 10:11
|
|
|
b0lt posted:This is a bit esoteric, but you can't implement libc with it because rust doesn't support functions with variadic arguments. That's fair, but I sort of assumed any low level systems programming would involve linking against libc and calling it through some FFI or w/e. I don't think re-implementing libc would be a goal. It just seems pretty nice to know a few kernel modules are memory safe/sanitized or something. I guess when I think of the overall need for things like https://github.com/google/sanitizers, it seems like what Rust offers would offset the need for explicit sanitation passes in the compiler (I guess you'd still want TSan).
|
|
#
?
Dec 1, 2017 10:48
|
|
|
b0lt posted:This is a bit esoteric, but you can't implement libc with it because rust doesn't support functions with variadic arguments. In my ignorance I always thought variadic functions were just syntactic sugar for passing in array arguments. I'm guessing that isn't the case at all in C?
|
|
#
?
Dec 1, 2017 12:02
|
|
|
nah, you just get extra arguments pushed to the stack. va_list just walks the stack for you. it's a ridiculous idea and can go incredibly wrong.
|
|
#
?
Dec 1, 2017 12:39
|
|
|
JawnV6 posted:Here’s my favorite Rust take: http://notes.willcrichton.net/rust-the-new-llvm/ That's... well that sure is a take
|
|
#
?
Dec 1, 2017 14:47
|
|
|
JawnV6 posted:Here’s my favorite Rust take: http://notes.willcrichton.net/rust-the-new-llvm/ Can I, uh, get a tl;dr here? Because aren't Rust and LLVM two entirely different things?
|
|
#
?
Dec 1, 2017 15:01
|
|
|
iospace posted:Because aren't Rust and LLVM two entirely different things? Besides, Rust==LLVM because their Levenshtein distance is equal to their string lengths. 
|
|
#
?
Dec 1, 2017 15:10
|
|
|
iospace posted:Can I, uh, get a tl;dr here? Because aren't Rust and LLVM two entirely different things? LLVM provides a cross-platform assembly-ish language that frontend compilers (such as Rust's) can target, which can then be compiled into actual assembly for target platforms. This is advantageous because a wide variety of languages can be implemented without having to reimplement things like register allocation and optimizations. The article suggests that Rust itself is an even better intermediate language, because it can provide zero runtime cost vs LLVM, but offer a great many compile-time capabilities, such as type-checking and memory/concurrency safety guarantees.
|
|
#
?
Dec 1, 2017 15:12
|
|
|
PhantomOfTheCopier posted:But it's a new language, hence it automatically is better than * and subsumes * and what are these other things of which you speak the world started with Rust. So in otherwords, the same type of people you see thumping functional languages all the time. Got it. eth0.n posted:LLVM provides a cross-platform assembly-ish language that frontend compilers (such as Rust's) can target, which can then be compiled into actual assembly for target platforms. This is advantageous because a wide variety of languages can be implemented without having to reimplement things like register allocation and optimizations. Ah, ok. So compiler stuff that generally wooshes over my head.
|
|
#
?
Dec 1, 2017 15:15
|
|
|
eth0.n posted:LLVM provides a cross-platform assembly-ish language that frontend compilers (such as Rust's) can target, which can then be compiled into actual assembly for target platforms. This is advantageous because a wide variety of languages can be implemented without having to reimplement things like register allocation and optimizations. Considering that Rust's biggest advantage over LLVM (or C, or C--) lies in its compile-time checks, it seems odd to choose it as a compilation target. That is, you could write a compiler for your language that is smart enough to write Rust code that successfully compiles, but it sounds like it would be relatively easier to just do the same compile-time checks in your compiler and then compile to a target that lacks those checks. Although, if you make a mistake, having your compiler emit Rust code that doesn't compile at all might be preferrable to having your compiler emit buggy C / LLVM code, I guess. In any case, I can't say if that's an accurate interpretation of what the article means, because my work firewall is awesome: 
|
|
#
?
Dec 1, 2017 16:46
|
|
|
|
| # ? May 25, 2024 03:11 |
|
|
I mean, the idea is reasonable. I assume you would write a huge standard library for your language in Rust and then just have your compilation frontend generate some intermediate code that calls those library functions after you take all the expressions in your languages and massage them into Rust code. The generated code would probably be very little in comparison to the size of the existing Rust stdlib that people can actually read and write and use nice tools for. Debugging Rust code would probably be a lot easier than debugging LLVM IR's SSA code in terms of the tooling in place. And well, Rust generates LLVM IR anyways. It seems like it'd be nice not to reimplement the borrow checking logic in your language if you take advantage of an intermediary target that becomes LLVM IR anyways. If I was writing a new "memory-safe" language, this could be an easier start than actually using LLVM.
|
|
#
?
Dec 1, 2017 17:41
|
|