A role may be opening up at my company that involves translating prototype code developed in Julia into operational code implemented in Go. I’d like to identify, in advance, candidates who are both proficient in Go, and familiar (at least) with Julia. The role will require a balance of software development, programming language, and people skills.
Note that this an unofficial/informal pre-posting inquiry. I’m just trying to identify potential candidates in advance, at this time. I will not be subjecting anyone to a formal interview/hiring process until that posting comes out (date is TBD). With that understood, please feel free to contact me to discuss (informally) further.
Hi, I’ve translated code to Julia (from MATLAB, it’s one way to avoid licencing cost). I must ask, why translate from Julia?
Meta/Facebook has done this, prototype their new audio codec in Julia, and port to C, for embedded, likely to avoid the GC (you can also do that within Julia…, even easier now), and/or for speed (in a small memory environment). [If wasn’t really done to get rid of Julia, or so I understood, the Julia and C codebases are kept in sync. Maybe at some point only the C code maintained?]
Since Go has a GC (and not used in embedded) why translate at all? You can call from Go to Julia (though maybe not done much?). Is it to clean up the (prototype) code too? It can be done in the same language, and all the speed achieved you need, faster than Go, most probably.
You raise good questions. I’m not in a position to justify the decision. The best outcome I can hope for is that the Julia and Go codebases be kept in sync.
With a very loose appropriation of the term, sure, but the two-language problem is actually an opinion specific to the state of scientific computing at a specific time, albeit one that ages well. It’s not about all usages of multiple languages, and it’s not a fact of life that using multiple languages is a problem.
Take Ousterhout’s Dichotomy, for example. At first glance, there is a nearly identical distinction between static, compiled, systems languages for basic computational components and dynamic, interpreted, scripting languages for descriptive abstractions that glue those components together. However, the problems John Ousterhout ran into were very different, so his programming language Tcl is very different and doesn’t aim to replace two languages, just be one of them.
Different contexts will have different needs and approaches from scientific computing, so the way Julia approaches the two-language problem could easily be irrelevant. There are many things that other languages are better for.
Compiling smaller executables might be another important consideration. People were complaining that Go’s hello world executable was “too large” at 1.9MB almost a decade ago, the reason being that the Go runtime with all its language features is taking up space. Meanwhile, PackageCompiler executables easily run into the 100s of MB, and juliac is still in development.