First Impressions

New to Julia
, , ,
1

Hi, all.

Thanks go to all who have worked on Julia. It is appreciated.

Julia, from the first looks on the website and while looking for information, looked like a language I might just use generally and for data. It is after all reasonably fast and has all sorts of other good things. I was looking at the language and its progress for a while and thought that I would check it out much more once version 1.0 or so was out. And so I did.

But the problem I had with it as a new user, using Julia 1.1 or so (the latest version as I write), consisted at least of the following matters:
(1) the out-of-the-box console REPL experience on Windows (not 10) is not sufficiently good;
(2) there is, as it seems to me, no official hardcore IDE.

Concerning (1), I noticed quickly that unicode characters are not at all displayed. I look around and was reminded of certain possibilities here and there, did effort here and there, but in the end it didn’t make a significant difference such that I could honestly say that point (1) has been made false.

I checked out console alternatives, but even if I were to use an alternative, the out-of-the-box REPL was insufficiently good, which is the point. In fact, when I ran a certain alternative, a virus was even detected. False positive? Maybe, but you can imagine that I should not have had the need to look for any alternative. Again, the out-of-the-box REPL experience was insufficiently good.

Concerning (2), there really does not seem to be any official hardcore IDE for Julia. In the case of R and RStudio there is no big hassle and it works (whether official or not). (I admit, they are not perfect and I had certain preferences, and I had to seek out answers concerning R and RStudio, but it was not really much trouble. It was set and it works.)

Perhaps you would say, “Use Juno.” I don’t trust Juno, as I don’t trust Atom, and it is not the point, for is it true or false that there is an official hardcore IDE for Julia, which is concerning quality and ease of installation at least on par with RStudio for R (and which has good optional Vim-like operation, the same way one may operate a web browser using Vim-like operation, so that I hardly have to move a hand away from the keyboard)?

Now, it is granted to me that I am tech-savvy and that I can find my way around a computer, and perhaps I could find workarounds, perhaps use Linux if it’s a better choice, but that is not the point. If I were making a product, then I would obviously want that product to be so good that a potential client (or user, and whatnot) would not even have to look at anything else.

I saw a few discussions about point (1), but there did not seem to be any answer in that discussion.

So is there going to be a solution anytime soon? Will the REPL experience on Windows be significantly and sufficiently enhanced? Will there be an official Julia IDE which is, so to speak, what RStudio is to R?

Thank you to all who have read, and thank you to the developers and anyone who has contributed to Julia. I truly hope that Julia will be even greater.

2 Likes
2

I just wanted to point out that many of us had exactly the opposite concern about the existence of an “official” IDE. In fact, when julialang.org was overhauled back around the 1.0 release, many of us objected that Juno was being presented as if it were “the official” IDE because we feel that if there is some sort of “canonical” IDE then it suggests that the language is sandboxed somehow and difficult to use in the general case. To some of us having Julia plugins on a variety of IDE’s is vastly preferable to having an “official” one, and that should in no way discourage development on any particular IDE plugin.

As for vim-like operation specifically: if that’s what you want, why not just use vim? The vim plugin is very good, I use it all day every day, and the author of that package is even so wonderful that he even implemented a few pet edge cases for me on request (e.g. it is now possible to go back and forth between a single and multi line function declaration with a single keystroke).

14 Likes
3

To add to this - I’d much rather julia’s core devs spend their energy and resources on continuing to make the language awesome. I love Juno - Seb does amazing work with it (come to think of it - does he have a donation box? I should really kick him a few $), but let 1000 flowers bloom I say.

I suspect that your intentions are good, but you may be disappointed by the response. A lot of people put a ton of work into this language, its packages and the community, most of whom don’t get paid for it. Constructive criticism is all well and good, but showing up as a new user and complaining without actually making any concrete suggestions or offering to help is unlikely to meet with positive reaction.

For the problems with the REPL, have you looked for solutions or filled a bug report? The REPL on Mac is awesome, and with OhMyRepl it’s even more awesome. I’ve never had any problems with Unicode.

As to the pack of IDE, I’m 100% in agreement with @ExpandingMan. Rstudio has some nice features, but Juno blows it out of the water (and the list of features Rstudio has over Juno is shrinking by the day). Not sure why you don’t trust it, but there’s also VScode, vim, and maybe others.[quote=“FRgs, post:1, topic:22318”]
Will there be an official Julia IDE which is, so to speak, what RStudio is to R?
[/quote]

I actually don’t think Rstudio is an official IDE. Is a separate company, and the R project home page doesn’t mention it. Yeah, most R coders use it, but that doesn’t mean anything.

8 Likes
4

Welcome to Julia community!

I have used Juno for a long time, also use Julia+VS code. Juno has most of the features as other popular IDEs, such as PyCharm for Python or RStudio for R. From my own experience, I mainly suffer from the installation problem, especially update to the new version. In fact, most of the errors is caused by the version conflict problem or the unknown problem after update all the Juno+Julia related packages.

