This is something a build system should be able to help with. I use Bazel to generate files that are then presented to the go compiler for embedding, but even tools like make, cmake, etc. should be able to do this. Neat to have an in-go package as well though!
I prefer my build pipeline to not depend on tools that have complicated setups. I’m using this package in a project that only uses make and a go compiler for all the steps.
CMake is even more horrifying than I thought, after several years of using it! (;,;) <- a Cthulu emoticon. The author does do a good job of capturing the way I feel about CMake, so +1.
I feel like I’m stuck with it, though. My project requires a systems level programming language. I chose C++ because of the library ecosystem: I depend on some unique, domain-specific libraries that are written in C++: no equivalents exist in other languages. And these other libraries are built using CMake.
Is there an alternative? I feel the same way about C++ that I do about CMake. For me, the alternative might be Rust + Cargo, rather than yet another C++ build system.
As to Rust, I’ve recently tried it in a hobby project, having a fairly long C++ background & love affair (which I left in panic, after eventually glimpsing the eldritch horrors lurking therein). My very subjective thoughts:
I was afraid to start experimenting with Rust because of learning curve and fear of struggling with borrow checker. What pushed me to try were two things: Rust 2018 edition (I have a feeling this is “The Actual Rust 1.0”), and some blog post I read which made me realize: “it’s totally OK, and you don’t need to feel bad, to just use heap/boxing if you struggle too much with borrow checker, esp. when learning; also even if you theoretically might lose some teeny bit of performance then, let’s be honest, you’re probably not even going to notice”. The Rust 2018 Edition was indeed what I thought it to be (it fixes a LOT of extreme frustrations you don’t even have to realize were there just a few months ago).
Compared to any C++ build systems, cargo is a bliss. At least for my simple app/library, it was 100% transparent and “out of the way”. The basic commands after cargo init are: cargo check, cargo test, cargo build, cargo fmt.
I didn’t read The Rust Book. I tried, but I found it too long and still too messy, unfortunately. So I finally decided to go with a hands-on/deep-dive approach, just trying to write an app. Against all recommendations, this worked for me.
But then, maybe because of no Rust Book reading, or maybe just because The Learning Curve, it was painful and a lot of teeth gnashing. But there are good parts there:
I quickly started to feel the GOOD in Rust. It. Is. Amazing. It made me feel so much safer and protected. Hard for me to describe this aspect in proper words here. It’s worth trying at least to know what all the people are talking about.
There’s a lot of answers for your problems on Stack Overflow. (A.k.a. you will have a lot of problems that other people had before you; but I’ve already said that.)
The good people on the Rust chat/discord (“beginners” channel) are really patient and helpful.
Did I say cargo is a bliss?
When I needed something, I was googling or searching crates.rs, and grown to expect that the library I need will usually just be there. That’s impressive in my book.
However, as of now, I’m starting to think I’m going to try something else for my app (in particular, Nim; but if not it, I’d probably stay with Rust). The not-so-good parts for me in this case were:
It’s a bit too tiresome for me at this point. Maybe it’s not enough The Rust Book, or maybe it’s being spoiled with Go, but feels a bit too slow and a bit too much energy toll for me at this stage. Not easy to find the appropriate metaphor, but maybe kinda like walking through a moderate rain. Not that bad (in no way Java or JS or C++ templates), and you have good and water-proof equipment with you, but the creeping cold, wet, and gray sky can grow on you still — even if you know you’re going further with every step, and there’s a cozy hut full of your smiling friends waiting for you at the end of the road. Not painful, mind me. But kinda tiresome.
Again, maybe that’s not enough of the Book, or maybe that’s just the Steep Curve, but there is some complexity. It kinda reminds me a bit of some light-medium C++ templates — though absolutely without the Eldritch Insanity and Terror — just some of the complexity level, and more often than not the feeling of “not really sure what I’m doing”, and a lot of semi-blind tries (“hm, then maybe I should try this?”) until something finally works. The infamous “wrestling the borrow checker.” Though I started to also feel the glimpse of the later phase when you would slowly subconsciously start to get a feel for it, and I found there were times when things were “just working” as I wrote them.
What also tires me somewhat is some level of ceremony required. A bit too much fluff for me (the .unwrap()s, the Ok(())s, the temporary variables required because of no “statement scope”, etc.). Here, I’m probably unfortunately totally spoiled by Go and Lua. That’s to some extent the “straw” which made me start exploring Nim for this case. The “saving grace” to some extent is that there’s actually some sense to this ceremony, as opposed to e.g. Java where it’s just the dumb laziness of the language syntax.
The libraries, although usually there, are unfortunately not always totally perfect; sometimes 99.9% there, but not the 100%. Some APIs, even in the stdlib, I believe could be done friendlier. I understand that the borrow checker enforces a lot of architectural choices, but still. Again, I may be spoiled by the Go stdlib here. Again, it somewhat reminds me of the Java stdlibs.
Some closing thoughts:
The experiment was also interesting in that I found what people mean by “the borrow checker sometimes enforces architectural choices”. A particular architectural decision that would be obvious and idiomatic in Go or (mostly) any other language, I couldn’t do in Rust. But then after a night’s sleep, on the next day I realized there’s a different way I should do this, which would be inappropriate in Go, but was absolutely appropriate in Rust. It was surprising and interesting to me.
My overarching feeling after the experiment is that I’d love to have a language with Rust’s safety & protections, but with Go’s simplicity. A.k.a. “I have a feeling there might be a smaller, simpler language in there, trying to escape”. But I also understand this may not be true, or be but not ever happen. I feel Rust is totally exploring a new and important frontier here, and being a pioneer inventor tends to involve some cruft and rough edges. Only after the dust settles some “cleaners” might arrive, have a look from the distance, and try to simplify. If we’re really lucky, there’s a non-zero chance this could actually even happen still in Rust, with some Rust Edition far enough in the future!
Bazel is great for C++ applications. I’ve rarely successfully integrated a third party library’s own CMake project into my own, so accepted rewriting it to make it work. Bazel (despite its flaws) makes that easy.
Meson looks promising for integrating into the wider OSS world
Not particularly. Basically you write rules in a BUILD file for a single directory (“package” in bazel terminology), and that refers to files in that dir or in subdirs if the subdirs don’t have their own BUILD files (rules). So failrly straightforward to wrap libraries.
And now I’ve tried it. Just works. Pretty slick on both ends. Took me a moment to realise I need to specify the client IP on both ends, but after I did that the packets flowed.
I’ve been eyeing this for a while. I’ve been meaning to get a VPN set up for over a year now, but I’m becoming more and more allergic to complex software at home. On the other hand, WG has seemed like an endless beta to me. Maybe it’s time to give it a shot.
Meaningful work to me means something that lets me challenge my skills, interact with good people, and do overall more good than harm to the world (human and natural).
My current and previous jobs have been deeply meaningful.
I currently work on autonomous vehicle software. I work with great people, am constantly challenged to deepen and expand my skills and knowledge, and I personally believe this is a place technology will improve and save human lives and decrease our stress on the environment. It is only “overall” improvement, because there will be a generation of displaced workers who will suffer, as there has been with most large economic shifts. We as a society, and I as an engineer, still don’t have an answer for them.
Previously I worked in a “personal robotics” research lab, where the goal was primarily assistive care robots and robotic arms for the people with disabilities. I found that work deeply meaningful on all counts as well.
Earlier jobs were much less meaningful. The companies were uninspiring and sometimes monopolistic, the work quickly became humdrum, and many coworkers would sooner throw you under a bus than help you, or simply did not care about the work they were doing. Like you, I realized I wasn’t satisfied.
I was able to move to more meaningful work because of three things:
I asked myself what the hardest, more interesting problem I could work on was (my answer was non-military robotics)
I was able to take a biiiiig pay cut and still feed my son because my wife also works and was very supportive
Most things with impact are hard, and you’ll find lots of good folks to work with at the intersection of hard and impactful.
I usually can’t speak about my work, but this week I’m giving a talk to a university robotics club about motion planning. Trying to do more talks in general.
Could I get a link to your materials? I’ve been writing a blog series on control theory, so I’m curious to see how others teach somewhat similar topics.
This is important for hiring experienced developers from different fields, specialties, and language backgrounds as well. Hire good people and they will learn or can be taught your domain and technology. I just passed a year transitioning from enterprise development to robotics. I absolutely love it, and am providing a lot of value, and it’s all because someone gave me a chance.
One thing I didn’t like about Go’s default
embed.FSmechanism is that it didn’t support pipelining processing operations on the files it embeds.That’s why I created this assets package which allows you to add something like minification for static files, or possibly even an encryption step.
This is something a build system should be able to help with. I use Bazel to generate files that are then presented to the go compiler for embedding, but even tools like make, cmake, etc. should be able to do this. Neat to have an in-go package as well though!
I prefer my build pipeline to not depend on tools that have complicated setups. I’m using this package in a project that only uses make and a go compiler for all the steps.
Planning a blog post on this, but briefly:
Very similar to my setup, except:
Oh, and files named like 2020-01-31-Event-Name-001.RAW
CMake is even more horrifying than I thought, after several years of using it! (;,;) <- a Cthulu emoticon. The author does do a good job of capturing the way I feel about CMake, so +1.
I feel like I’m stuck with it, though. My project requires a systems level programming language. I chose C++ because of the library ecosystem: I depend on some unique, domain-specific libraries that are written in C++: no equivalents exist in other languages. And these other libraries are built using CMake.
Is there an alternative? I feel the same way about C++ that I do about CMake. For me, the alternative might be Rust + Cargo, rather than yet another C++ build system.
CMake made me realize I actually like autotools; though perhaps out of Stockholm syndrome.
Try Meson. It can even find dependencies using CMake!
Well, get ready to write C APIs to all your unique C++ libraries :)
(there’s Swig though I guess)
As to Rust, I’ve recently tried it in a hobby project, having a fairly long C++ background & love affair (which I left in panic, after eventually glimpsing the eldritch horrors lurking therein). My very subjective thoughts:
I was afraid to start experimenting with Rust because of learning curve and fear of struggling with borrow checker. What pushed me to try were two things: Rust 2018 edition (I have a feeling this is “The Actual Rust 1.0”), and some blog post I read which made me realize: “it’s totally OK, and you don’t need to feel bad, to just use heap/boxing if you struggle too much with borrow checker, esp. when learning; also even if you theoretically might lose some teeny bit of performance then, let’s be honest, you’re probably not even going to notice”. The Rust 2018 Edition was indeed what I thought it to be (it fixes a LOT of extreme frustrations you don’t even have to realize were there just a few months ago).
Compared to any C++ build systems, cargo is a bliss. At least for my simple app/library, it was 100% transparent and “out of the way”. The basic commands after
cargo initare:cargo check,cargo test,cargo build,cargo fmt.I didn’t read The Rust Book. I tried, but I found it too long and still too messy, unfortunately. So I finally decided to go with a hands-on/deep-dive approach, just trying to write an app. Against all recommendations, this worked for me.
But then, maybe because of no Rust Book reading, or maybe just because The Learning Curve, it was painful and a lot of teeth gnashing. But there are good parts there:
However, as of now, I’m starting to think I’m going to try something else for my app (in particular, Nim; but if not it, I’d probably stay with Rust). The not-so-good parts for me in this case were:
.unwrap()s, theOk(())s, the temporary variables required because of no “statement scope”, etc.). Here, I’m probably unfortunately totally spoiled by Go and Lua. That’s to some extent the “straw” which made me start exploring Nim for this case. The “saving grace” to some extent is that there’s actually some sense to this ceremony, as opposed to e.g. Java where it’s just the dumb laziness of the language syntax.Some closing thoughts:
Bazel is great for C++ applications. I’ve rarely successfully integrated a third party library’s own CMake project into my own, so accepted rewriting it to make it work. Bazel (despite its flaws) makes that easy.
Meson looks promising for integrating into the wider OSS world
Doesn’t Bazel need a specific directory structure so it can work? Can it be used to write build systems for existing projects?
Not particularly. Basically you write rules in a BUILD file for a single directory (“package” in bazel terminology), and that refers to files in that dir or in subdirs if the subdirs don’t have their own BUILD files (rules). So failrly straightforward to wrap libraries.
Nice! Now I have a reason to try https://github.com/Lochnair/vyatta-wireguard on my EdgeRouter.
And now I’ve tried it. Just works. Pretty slick on both ends. Took me a moment to realise I need to specify the client IP on both ends, but after I did that the packets flowed.
I’ve been eyeing this for a while. I’ve been meaning to get a VPN set up for over a year now, but I’m becoming more and more allergic to complex software at home. On the other hand, WG has seemed like an endless beta to me. Maybe it’s time to give it a shot.
Weekly library run with my son, swimming, repairing a gas range igniter, and hopefully get out to do some photography.
Meaningful work to me means something that lets me challenge my skills, interact with good people, and do overall more good than harm to the world (human and natural).
My current and previous jobs have been deeply meaningful.
I currently work on autonomous vehicle software. I work with great people, am constantly challenged to deepen and expand my skills and knowledge, and I personally believe this is a place technology will improve and save human lives and decrease our stress on the environment. It is only “overall” improvement, because there will be a generation of displaced workers who will suffer, as there has been with most large economic shifts. We as a society, and I as an engineer, still don’t have an answer for them.
Previously I worked in a “personal robotics” research lab, where the goal was primarily assistive care robots and robotic arms for the people with disabilities. I found that work deeply meaningful on all counts as well.
Earlier jobs were much less meaningful. The companies were uninspiring and sometimes monopolistic, the work quickly became humdrum, and many coworkers would sooner throw you under a bus than help you, or simply did not care about the work they were doing. Like you, I realized I wasn’t satisfied.
I was able to move to more meaningful work because of three things:
I usually can’t speak about my work, but this week I’m giving a talk to a university robotics club about motion planning. Trying to do more talks in general.
Man, that sucks. I hope you’re keeping secrets for the right moral reasons. Too often people do unkind things when they have secrecy.
Could I get a link to your materials? I’ve been writing a blog series on control theory, so I’m curious to see how others teach somewhat similar topics.
Sure. I don’t have them collected yet, but I plan to provide a collection to the students so I’ll send it along.
This is important for hiring experienced developers from different fields, specialties, and language backgrounds as well. Hire good people and they will learn or can be taught your domain and technology. I just passed a year transitioning from enterprise development to robotics. I absolutely love it, and am providing a lot of value, and it’s all because someone gave me a chance.