mdcfrancis

The authors of the encoding/json library thought the same. As a way to exit from deep down in a parse stack it works well especially if you only have limited entry points. https://cs.opensource.google/go/go/+/refs/tags/go1.19:src/en... uses well typed panics.

Amazon WorkMail, part of the AWS suite of tools, $4/month/user last I looked. If you host your domain on route53 setup is painless. It's an exchange server compatible service and provides some MDM functionality.

I can answer for the type stable julia case, if you have a struct in julia that is composed only of primitive types this is stored as a C struct with zero overhead and fixed byte length. An array of these is then crazy efficient when it comes to streaming into the CPU etc. If you dig around the GPU support in Julia you can see this used to good effect.

unfortunately, I don't have access to that code anymore, I wrote a number of loaders for different data set types including CSV. The time series were all modeled as forward iterating stream of tuples, so there is no specific table abstraction. There is an implicit assumption that the stream is ordered by the join key, in a time series this being the timestamp, though nothing in the implementation enforced that.

Joins are always n-way merge joins, so you can write something like y = 2x^2 - 3z + c and fold that into a single streaming operation y = f( x, z, c ) where y, x, z and c are time streams.

When rendered to screen they looked very similar to your examples. With plugins in the IDE you could directly plot and array of time series as a chart.

Since the time I wrote NamedTuples the Julia core team folded the functionality into the core of Julia https://docs.julialang.org/en/v1/manual/types/#Named-Tuple-T.... This is the core of https://juliadb.org/ all credit to the Julia core team

I've written similar in Julia, you can see the record type used in https://www.juliapackages.com/p/namedtuples. The full library, not in the open source, uses this type for time series analysis. It's all type safe and allowed expressions such as x = vwap( ts, 5) - l1( vwap( ts, 5)) through to a time moving PCA. Julia makes writing this sort of thing short and quick. The total impl was only a thousand lines or so of code.

they are also, type stable, strongly typed and have the same overhead as a struct. So an array of NamedTuples takes the minimal space and allocation.

I'm not the best placed person to answer about Python, my background is primarily C++/Java and functional languages. The types in general get out of the way. The ability to specialize behavior by types makes for some very interesting patterns and for a module writer add a huge amount of power. For the user of the module they rarely see the types.

The cons, top three from the top of my head, implicit array concat ( going in 0.5 ), String types ( going soon ), anonymous function performance ( gone by 1.0 )

None of these are show stoppers, but they do sometimes fall into the category of surprising. The core dev are very aware of the issues and if you look at the road map for 1.0 many are either well on their way to being fixed or are scheduled to be resolved.

This is great news for Julia.

As a person who has spent the best part of year coding almost exclusively in Julia (I work in finance, we were one of the main sponsors of JuliaCon, though these are my personal thoughts) I want to chime in a little.

To get to 1.0 many of the cons in the language will be solved and there are plans in place for much of this.

I never cease to be surprised by the brevity of code to solve complex problems. Something which would be hundreds of lines in Java/C++ often turns into 50 or so lines of much more readable code.

When asked to describe Julia I struggle but end up this way 'I can make Julia 'dance' like no other fast programming language' though to be fair modern JS is pretty close for many tasks.

The parametric type system is to me the strongest part of the system - I describe it simply as 'templates that work', it is ridiculously powerful and (to me) is the most compelling reason to learn Julia.

I personally find even at 0.4 it is very usable even for tasks which are not math. Though the run time is currently fairly heavy.

So congrats to the Julia team.