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.
The stdlib is not always the best example of idiomatic Go; encoding/json is particularly infamous for having poor performance and awkward APIs. I'm fairly confident that it it was re-written today, it wouldn't use panic/recover.
which was why I used it. I basically had a single entry point (if i remember correctly) something like "match(regex, text)" and hence it made it easier for me to write by just panic at the error location and recover within the match() call than putting if err != null everywhere. Or at least that's what I thought then in terms of cleanliness.
in all the production code I've written in go since then, I haven't used panic/recover because its not considered proper. But I'm still a bit skeptical as do think it can make code a bit cleaner when writing a library (I'd 100% agree though that the panic should never escape the library though and only a plain error returned to the caller, i.e. need strong library boundaries for this).
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.
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.
I checked your website; do you have an example of how to load data from a file into NamedTuples? Specifically, can NamedTuples infer type from an external source?
Also, do you have an example of what a displayed table looks like? Julia has a DataFrames package that can display a table. I am curious to know how your time-series library displays a table.
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.
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.
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.
As someone who spent some time learning Julia and wants to like it, here are the problems I experienced when I was trying to actually write software with it that I would keep using, as opposed to just scripting some numeric operation I needed to do.
* Non-numeric things are not well optimized. Building a dictionary full of strings was slower than Python when I tried it.
* The module system is confusing because of the principle that files should be "mostly unrelated" to modules. The documentation gives you no advice on how you should organize your code so that it's easy to import, understand, and maintain. The advice I got at a meetup was "just include() everything".
* Package management is a loose wrapper around git. The git commands it runs do not always succeed.
* Curly braces do something different in every version.
