Orica | Australia | Full-Time | REMOTE (AUSTRALIA ONLY)
Our team is building blast design and simulation software. Our tech stack is 100% pure rust. We have a pile of interesting problems to solve: building elegant UX, 3d rendering complex surfaces, simulating explosions, etc.
Really nice team, fully remote (from anywhere in Australia).
They're all good questions. The thing that reads the config should have been fuzz tested with something like AFL. Likely should have a lot more tests. Maybe shouldn't run in a device driver. There's almost no doubt there are engineering process and culture issues here.
> Rollback is hard I guess once your OS can't boot.
This is why the client needs have enough error handling to realise it's latest update has now caused unsuccessful boot and roll that update back locally to the last known good configuration (or completely back to factory and pull all updates again).
Page wont load for me. BUT, this title is the first sensible thing I’ve heard someone say about Agile in 10 years.
I just don’t use the word Agile. Too many people like it for the wrong reasons, or hate it for the wrong reasons. Everyone has a different understanding of it. It’s just not useful.
If I say “let’s use Agile” it’s just going to lead to arguments and misunderstandings.
Id always rather be more specific about which Agile idea I think will be useful. E.g. “let’s build a prototype before we waste time planning too much detail” or “lets get something built and released so we can learn more about what our customers want” etc.
I feel like there are some very precise ways to think about these things.
For example, a backlog is a priority queue. A priority queue can only be long if work is added more frequently than it is removed.
Work can be removed if it is either completed or abandoned.
Work can be added when users request features, users find bugs, product owners predict features will be useful, or the dev team adds technical improvements.
Talking to users will increase the bugs identified and the user requested features.
So by these relationships, talking to customers will directly increase the size of the backlog.
And the overall backlog length may be large due to many factors unrelated to talking to customers: slow development, never deleting out of date work, adding too many technical tasks, adding too much unvalidated vision work, etc.
Does anyone know of any books, blogs or youtubers that bring this kind of logical system level thinking to software work management?
I love this, but Im using DataSpell from JetBrains at the moment because it has 2 killer features:
1. Variable viewer so I can see the current value of all variables in scope.
2. Interactive debugger
Maybe the variable viewer is only important because Jupyter notebooks don’t track and rerun dependencies? So I wouldn’t need it with Marimo. But the interactive debugger is priceless.
C# is my main language. I consider it a very good all-round language.
Rust's type system has some advantages over C# tho, for example Sum Type, Option (C# has ? but it was added later so you need to be careful when interacting with old code, kinda like TypeScript <-> JavaScript to a lesser extent), exhaustive enum, etc.
Another thing I don't like about C# is the runtime startup time which prevents me from using it for command line tools (Yes I prefer static typed languages even for "scripting"). I think Go has proven that you can have both GC and extremely fast startup time.
Either one has really good startup time (below ~100ms and 20-30ms respectively depending on what you do), compact binary size and require no external dependencies. Just like in Go except without all shortcomings of Go :)
p.s.: AOT on macOS requires .NET 8 preview (will be released in November)
20 milliseconds? On my 7 year old Linux box, this little Nim program https://github.com/c-blake/bu/blob/main/wsz.nim runs to completion in 109.62 +- 0.17 microseconds when fully statically linked with musl libc on Linux. That's with a stripped environment (with `env -i`). It takes more like 118.1 +- 1.1 microseconds with my usual 54 environment variables. The program only does about 17 system calls total, though.
Additionally, https://github.com/c-blake/cligen makes decent CLI tools a real breeze. If you like some of Go's qualities but the language seems too limited, you might like Nim: https://nim-lang.org. I generally find getting good performance much less of a challenge with Nim, but Nim is undeniably less well known with a smaller ecosystem and less corporate backing.
EDIT: I make only observations here, not demands. Another observation on the same machine is `python-3.11.5 </dev/null` with an empty environment taking 7.85 +- 0.02 ms.
20ms as measured with `time` on Fish shell on macOS. Let's be real, comparing versus Nim here is the same as comparing with C - both are a much lower level languages and don't do as much work on startup (threadpool, GC, etc.) and, for the reference, 60fps is 16.6ms per frame. The difference is unlikely to be noticeable. And this isn't measuring program execution time but back to back console receiving a command to launch a binary, OS doing so, binary starting, doing useful work (displaying hint that the command was not in the correct format) and only then exiting.
I agree this particular C# being >180x slower may not matter much for one-off commands keyed-in by and watched by humans, but that may not be all that matters. E.g., some people might `find . -print | xargs -n1 cmd`. Almost everything almost always "all depends". (On a whole lot. E.g., only @raincole can elaborate on his use cases and what might be missing from the Nim ecosystem.)
EDIT: Also, it's misleading to bundle Nim with C and C's many & storied footguns. While "low-level" is somewhat subjective and you can opt-in to go as low as C (if you so desire), most Nim code is as high-level as Python or C# with various choices in automatic memory management, and the language has very high-level capabilities. E.g., Nim has user-defined operators like Julia. Want to add `=~` or `~` for regex pattern matching? No problemo. In that aspect, Nim is arguably higher-level than C#.
Then the answer is F#.
OCaml has everything except the big ecosystem. Haskell has a way bigger Ecosystem than OCaml, but is still not comparable to Rust.
Runtime startup might be a fixed issue soon for smaller CLI programs. Correct me if I'm wrong, but I believe they are working on (and it is already available with a compiler option) to compile your C# program ahead of time (C# AOT).
Pick up some F# then. Both can interop, I've built many things in a combo of the two languages, plus it'll make you a better C# developer and your type system power greatly increases. Be careful though you might not want to go back to C#.
C# calls the first one "nullable reference types." When that build option is enabled, all types are non-nullable by default, and you can make them optionally nullable by declaring them like "MyClass? cls = null;"
The compiler will ensure you check for null before de-referencing a nullable type.
This isn't gradual typing? If libraries are not compiled with the compiler option, then all their reference types will be deemed nullable and I need to check for null before dereferencing. I can't do something like "GetItem().Name" if "GetItem()" returns a reference type like I could in Java, GoLang, JS, etc. If that library did use the flag and was provably non-nullable, then I could.
I think the whole chart was made in a drawing program like MS paint or Visio. The spacing between the columns isn’t quite even as would be the case with any software charting library, especially noticeable for the gaps left and right of the blue bar.
Also this quote is amazing
“the authors state that “no datasets were generated or analyzed during the current study””
Our team is building blast design and simulation software. Our tech stack is 100% pure rust. We have a pile of interesting problems to solve: building elegant UX, 3d rendering complex surfaces, simulating explosions, etc.
Really nice team, fully remote (from anywhere in Australia).
Follow the link to apply: https://www.seek.com.au/job/81661361