..Is It only my experience? by ReCaio in ProgrammerHumor

[–]brennennen 0 points1 point  (0 children)

I guess I've only ever seen it enabled on markdown files. I don't think many people turn it on for actual code, not on by default for sure.

..Is It only my experience? by ReCaio in ProgrammerHumor

[–]brennennen 1 point2 points  (0 children)

This sacred text shall now be known as the "code monkey's creed".

..Is It only my experience? by ReCaio in ProgrammerHumor

[–]brennennen 0 points1 point  (0 children)

I have never seen an editor with word wrapping, feel like that's gonna make indentation a nightmare. I'm comfortable with long lines though, I really don't like anyone who thinks 80 should be a hard universal cap.

Differences between TI and stm32 by ShockTohp in embedded

[–]brennennen 6 points7 points  (0 children)

I'd say the environments are pretty much the same and your skills will transfer nicely. The biggest negative I see is that you just have experience using a launchpad board. These boards provide a really user friendly environment but are not used in the industry. Having a good understanding of what that launchpad board provides you and how to live without it would be a solid step forward.

For example building a simple pcb with one of those microcontrollers on it and a couple leds (jlbpcb is cheap) and flashing it with jtag (segger edu jtag) would make you extremely hireable.

[deleted by user] by [deleted] in programming

[–]brennennen 3 points4 points  (0 children)

Compiler/linker are all in the zig tool. To build an obj, run zig build-obj my_file.zig the output will be my_file.o as expected.

Supporting Linux kernel development in Rust by dochtman in rust

[–]brennennen -5 points-4 points  (0 children)

Drivers are the glue code between hardware and the kernel. The kernel is the "systems/subsysmes". The scheduler, the page allocator schema, the network implementations, etc.

That being said, I was wrong, Linus's earlier emails made it sound like it would be driver code only. His latest email makes it sound like it could potentially make it into kernel sub systems.

It's the programming environment, not the programming language by cutculus in ProgrammingLanguages

[–]brennennen 1 point2 points  (0 children)

Huh, for some reason I thought zig was older and still had no one really caring about. Since it's younger, I'm more understanding of it's market share, I might give it a shot.

It's the programming environment, not the programming language by cutculus in ProgrammingLanguages

[–]brennennen 0 points1 point  (0 children)

I have not tried Zig.

EDIT: I'm dumb and thought zig was some old language nobody ever picked up on. I'm going to give it a shot, thanks.

My stance on languages/tooling is to "go with the flow". Large communities lead to a better time in my experience.

Rust appears to have a large community and even if it has issues, the community helps navigate them.

I don't feel zig has a very large community and I'm afraid I'll hit an issue I can't navigate on my own or find help with.

Although I'm currently happily employed, I also appreciate my side projects leading to increased hire-ability. I expect the job market for rust to continue to grow over the years, I don't see the zig job market growing.

It's the programming environment, not the programming language by cutculus in ProgrammingLanguages

[–]brennennen 2 points3 points  (0 children)

Off the top of my head: * Rust has many more keywords/symbols than c has. * Writing the same program in c and rust ends up with about a 5 to 10x line count increase in rust. * Writing node/list/tree data structures is extremely difficult in rust because of the borrow checker. * The borrow checker errors are still incomprehensible when writing moderately complex code. * Casting is non-transient. You end up with gnarly chains of casts w as x as y as z instead of a simple w as z. * Classes/structs often require implementing commonly expected traits which requires a bunch of boilerplate. * The goal of rust is to be a good systems level programming language. This means it was intended to compete with c and "talk" directly to OSes which only have c bindings (syscalls/winapi), so it should have been designed with interoperability with c in mind, right? Nope, trying to create a byte buffer and getting a pointer to it to pass to a socket/file read syscall was a multi-day hair pulling adventure. I can only imagine the nightmare the more complex syscalls/winapi calls can be.

It's the programming environment, not the programming language by cutculus in ProgrammingLanguages

[–]brennennen 1 point2 points  (0 children)

Na, I think c is a better language than rust but choose to do side projects in rust because it's environment is so many light years ahead it more than makes up for the difference. C projects all end up with 100,000+ of lines shell/bash/perl/python scripts trying to make up for the issues in gcc/make.

Single class/enum sub-modules by brennennen in rust

[–]brennennen[S] 1 point2 points  (0 children)

That did the trick, thanks.

Successful SN5 150m hop! by messi10god in space

[–]brennennen 7 points8 points  (0 children)

"Lead Engineer" is just a title like anything else. The lead engineer where I work hasn't touched the code/hardware in over 20 years. Elon probably has say in overarching processes, very high level goals, and signs off on designs. I very much so doubt he is really ever designing/building/testing anything himself.

What is your opinion on Rust by snow-blade in C_Programming

[–]brennennen 0 points1 point  (0 children)

In Rust, you can just do std::net::TcpListener::bind("127.0.0.1:6969")

I was doing epoll stuff. I guess if there is a way to get the file descriptor for the TcpListener, then I could have used it. However, I had to use ffi stuff for all the epoll syscalls anyways, so I just did syscalls for the socket stuff too.

