Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fortran Package Manager

github.com

Post reply on HN
Print view View original

61–70 of 73 posts

Re: Fortran Package Manager

#61

Post by certik »

trianglesphere wrote: post #60
trianglesphere wrote: post #56

Earlier quoted context omitted.

It seems like there's a small resurgence. You'd use fortan over those other languages for scientific computing. It's built for number crunching. As so it has some language features that help, has been optimized for it (see the n-body problem benchmark), and a lot of the number curnching libraries are written in it. One example of a project that I've used (but didn't work on) is GEMINI which is a newish prokect writte…

huh, ifort is slower than I remember compared other langs/impls: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

I don't know what exactly is going on, but last time I looked into it, it seemed the main difference between the codes was how quickly you can do 1/sqrt(x). Ultimately, I would like to see more numerical benchmarks and also compare more versions in a given language.

We started a repository for it:

https://github.com/fortran-lang/benchmarks/

But didn't have time to work on it yet. See the issues, e.g., at:

https://github.com/fortran-lang/benchmarks/issues/2

For some discussion how to best do that.

Re: Fortran Package Manager

#62

Post by certik »

mxcrossb wrote: post #12

I think I would prefer a separation between the package manager and build system. I’ve already got a build system for my FORTRAN codes, and that system can handle all the complications. SPACK, for example, can easily work with a pre-existing build system. But I definitely think that the worst part of FORTRAN compared to modern languages is that it takes so much work to manage external dependencies, so I appreciate th…

This issue of separating a build system and a package manager vs lumping it together is a key design decision. We chose to follow Rust's Cargo, which lumps it together. It seems like a wrong decision at first (for the reason you stated), but we feel it is actually the right decision: from the user experience it feels much more natural and robust. I was not sure at first, but after playing with Cargo and Rust, you realize that this is the way to go.

Re: Fortran Package Manager

#63

Post by certik »

xioxox wrote: post #42
oblio wrote: post #20

For folks who have never used Fortran, how is the day to day life compared to Python or Java?

Never or ever? I have to use it for a work project. It's ok when dealing with numbers or matrices, but very painful in many respects. It's missing quite a few features found in more recent languages. I don't recommend it personally unless you're working with other big fortran codes. * Missing standard data structures, like hash maps. I just wish I had something like a Python dictionary built in. * Strings are pretty…

Thank you. I agree with all of this, and that is precisely the reason why I decided to get involved to make things better. To fix all of the above I believe we need:

* Much better tooling and more organized community, thus we started https://fortran-lang.org/ and the associated projects (fpm, stdlib, ...) and discussion board (Discourse)

* Better compiler that has good support for all Fortran features, and can help with linking and using C++ and Python libraries (automatic wrappers both ways), better optional warnings (to prevent old style code), good support for GPUs, etc. Also interactive like Python or Julia. I started LFortran (https://lfortran.org) to fix that.

* Perhaps some improvements to the language (I joined the Standards Committee and I encourage people to join). We have a subgroup for generics (templates). The hash maps should probably go to stdlib first, later we can think about putting them into the language itself.

Re: Fortran Package Manager

#64

Post by certik »

omrjml wrote: post #29
Mauricebranagh wrote: post #26

Earlier quoted context omitted.

Also Compared to Python Fortran is an old school compiled language - you have to get used to working with a compline/link cycle without the interactivity that Python has. This isn't any better or worse but does require a shift in mind set. Though I believe some people are trying to build a Fortan Repl

That's true, I keep forgetting about https://lfortran.org/ Unfortunately in my experience the people I know who almost exclusively code in fortran are not really interested in jupyter notebooks.

Indeed, I expect it will be newcomers to Fortran from languages like Python, Julia or Matlab who will really like LFortran once it matures. We are working very hard on it and are close to compiling real world projects, you can follow our progress on MVP here:

https://gitlab.com/lfortran/lfortran/-/issues/313

Current Fortran programmers might not always appreciate the interactive part, but I think they will also like LFortran as another independent compiler and for some of its features once it matures (such as C++ translation, fast compilation, good warnings, automatic wrappers to/from Python, etc.).

Re: Fortran Package Manager

#65

Post by certik »

ktpsns wrote: post #19
mraza007 wrote: post #15

Just curious is Fotran Still being used in Newer Projects

I find the trinity of Matlab, Fortran and Julia quite interesting. They all have a similar syntax and I guess Julia can grab quite some people from the other two ecosystems. Clasically, scientists used Matlab for prototyping and Fortran for high performance implementations. With Julia, things might change. However, in science, changes happen slowly and there are still tons of codes (and also new codes) written in For…

Also with LFortran (https://lfortran.org) being interactive like Julia, our hope is that it will allow to prototype directly in Fortran.

(I am the original author of LFortran.)

Re: Fortran Package Manager

#66

Post by Bostonian »

shp0ngle wrote: post #46
mraza007 wrote: post #15

Just curious is Fotran Still being used in Newer Projects

SciPy and NumPy both use Fortran :P

https://www.quora.com/Which-python-packages-besides-Numpy-us... Does NumPy use Fortran?

NumPy does not use Fortran. It provides an interface to BLAS (Basic Linear Algebra Subprograms) and Lapack (Linear Algebra Package) for which the reference implementation is written in Fortran.

Re: Fortran Package Manager

#67

Post by mraza007 »

certik wrote: post #65
ktpsns wrote: post #19

Earlier quoted context omitted.

I find the trinity of Matlab, Fortran and Julia quite interesting. They all have a similar syntax and I guess Julia can grab quite some people from the other two ecosystems. Clasically, scientists used Matlab for prototyping and Fortran for high performance implementations. With Julia, things might change. However, in science, changes happen slowly and there are still tons of codes (and also new codes) written in For…

Also with LFortran ( https://lfortran.org ) being interactive like Julia, our hope is that it will allow to prototype directly in Fortran. (I am the original author of LFortran.)

Thanks for sharing I’ll definitely check it out

Re: Fortran Package Manager

#68

Post by cik »

milancurcic wrote: post #51
cik wrote: post #33

I rely on FPM the Effing Package manager[0]. Occasionally, I run into php-fpm [1]. There's an unfortunate naming collision, at least with the first. [0]: https://github.com/jordansissel/fpm [1]: https://www.php.net/manual/en/install.fpm.php

We asked for and received a blessing from Jordan: https://github.com/fortran-lang/fpm/issues/90

I mean that's great - but I don't think it's necessary, it's a name not a trademark. I was trying to point out that its unfortunate when names collide.

Re: Fortran Package Manager

#69

Post by oscardssmith »

abzug wrote: post #58
the_only_law wrote: post #57

Is there any value in learning Fortran today, regardless if you work in a domain where it’s a thing or now? From seeing a lot of job postings in the sort of domains one would expect it to be used(scientific stuff and similar “academic” and research fields) it seems like Python and maybe Julia has taken over for most stuff and Fortran requirements are written as if it’s a “nice to have” for any legacy maintenance.

A bunch of scientific libraries in Python and Julia are wrappers for really fast stuff made in Fortran, C/C++ so...

BLAS/LApack are pretty much the only Fortran libraries that Julia uses afaik. There is also in development work on a Julia only blas replacement (Octavian.jl) which is competitive with mkl for the basic gemm already (more work needed for some of the more obscure functions). Lots of the push behind Julia is for it's ability to let fairly simple code compete with hands optimized Fortran.

Re: Fortran Package Manager

#70

Post by oscardssmith »

dionhaefner wrote: post #17
mraza007 wrote: post #15

Just curious is Fotran Still being used in Newer Projects

Yes. Fortran is used extensively in climate modelling (even newer models).

If you're interested in climate modeling, you should really check out Clima.jl. it's an international collaboration on building a next gen climate model in Julia that uses some cool tricks like heavy usage of surrogate models that would be really hard to do in Fortran
Post reply on HN