> It’s also worth noting that there are cases where the interpreter feels faster, at least on initial execution. Julia’s JIT compiler produces excellent results, but all that code-analysis takes time; there is interest in exploring whether running more code in the interpreter could reduce latency, a.k.a. the “time to first plot” problem. JuliaInterpreter is a potential tool for exploring that trade off, and it appears that not much additional work would be needed.
Oh wow, this is great. I've really enjoyed what little toying around with Julia I've done, but it seemed just shy of feeling truly interactive to me. But I really do love the featureset of the language, so if this gets integrated into the language and it helps in time to interactivity, I'll absolutely be moving some parts of my work to Julia.
If I need to understand what subtle assumption of DifferentialEquations I violated stepping into the point of failure is God sent. And that's a well documented package.
More importantly, I now can usually reason my way around. But my students can use this to learn what goes wrong in their codes interaction.
This is a massively important step in the tooling and ecosystem. Congratulations to the developers.
A side question: How is Julia for web development? I'm not really a web developer and my mindset is more in realms of C, shell and CGI or Go. I mean a small to mid scale operation so SQLite integration is probably enough and Julia has a package for that.
Julia has a web framework called Genie (https://github.com/essenciary/Genie.jl) which seems decent enough (probably useful for data visualizations but I don't know of many people using it (I haven't used it for anything worth mentioning)
One of the neatest things I found when I was messing around with Julia was UnicodePlots, which lets you make nice plots right in the terminal. I love that little library and used it to build a little live orderbook of GDAX right in the terminal. I wish there were more terminal-based applications for non-sysadmin/engineering tasks, I feel like its such a useful medium.
A lot of the libraries are focused on optimization, differential equations, statistics, matrix operations...those sorts of things. It doesn't have classes in the way you would probably think (not really an OO language).
I read that their focus is on scientific computing, but I feel that there is a growing effort to expand Julia's use cases. Also I think that some end user applications could gain a bit from optimized statistics or matrix operations.
The associated libraries are, unfortunately but understandably, less well developed than counterparts in other languages. E.g. right now I'm happily using AWS[Core/SQS/S3], which are highly functional community developed AWS packages, but they're definitely less full featured than boto3. My impression is this situation is common for a variety of web and database packages.
There are many ways to do OOP.
I advise to read the "The Art of Metaobject Protocol".
There are many ways to do OOP from CS point of view, be curious, learn them.
If you need more features the Genie.jl library is aiming to be a full featured web framework.
Here is a quick screencast: https://imgur.com/a/PXTRgHp
Just a quick note for the inattentive like me: you have to click the "Run" button before executing the `@enter foo(20)` command.
I've been getting into Julia a bit for personal projects, since I like it better than Python, so maybe this will be a good excuse to learn how to use debuggers more effectively.
My experience regarding people around me that don't use them is that they never actually bothered to learn how to use them.
Same applies to other development tools like profilers and static analysers.
I guess I was quite lucky with some of the teachers and professors that crossed my path.
I definitely would benefit from learning more about performance profilers though. You've given me an idea of reading material for the weekend.
Debuggers aren't exactly self-explanatory so the role of good teachers should not be underestimated
So, yeah, learning the keyboard shortcuts for how to step through something takes effort. However, it is doing basically what I was taught to reason about programming.
Functional idioms throw a lot of this a giant curve ball. Heaven help the person that was used to stepping through a for loop that steps over a map call. Oops. Worse if it is lazy.
That said, they are not competing ways of thinking. Just different ways. If you are having trouble with one, try the other.
(I do note that the difficulty of working in a debugger is ironically one of the major criticisms of macros in lisps.)
- FoxPro /VisualFoxPro (the best of all, IMHO)
Others more common debuggers (Visual Studio, Xcode, IntelliJ, maybe others I don't remember), have issues, like the amazing "feature" of show opaque values, not allow to inspect stuff or requiere extra steps.
But the worse of all? Them are SLOW. Do "step" is slow. Waiting to see if evaluating values? slow.
Python have almost good, but mostly because python allow to see a lot. GDB sucks as is, but python make it look good.
Plus it is not like one needs to single step all the way, there are plenty of ways to control execution flow.
Like 7h ago?
But here, I was talking how other debugger have not the same problems.
But really, what do you use in their place? Do you work in an environment that is "debugger by default" (as opposed to a separate step where you need to "debug" instead of "run")?
I think it's the difference between inspecting local vs global program behavior. A debugger gives a very local view of the program but the most difficult bugs are ones where the local behavior is (or seems) correct but the global behavior is wrong. In that case it can be much more useful to run the program to completion with plenty of logging and then to carefully inspect the record of how the state changed.
I have often thought that programmers posture over their tool independence to signal their excellence. Before the current generation of programmers, many programmers would proclaim how they didn't need to use higher level languages to assist them in programming because assembly language was sufficient given their reasoning powers. Today programmers proclaim they don't need types to insure data invariants as their reasoning powers are sufficient. They proclaim they don't get any value from unit testing because they can maintain correctness across all development phases using their reasoning powers alone. They proclaim they don't need automatic garbage collection because they can insure correct memory usage using their reasoning powers. They have no use for IDEs, debuggers, or profilers because they believe none of these tools could augment their reasoning powers.
Excellent programmers can indeed compensate for poor tooling through their reasoning powers alone. But if history is a guide, people who don't use the best tools, practices and technologies to produce the best work, at some point, wont produce the best work.
If there wasn't gdb/lldb at all, I'm pretty sure Linux/BSD would have a debugger that's far better than any closed source counterpart.
Well, cite, please.
Which isn't to say that live coding and debuggers are bad. However, they are usually much more useful to find out either how something got to where it is, or to augment what you have until it is ready to send for review.
I've also used the Visual Studio debugger for F#, and I think I did gdb with Eclipse a couple years ago when I did C.
Might be helpful :) https://timholy.github.io/Revise.jl/stable/
This. I just did this today on CL, because I needed it. I was running a long process and can't afford to stop it.
And note that i'm using a CL compiler that compiles down to machine language, not an interpreter.
unless the code has been inlined
It is a a bit less polished than Debugger.jl right now.
Debugger.jl on the other hand is slow, being interpreter-based, but very reliable. The down side is that it's really slow, so if you need to debug performance intensive code, you might be in trouble. In the future, the plan is to steal tech from Gallium  and MagneticReadHead  and use them to create a hybrid interpreted/compiled debugger that is as reliable as Debugger.jl is now but which can run code fast enough to debug even compute-intensive workloads effectively.
- Being completely written from scratch in Julia
- Mixed debugging between Julia and C/C++ code
- Integration with https://github.com/mozilla/rr for time traveling debugging
- Debugging windows programs running on a linux host under wine (and in particular even as an rr replay).
- Zero overhead debugging by using mixed modes (DWARF based debugging generally, a much more accurate interpreter based one when possible).
- Very precise location tracking, on an expression basis, not just a line-by-line basis
- Multi-process debugging by riding along RPC calls, even across machine and even as separate rr recordings across machines
After 0.6 was released, I decided this wasn't working out for a Julia debugging story and pulled out just the interpreter and UI parts from Gallium (that package was called ASTInterpreter2.jl). This worked ok, but was lacking a bunch of features that I never got around to implementing, because the lead up to 1.0 required a whole bunch of compiler work that nobody else was available to do. This work now is based on that work from 0.6, but actually making it work nicely and paying a whole lot of attention to it that I was never able to. I'm very happy that Tim, Kristoffer and Sebastian decided to take this on, because I feel like my workload has only increased over the past year ;).
I still very much want all the ambitious features from above, and we do still have the code (and much of it is actually in use, just not for debugging) and I'm fully expecting them to make a recurrence. However, this time around, we'll start with a stable, usable system and gradually make it faster and add features, rather than building an unstable system with all the features and trying to fix it. The former approach is much better for getting usable tools out (though sometimes the latter can lead to more interesting results in a research setting). The other thing to note is that Julia is much more stable now, so it's easier to keep things running without breaking every few months.
1. Gallium was a traditional gdb/lldb-style debugger
2. Debugger.jl is a pure interpreting debugger
3. MagneticReadHead works by compiling a modified version of the code you want to debug that is instrumented to add debugging hooks (this is different from how gdb/lldb work).
Just kidding, there are many cool things that are in the works, including Go-style multithreading and effortless automatic differentiation of arbitrary code, allowing you to "machine learn" any algorithm without a complex framework.
But that's all stuff that's not even available in most languages—now is a great time to start using Julia:
1. The latest stable release is 1.1—code you write now will keep working on all 1.x releases
2. There's excellent editor and IDE support for Julia in pretty much every imaginable configuration
3. There's a solid debugger with interfaces from the terminal and IDEs (and I'm sure soon there will be many more)
I think that is worth it for Rust because I think it has good features for building compilers. And really low level runtime-y bits.
Julia has less good features for building compilers.
But still the vast majority of the language is in Julia.
Including a lot of the code lowering.
Still, the fact that it's almost all Julia suggests to me it could be all Julia, although maybe that's changed with 1.0+ releases.
Trying to think about why it matters to me, I think what it is a sense that if you can get what Julia offers from another language that does more, it probably is better to use that other language. So I want to see it pushed to be more general-use. Not just for the principle, but because I think in general there are gains to languages in doing so. E.g., my guess is that getting Julia to be self-hosting would require certain efforts that might pay off in other ways, or set the stage for such things.
It's worth noting that this entire effort is done in external packages that work on both Julia 1.0 and 1.1. One of the biggest things Julia previously needed was stability, and we now have that.
And it adds up to over 100% because many people use many things. I use all of the above
I'm not sure who the "they" you speak of is.
that "should choose VSCode as their main editor."
However some packages are still being updated.