Jump to page: 1 2 3
Thread overview
What Julia Does Right
Dec 08, 2022
Walter Bright
Dec 08, 2022
ryuukk_
Dec 09, 2022
zjh
Dec 09, 2022
zjh
Dec 09, 2022
zjh
Dec 09, 2022
FeepingCreature
Dec 09, 2022
zjh
Dec 09, 2022
FeepingCreature
Dec 09, 2022
Paul Backus
Dec 09, 2022
H. S. Teoh
Dec 09, 2022
Walter Bright
Dec 09, 2022
Walter Bright
Dec 10, 2022
Greggor
Dec 10, 2022
Walter Bright
Dec 10, 2022
rikki cattermole
Dec 10, 2022
Hipreme
Dec 10, 2022
max haughton
Dec 11, 2022
Greggor
Dec 11, 2022
rikki cattermole
Dec 11, 2022
zjh
Dec 11, 2022
max haughton
Dec 11, 2022
bachmeier
Dec 11, 2022
max haughton
Dec 09, 2022
Guillaume Piolat
Dec 10, 2022
Don Allen
December 08, 2022
Here's a good thought provoking article:

https://viralinstruction.com/posts/goodjulia/

A couple of things stood out for me:


1. https://viralinstruction.com/posts/goodjulia/#the_package_manager_is_amazing

I've never thought of a package manager that way.


2. "Rust, for example, may have a wonderfully expressive type system, but it's also boilerplate heavy, and its borrowchecker makes writing any code that compiles at all quite a time investment. An investment, which most of the time gives no returns when you're trying to figure how to approach the problem in the first place. It's also not entirely clear how I would interactively visualise and manipulate a dataset using a static language like Rust."

I've always thought that a great strength of D was its plasticity, meaning you can easily change data structures and algorithms as you're writing and rewriting code. Apparently this is much more difficult in Rust, which will inevitably result in less efficiency, even if the compiler for it generates very good code.
December 08, 2022
On Thursday, 8 December 2022 at 17:47:42 UTC, Walter Bright wrote:
> Here's a good thought provoking article:
>
> https://viralinstruction.com/posts/goodjulia/
>
> A couple of things stood out for me:
>
>
> 1. https://viralinstruction.com/posts/goodjulia/#the_package_manager_is_amazing
>
> I've never thought of a package manager that way.
>
>
> 2. "Rust, for example, may have a wonderfully expressive type system, but it's also boilerplate heavy, and its borrowchecker makes writing any code that compiles at all quite a time investment. An investment, which most of the time gives no returns when you're trying to figure how to approach the problem in the first place. It's also not entirely clear how I would interactively visualise and manipulate a dataset using a static language like Rust."
>
> I've always thought that a great strength of D was its plasticity, meaning you can easily change data structures and algorithms as you're writing and rewriting code. Apparently this is much more difficult in Rust, which will inevitably result in less efficiency, even if the compiler for it generates very good code.

I had the same impression, Rust lacks flexibility, but that's due to the goal of the compiler, although enums were nice to work with, being able to compose with them with pattern matching helps making the code less rigid and a little more flexible


December 09, 2022

On Thursday, 8 December 2022 at 17:47:42 UTC, Walter Bright wrote:

>

Here's a good thought provoking article:

https://viralinstruction.com/posts/goodjulia/

A couple of things stood out for me:

  1. https://viralinstruction.com/posts/goodjulia/#the_package_manager_is_amazing

I've never thought of a package manager that way.

I just saw the neat language which based on D. I think language plug-in is really a very good concept. The D plug-in author can specifically open/close some D features In this way, the author of the D plug-in does not need to set up a separate branch, but directly set up a sub branch under the plug-in directory of theDlanguage. The author of the D plug-in can use the latest D features at any time, and theD user can also enjoy the D plug-in feature.
In this way, people do not need to establish branches of 'D'.

December 09, 2022

On Friday, 9 December 2022 at 02:10:01 UTC, zjh wrote:

>

In this way, people do not need to establish branches of 'D'.

If the plug-in author creates a language alone, but still has torepeat many things, and has no reputation, it is very troublesome. If combined with languages such as D(If D has plug-in system), it can not only strengthen the D ecology, but also increase the plug-in author reputation. It is really a combination of strong and strong. I think D authors can really try!

Make the Dlanguage the base language of the new language, while other features are implemented by the D plug-in author, similar to the relationship between Microsoft and driver. This can expand the ecology!