These problems can always be solved by reinstalling the Juno plugin or with the help of the other users from Julia community. Some times I feel this IDE is composed of too many components integrated loosely and not so robust as PyCharm or RStudio. In fact, once it runs it is very stable now, at lease compared with the earlier versions.

RStudio is also complained at the earlier stage, which did not have debugging function at that time. Later, it has more and more features and become the RStudio as today. RStudio is developed using C++ and Qt, and put all functions into one program, which seems very stable and fast. Currently, 65 contributors are working on RStudio and lasted for about 9 years ( GitHub - rstudio/rstudio: RStudio is an integrated development environment (IDE) for R ). Compared with RStudio, Juno would be still young, which just has debugging function days before. After some time and more contribution from the community, Juno would be as mature as RStudio in the near future.

In fact, there are some IDEs once look very promising, but dropped for many reasons.

  1. JuliaStudio
    This would be the earliest Julia IDE and developed with C++ and Qt, which is very similar to RStudio ( GitHub - forio/julia-studio: An IDE for the Julia Language ). There are 114 people contributed and 26668 commits. This is supported by one company and maybe dropped because of the business reason. They should put resource on the profitable project.

  2. JuliaDT
    This IDE is once supported by Julia Computing and looks very nice. Unfortunately, it is also dropped for some reasons.
    ( https://juliacomputing.com/blog/2016/02/06/Eclipse-JuliaDT.html )

Currently, Besides Juno several IDEs are under active development. According to my own experience, you can also try

  1. Julia plugin for VS code (Commits · julia-vscode/julia-vscode · GitHub), which seems very robust.

  2. Julia plugin for PyCharm
    Many features, but also many bugs. Still young, maybe a very promissing one in the future.
    ( Julia - IntelliJ IDEs Plugin | Marketplace )

If you just write short code, you can try

  1. REPL
    Very beautiful, at lease than the Python REPL :grinning:

  2. IJulia
    Very convenient for the data processing.
    https://github.com/JuliaLang/IJulia.jl

3 Likes
5

Hi @FRgs. First of all, thank you for taking the time and effort to report your first impressions. It’s greatly appreciated.

There’s a long-standing issue open about shipping a better terminal (with better fonts) on Windows, but it got bogged down in some combination of a) which one? b) is it legal? c) no one ever got around to it, and d) people keep claiming that newer Windowses ship with better terminals these days (I have no idea since I haven’t run Windows since 1997). In any case, it would be a great contribution if someone who actually uses Windows were to figure out the better terminal thing.

I’m not sure what qualifies as a “hardcore IDE” for you, but Juno/Atom, VS Code, Emacs and vim are all very well supported and seem to cover the range of conceptions of “hardcore IDEs”. I will admit that they’re probably not as well polished as RStudio, but that IDE has been developed for a decade and is the primary focus of a company by the same name. Personally, I prefer a lightweight non-IDE like SublimeText together with a terminal.

13 Likes
6

To my experience, RStudio is no faster than VSCode (can’t say about Atom). I have used RStudio since 2013, and I feel like it only got stable last year. Showing multiple ggplot figures used to crash RStudio. R is also very easy to crash when dealing with large data and intensive computation. When R freezes, the code typed on RStudio editor will not be saved, and this issue was solved last year.

Actually both PyCharm and Spyder are slower than VSCode on my machine. If you really want “hardcore” IDE, take a look at scite editor. It is really fast and lightweight.

It has a very easy-to-work terminal where you can send your Julia code to Julia.

1 Like
7

As far as I know very few programming languages have official IDE’s. Python doesn’t, R doesn’t, C/C++/Fortran doesn’t, Ruby, Haskell, etc. None of them do. Matlab has an official IDE, which is a mix of good and bad.

RStudio has become the most popular IDE for R, and some people therefore consider it the de facto default IDE. But it’s not official. Juno is the closest thing for Julia, but since the use-cases for Julia are much more varied than for R, and the people who use it often has more varied backgrounds and more software development experience than R users (who tend to be statisticians and data scientists first), it is understandable that they have more varied requirements for their editors and IDEs.

Did you perhaps mean “dedicated IDE” rather than “official IDE”? I mean, are you missing an IDE that is tailor-made for Julia? That’s a different question, and one some people have asked before. I think it’s not a super idea (though it could be useful for a subset of users.) Perhaps one day someone will make an unofficial dedicated IDE for Julia. There have already been some efforts. But it is unlikely that they will become more popular than the plugin-based ones (Atom, VSCode, Vim, Emacs etc.)

3 Likes
8

I am not sure what you mean by “hardcore”, but it is surprising to see the term used in the same paragraph as Windows. :wink:

Julia works with many IDEs, which is great because you get to choose. Many people write multiple languages (eg I write in natural languages like English and Hungarian, markup languages such as Markdown, Org-mode, HTML, CSS, programming languages like Bash, C, Stan, Lisp, and last but not least, Julia). Having a single IDE for each with inconsistent interfaces would be a huge inconvenience for me.

That said, on Windows many people like VS Code and AFAIK it is well supported. Your writeup is appreciated, but it may be better to simply ask for help first, then you can get started with the language.

5 Likes
9