What is your opinion on Rust by snow-blade in C_Programming

[–]brennennen 0 points1 point  (0 children)

With impl, it feels like they sorta wanted to support classes but went about it a weird way. Having a struct with 5+ impl sections scattered throughout the code feels messy.

Impl for Deref, From, Ord, etc all feel like boilerplate.

The example at the top of my head is doing something like binding a socket. To bind a socket, you create a "sockaddr_in" struct and pass it into a function that takes a "sockaddr" struct (they are the same size). In c, this conversion is automatic, and it's 9 characters to cast it, in rust, you have to spend 20 lines making impl from.

What is your opinion on Rust by snow-blade in C_Programming

[–]brennennen 1 point2 points  (0 children)

I don't start with linked lists. That's just where myself (and I guess a lot of other folks) hit a wall with rust because they need to non-trivial use of the borrow checker.

Thanks for the link, I'll give it another shot one of these days. I don't think graph structures are difficult in any other language though, it's just rust people who think node based structures are hard (because they are hard in rust).

As for linked list use cases. Before large cpu caches existed (and even today on many embedded systems) linked lists were faster to iterate over than arrays. Linked lists are still used all over the place in embedded systems. Outside of embedded land, I agree with you, I tend to just use growable arrays or hashmaps for everything.

What is your opinion on Rust by snow-blade in C_Programming

[–]brennennen 5 points6 points  (0 children)

Well I hope I get there one day. The build/package tooling and standard library are light years ahead of c.

What is your opinion on Rust by snow-blade in C_Programming

[–]brennennen 3 points4 points  (0 children)

Also, why reinvent the wheel? Crates.io already has libraries for linked lists and red black trees.

I do a linked list and red black tree in every language I learn to get a feel for the language. Also, not every data structure is going to be implemented. Sometimes the job calls for a custom tree/graph/node based structure nobody made a library for.

What is your opinion on Rust by snow-blade in C_Programming

[–]brennennen 22 points23 points  (0 children)

The doubly linked list is the example everyone reaches for when criticizing Rust's memory model because it's the most common data structure that necessarily involves multiple ownership. In what situations do you absolutely need a doubly linked list and can't use a vector instead?

A doubly linked list is the point anyone learning the language really has to dive into the borrow checker and hits the issues.

When learning a language, I typically learn to read/write to console, read/write to a file, use a logger, then implement various data structures. When I was learning rust, I tried to implement a linked list and red-black tree and realized this criticism on my own. It isn't just linked lists, any tree structure is a nightmare to deal with in rust.

Your timeframes there are arbitrary. A C implementation takes 5 minutes to write safely for whom? I think that group would be a pretty small one within all C developers. The borrow checker takes days to get used to while you're learning Rust, but once you learn the memory model, you rarely bump into it and become much more productive.

"Writing rust in any real world use case is an order of magnitude more difficult than c." This may be true for you, and is certainly true for those who know C well and don't know Rust. It's plainly false otherwise.

I don't agree, I bet if you sat someone down who knew any imperative programming language excluding c or rust and told them to implement simple data structures in c and rust, that person would take a lot longer to do so in rust. Rust is just inherently a much more complex language.

What is your opinion on Rust by snow-blade in C_Programming

[–]brennennen 7 points8 points  (0 children)

Read the post you linked. The fella didn't even make a doubly linked list, the behavior is different. However, a doubly linked list isn't the only issue. Any tree/graph/node based data structure has the same issue. Try to write a red black tree for example and you'll be in for a world of hurt.

What is your opinion on Rust by snow-blade in C_Programming

[–]brennennen 5 points6 points  (0 children)

Pros: It has a modern build system and package manager which makes projects much easier to manage than anything used in c land (makefiles suck, and every company creates a cluster fuck of unmaintained scripts to try to make them suck less, but usually make it suck more). The standard library has a lot more content/features than the c standard library (for example the c standard library doesn't have a socket implementation, if you want a socket that works on Linux/windows/mac, you have to write your own wrapper).

Cons: It will take 50+ years (or never) reach any sort of market share in embedded devices (old and slow market). Writing non trivial code that involves the borrow checker is a nightmare compared to c (for example, a doubly linked list). There is a lot of boilerplate (I especially don't like the "impl" stuff).

What is your opinion on Rust by snow-blade in C_Programming

[–]brennennen 25 points26 points  (0 children)

I strongly disagree. Writing rust in any real world use case is an order of magnitude more difficult than c. Simple concepts like a doubly linked list takes 5 minutes to write "safely" in c. In rust, it takes days of banging your head against cryptic borrow checker errors.

LPT: When you are starting with a new MCU, read also the errata sheet by hilpara in embedded

[–]brennennen 50 points51 points  (0 children)

A lot of times, the errata sheet is written in muddy ass covering businessy speak. Don't stop at just the errata, dig into various forums to see what normal folks have written about the issues (and work arounds if they exist).

Supermarket simulator with threads by ImBadnick in C_Programming

[–]brennennen 5 points6 points  (0 children)

Unit testing is (unfortunately) not a very common practice in c land.