# Mention of Julia for the re-implementation of PETSC **URL:** \ **Category:** Offtopic\ **Created:** [September 7, 2020, 1:51pm UTC](https://discourse.julialang.org/t/mention-of-julia-for-the-re-implementation-of-petsc/46199 "2020-09-07T13:51:06Z")\ **Posts on this page:** 6\ **Page:** 2

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\ **Post date:** [September 9, 2020, 8:14am UTC](https://discourse.julialang.org/t/mention-of-julia-for-the-re-implementation-of-petsc/46199/21 "2020-09-09T08:14:28Z")

> [@jlapeyre](#): > > And almost no new project that wants users with a broad background will choose Julia as the user-facing language […] All this is widely understood in the Julia community. I am not sure it is. In fact, I think that many people here hold the opposite view, ie that _various features make Julia is ideal for a user-facing API_, with the understanding that “user” in this context means someone who is willing to put together various building blocks to solve numerical problems as part of a program, while preferring to leave the implementation of these blocks to others to the extent possible. The prevalence of Python comes from history: keep in mind that it is _more than 2 decades_ older than Julia\*. Not switching a large existing codebase to another language is a reasonable choice in a lot of cases, but does not necessarily reflect on the relative merits of languages. ---

**Author:** ![Eben60](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/eben60/32/13475_2.png) [@Eben60](https://discourse.julialang.org/u/Eben60)\ **Post date:** [September 9, 2020, 1:02pm UTC](https://discourse.julialang.org/t/mention-of-julia-for-the-re-implementation-of-petsc/46199/22 "2020-09-09T13:02:27Z")

> [@RoyiAvital](#): > > No one would wrap an existing code base in Julia. > Let’s say I have a system which is doing some analysis of signals and now I want a new module to address new model of a signal. Or see [Data-exchange Julia-LabView](https://discourse.julialang.org/t/data-exchange-julia-labview/46315) for another use case: Experiment control by LabVIEW, and e.g. signal analysis with Julia. ---

**Author:** ![jlapeyre](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jlapeyre/32/4514_2.png) [@jlapeyre](https://discourse.julialang.org/u/jlapeyre)\ **Post date:** [September 9, 2020, 3:07pm UTC](https://discourse.julialang.org/t/mention-of-julia-for-the-re-implementation-of-petsc/46199/23 "2020-09-09T15:07:06Z")

> [@Tamas\_Papp](#): > > In fact, I think that many people here hold the opposite view, ie that _various features make Julia is ideal for a user-facing API_ , I and many other people here think that Julia makes a great user facing API, far better than Python. (Maybe not ideal, because of JIT latency, etc. although this is improving greatly). I think Python is an absolutely terrible choice for any position in a scientific computing stack. Maybe I meant “almost no new project” in the measure-theoretic sense. In my experience, essentially everyone mistakenly believes that Python is an ok, or even great, language for scientific computing. ---

**Author:** ![RoyiAvital](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/royiavital/32/571_2.png) [@RoyiAvital](https://discourse.julialang.org/u/RoyiAvital)\ **Post date:** [September 29, 2020, 5:03am UTC](https://discourse.julialang.org/t/mention-of-julia-for-the-re-implementation-of-petsc/46199/24 "2020-09-29T05:03:07Z")

@simonbyrne created [Conjugate Gradient for `C` in Julia](https://github.com/simonbyrne/libcg). I haven’t tested it in Windows and haven’t checked the Julia overhead in that case but it is an example. Are there more like that? Can anyone write some guidelines on how to optimize such use cases to minimize Julia’s overhead in such modules? ---

**Author:** ![paulmelis](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/paulmelis/32/35063_2.png) [@paulmelis](https://discourse.julialang.org/u/paulmelis)\ **Post date:** [September 29, 2020, 7:47am UTC](https://discourse.julialang.org/t/mention-of-julia-for-the-re-implementation-of-petsc/46199/25 "2020-09-29T07:47:33Z")

> [@jlapeyre](#): > > I and many other people here think that Julia makes a great user facing API, far better than Python. > [@jlapeyre](#): > > I think Python is an absolutely terrible choice for any position in a scientific computing stack. […] In my experience, essentially everyone mistakenly believes that Python is an ok, or even great, language for scientific computing. Would you care to elaborate on this? As these are pretty bold statements given the popularity of Python in this context. If “scientific computing” is narrowly defined as “writing code to perform scientific computations” then I would agree with you, but many researchers are using Python as the proverbial “glue language” to build on existing components (regardless of what language those components are developed in). The latter use of Python is where it really shines. I certainly would not consider Julia a better option in that respect. ---

**Author:** ![simonbyrne](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/simonbyrne/32/19_2.png) [@simonbyrne](https://discourse.julialang.org/u/simonbyrne)\ **Post date:** [September 29, 2020, 3:30pm UTC](https://discourse.julialang.org/t/mention-of-julia-for-the-re-implementation-of-petsc/46199/26 "2020-09-29T15:30:40Z")

It is running on Windows: [https://github.com/simonbyrne/libcg/runs/1156215742](https://github.com/simonbyrne/libcg/runs/1156215742) [Previous page](https://discourse.julialang.org/t/mention-of-julia-for-the-re-implementation-of-petsc/46199.md?page=1)