In general, I think that plugins to solid open-source text editors are the future (and the present) of IDEs, and that you will see fewer and fewer dedicated ones from now on. Except for large software companies, like Apple (who tends to have a very specific vision about how things should work, and who also have a gigantic ecosystem that developers target), it will just be too hard to compete with the flexibility and functionality of plugin-based editors.

My guess: Julia will never have an official IDE, you might as well get used to it! :slight_smile:

4 Likes
10

I sincerely hope for this, as having an “official” IDE usually implies that interfaces between the language and the IDE get blurred, so all other interfaces become less well-supported.

The ideal case is the language providing well-documented APIs for IDE functionality (introspection, documentation, debugging), and IDEs just building on top of that.

7 Likes
11

:100:

I find the idea of language specific IDE a bit strange: it’s very hard to get the feature set of say Atom with all of its plugins, fuzzy file search, pane splitting, excellent git/github integration, multiple cursors, vim keybindings etc. starting from scratch. OTOH, hardcore vim users will probably want a different feature set (ability to run remotely in ssh+tmux, good regex search, macros, vim navigation, composable commands, C-o C-i jumps across files, low latency even when working with large files) and users of different editors that I’m not familiar with will probably expect yet other different features, so it’s very hard to think of an “official IDE” that satisfies everybody. I’m extremely happy with the status quo of having plugins for existing editors (have only used consistently Juno and julia-vim and found both of excellent quality). Plus, using an established existing multi-purpose editor has the advantage that if one learns how to efficiently use it, this knowledge transfers to other programming environments, for example Atom can very well be used for say HTML, CSS, JavaScript, Markdown, LaTeX etc…

As far as I understand a across language effort for this is the Language Server Protocol, implemented here for julia. This unfortunately still needs to stabilize a bit (at least the last time I tried it was a bit hard to get to work on neovim) but it’s an exciting prospect as very different text editors can use the same technology to add tighter julia integration.

7 Likes
12

The last I checked the major issue with LanguageServer is compile times. One would have to compile a pretty substantial system image for it to be pleasant to use and I’m not sure of the logistics of using such an image for LanguageServer when you may want to use a different one for your development.

There is no dancing around the fact that Windows is very sick as a development environment. I try to keep an open mind because frankly I don’t like Apple and I (unfortunately) still own a Windows machine because I enjoy gaming, but nothing ever seems to work right on Windows. Even Microsoft seems to have finally admitted defeat somewhat by (perhaps tongue-in-cheek) implying that developers should use the sandboxed linux environments now available within windows. Recently I had to help some colleagues ssh onto one of my dev servers and there were all sorts of problems with the terminal. I feel like I’ve never once seen a successful AppVeyor run, and I never seem to be able to figure out what bizarre quirk of windows caused whatever the error was.

My point is (I had one other than just general Windows-bashing) that Windows users just can’t expect things to work as smoothly as Linux or Mac users. Existing software that works well on Windows probably took an enormous amount of time and effort to get into its current state, and much of that is probably older software that wasn’t originally intended to run on UNIX-like operating systems.

3 Likes
13

I think Windows is only sick as a development environment because the UNIX stack has become the de facto methodology because of the web. If you just need to do, for example, C# development, or application development that uses the windows environment it works perfectly well :wink: I would much rather use the Visual Studio approach than to have to constantly use command line tools, hell I even like powershell more than sh… but if I want to use any opensource it is built with a UNIX mindset and the pain follows…

Not much can be done for windows if developers expect UNIX only tools to be the way to build systems. And sadly there aren’t many truly cross platform development stacks – just UNIX or something else… UNIX tools are hostile to windows users, and windows tools don’t work on UNIX (though microsoft is becoming shocking more open these days…). I think the reality is we just live in a 2 platform world at first approximation. But I don’t think it is really true that windows is somehow less friendly to development … it just isn’t a UNIX environment.

4 Likes
14

The Git Bash terminal works fine on Windows 10. One gets a usable shell mode.
I personally use SublimeText 3 (https://github.com/PetrKryslUCSD/HowToUseJuliaWithSublimeText3).
I also you run Julia in the Windows Subsystem for Linux (WLS), also within SublimeText.

15

Is this what you’re talking about? https://gitforwindows.org

1 Like
16

Yes, that’s it.

17

Cool, maybe we can borrow that and/or ship with Git for Windows.

3 Likes
18

I use and love cmder which is based on ConEmu. SublimeText3 is my favorite editor as well. It’s just blazingly fast.

1 Like
19

How many hundreds of Mb would it add to the Julia installation? (sorry, no, disk space is valuable on laptops). Nice option to have, but on an optional install basis.

1 Like
20

To develop UNIX centric tools, maybe. Specially those that don’t care to consider that, for good or bad, MS made some things different. For example, binary files should be open with fopen(fname, "wb"). One cannot allocate in one dll and free on another, posix only functions are not available in VS, etc.

But VS debugger is an age way from competition (OK, confess, never really tested Xcode for this) . Comparing to Windows File Manager the Finder and Linux like tools I have’d tested are, no offence, pathetic.

1 Like