December 09, 2022

On Friday, 9 December 2022 at 02:18:09 UTC, zjh wrote:

>

similar to the relationship between Microsoft and driver. This can expand the ecology!

The language plug-in author is not the official language, but it is an ideal place to create new language features. If the language official approves,language official can also add the feature as default after the feature experiment verification is completed, so that the language official is automatically entered. This is really, very cool!

December 09, 2022

On Friday, 9 December 2022 at 02:10:01 UTC, zjh wrote:

>

On Thursday, 8 December 2022 at 17:47:42 UTC, Walter Bright wrote:

>

Here's a good thought provoking article:

https://viralinstruction.com/posts/goodjulia/

A couple of things stood out for me:

  1. https://viralinstruction.com/posts/goodjulia/#the_package_manager_is_amazing

I've never thought of a package manager that way.

I just saw the neat language which based on D. I think language plug-in is really a very good concept. The D plug-in author can specifically open/close some D features In this way, the author of the D plug-in does not need to set up a separate branch, but directly set up a sub branch under the plug-in directory of theDlanguage. The author of the D plug-in can use the latest D features at any time, and theD user can also enjoy the D plug-in feature.
In this way, people do not need to establish branches of 'D'.

Note that an important attribute of the way I use macros is that they're pulled into the compiler automatically, but only directly affect code that imports them. So the meaning of existing syntax can be overloaded at the use site by a macro type like all types can, ie. opCall, opBinary, etc., but you only get new syntax if you macro import. The goal is to have a rich central type system that macros can internally fall back on.

If you treat macros as compiler plugins that you pass on the command line, for instance, you fracture the ecosystem because you can no longer combine two libraries with macros that occupy the same syntax. The goal is to keep macros, broadly, encapsulated to the site of use.

December 09, 2022
On Thursday, 8 December 2022 at 17:47:42 UTC, Walter Bright wrote:
> Here's a good thought provoking article:
>
> https://viralinstruction.com/posts/goodjulia/
>
> A couple of things stood out for me:
>
>
> 1. https://viralinstruction.com/posts/goodjulia/#the_package_manager_is_amazing
>
> I've never thought of a package manager that way.
>
>

I'm not sure what you mean here? As far as I can tell, dub does all of that.
December 09, 2022

On Friday, 9 December 2022 at 05:43:56 UTC, FeepingCreature wrote:

>

Note that an important attribute of the way I use macros is that they're pulled into the compiler automatically, but only directly affect code that imports them. So the meaning of existing syntax can be overloaded at the use site by a macro type like all types can, ie. opCall, opBinary, etc., but you only get new syntax if you macro import. The goal is to have a rich central type system that macros can internally fall back on.

If you treat macros as compiler plugins that you pass on the command line, for instance, you fracture the ecosystem because you can no longer combine two libraries with macros that occupy the same syntax. The goal is to keep macros, broadly, encapsulated to the site of use.

Thank you for your explanation

December 09, 2022
On Thursday, 8 December 2022 at 17:47:42 UTC, Walter Bright wrote:
>
> 1. https://viralinstruction.com/posts/goodjulia/#the_package_manager_is_amazing
>
> I've never thought of a package manager that way.
>
>

At the end of the day, someone that uses the package manager, will have much less contact with the compiler directly. The package manager is the primary entry and you "speak" more with it than any other tool. On this regards, DUB having colors is more significant than dmd having colors.

The only reason I would type `dmd` or `ldc2` nowadays is to reduce a bug for Bugzilla.

Modern UI toolkits like comes with a commandline tool which you do most of it, for example flutter. It's like a nice interface for "doing things with the library".
December 09, 2022
On Friday, 9 December 2022 at 05:45:36 UTC, FeepingCreature wrote:
>
> I'm not sure what you mean here? As far as I can tell, dub does all of that.

Some features from the article that as far as I know have no equivalent in dub:

1. Caching registry locally.

> Resolving environments feels instant, as opposed to the glacially slow Conda that Python offers. The global "general" registry is downloaded as a single gzipped tarball, and read directly from the zipped tarball, making registry updates way faster than updating Cargo's crates.io.

2. Multiple registries with namespacing.

> Pkg is federated, and allows you to easily and freely mix multiple public and private package registries, even if they have no knowledge of each others and contain different packages with the same names.

3. Cross compilation.

> The BinaryBuilder package allows you to cross-compile the same program to all platforms supported by Julia
« First   ‹ Prev
1 2 3